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