我從優秀的開發者那里學到的19件事
1.三法則
三法則是一個代碼重構的經驗法則，用來決定什么時候應該用新的代碼/程序/方法來替換一段復制的代碼。
它規定，允許你復制粘貼一次代碼，但當同一代碼復制三次時，應提取到一個新的程序中。主要的概念是使代碼/程序/方法能夠在項目中通用，這樣它就可以在很多地方重復的使用。
2.穩定才是王道
在結構和編碼方式上保持一致。這可以幫助你提高代碼的可讀性和可維護性。
嘗試并提出一致性的編碼標準，這有助于保持一致性，最好精確到你的變量的命名習慣。另一個重要的是代碼程序的結構，它應該是顯而易見的，開發人員需要做出一些改變或添加一些新的東西。
3.減少嵌套
If中的if可能會使代碼結構變得很亂，而且很快就很難讀懂。有時你可能無法繞過這個問題，但一定要看看你的代碼結構。對于 else if 來說也是一樣的，要盡可能避免if嵌套，因為這有時會使代碼更難讀。
衛語句(又稱 提前返回 /提前退出)是幫助解決這一問題的有效方法!衛語句只是用于檢查先決條件，可以是一個返回語句，也可以是一個異常。
沒有使用衛語句示例：
- if (account != null)
- {
- if (order != null)
- {
- if (order.term == Term.Annually)
- {
- // term annually
- }
- else if (order.term == Term.Monthly)
- {
- // term monthly
- }
- else
- {
- throw new InvalidEnumArgumentException(nameof(term));
- }
- }
- else
- {
- throw new ArgumentNullException(nameof(subscription));
- }
- }
使用衛語句示例：
- if (account == null)
- {
- throw new ArgumentNullException(nameof(account));
- }
- if (order == null)
- {
- throw new ArgumentNullException(nameof(order));
- }
- if (order.term == Term.Annually)
- {
- // term annually (return here)
- }
- if (order.term == Term.Monthly)
- {
- // term monthly (return here)
- }
- throw new InvalidEnumArgumentException(nameof(order.term));
4.從全局出發去考慮
對項目整體有個認知是非常重要的，這能使小細節更容易跟進。一旦你了解了項目的整體結構，小細節就不需要再去花太多時間去研究。
5.花點時間思考下命名的問題
在編碼中給變量、方法或對象命名是困擾我們的事情之一，這可以是給一個類、方法甚至是一個變量命名。一個優秀的開發者會花時間考慮相關的變量名，因為他們知道這有助于提高可讀性!
6.技術負債是不好的
要求高點可以幫助解決這個問題。盡量一次寫好你的代碼邏輯，否則你就得反復的去重構。
技術債務是軟件開發中的一個概念，它反映了由于現在選擇一種簡單的(有限的)解決方案，而不是使用會花費較長時間的更好的方法而導致的額外返工的成本。
7.過高的評估
根據您所處部門的不同，您未必喜歡這一點。但優秀的開發人員往往會高估任務，因為他們知道事情大概要花多長時間，然后會給預期再增加一個緩沖的時間，這樣可以幫助你把事情做好。
這可以真正幫助你解決上面的觀點—— "技術債務是不好的"。如果你低估或預估了一個比較理想的時間，實際上可能會無法完成，甚至會遺留一些技術債務。因為你的期望只是盡快的完成并能夠使其正常運行，而不是使代碼干凈且易于維護。
8.文檔和注釋
文檔和注釋有助于幫助自己或者他人更容易的理解和使用。你會聽到一些有經驗的人在說，我們能不能把這個過程記錄下來，或者代碼審查失敗，因為接口沒有相關注釋等。
9.敢于刪除不好的或沒用的代碼
你經常會看到很多不太自信的開發人員將大量代碼注釋掉并留在那里。版本控制是有目的!優秀的開發人員不會回避刪除應用程序中沒用的代碼。
10.花時間檢查編寫的代碼
優秀的開發人員將花費更多的時間在代碼審查上，并且知道代碼審查的重要性。
- 盡早的發現BUG;
- 提高開發人員的技能，并讓團隊其他成員也養成這樣的習慣;
- 知識分享;
- 一致的設計和實現。
我見過的最好的代碼評審過程是：
- 1個風險不大的小任務應該由1個開發人員進行審查;
- 中型/大型更改或有風險的更改應由3位開發人員進行審核，其中一位是其辦團隊中的高級開發人員;
- 一個風險極高的修改或是正在開發的新功能，應該舉行一個會議，3個開發人員至少有一個是首席開發人員，然后一起去看每一行，并提出建議。
11.編寫測試用例
您會注意到，經驗更豐富，實力更強的開發人員會花更多時間編寫好測試用例。良好的測試用例可以幫助您更有信心地擴展或修改程序代碼，并有助于減少bug的產生。
12.花時間去設計
在深入研究代碼或寫代碼之前，請先進行仔細考慮，然后將其分解為小塊。這有助于幫你如何將所有東西組合在一起，并為創建更簡潔的代碼做更多準備。
13.要注重技術實現原理而不是語法
這是個大問題! 他們喜歡學習基礎知識大于注重語法。這可以幫助他們更有效的發現問題，也可以幫助他們更明白的google問題。
14.讓谷歌成為你的好朋友
他們是Googling的專家，能更好的找到解決問題的方法。因為上面提到他們更專注于基礎知識而不是語法，所以他們知道該搜索哪些谷歌術語，如果你執著于學習語法，這是很難做到的!
15.先實現功能再優化
一些初級開發人員，似乎一開始就花了很多時間讓編寫的代碼看起來很漂亮，這樣如果最后發現它們無法正常工作就陷入尷尬。優秀的開發人員會在早些時候只實現功能，這樣把細節處理好之前可以盡早的發現問題，有利于保證項目更加順利的進行。
16.風險管理和解決問題
高級開發人員可以把控風險，通過設計模式的應用提煉出復雜的問題，并且根據過去的經驗，可以獨立解決不同的問題。
17.多問
優秀的開發人員想了解的多一點。即使聽起來很簡單，他們也不介意提出問題。這些可能是與技術或業務相關的問題。了解業務需求有助于他們編寫更好的代碼!他們對自己的能力充滿信心，因此不怕問問題。
18.盡可能地將邏輯從數據庫中分離出來
這一點要看你構建的應用類型，只有在不會影響性能的情況下才可以。
他們知道要把數據庫查詢控制在簡單的CRUD操作中。
Create, read (aka retrieve), update, and delete
然后，業務邏輯層應該將這些內容整合在一起。這有助于開發人員知道在哪里尋找業務邏輯。如果在數據庫查詢和代碼中有邏輯，這很快就會變得混亂。
19.保持代碼簡潔
他們知道保持代碼簡單是最好的方法。即使這意味著有時要多寫代碼。您將看到許多初級開發人員編寫如下所示的代碼：
- return dir.Keys.Any(k => k >= limit) ? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];
這通常是可行的，但是閱讀起來非常困難!
總結：
這就是我看到的優秀的開發人員每天都會做的事情。您會發現其中許多與實際編碼無關，而與過程以及它們如何處理任務有關......
