成爲高效程序員的 14 個習慣（一）

Paul Isaris 原做，受權 New Frontend 翻譯。

序言

不少人相信從一個高效的初級程序員轉變成中級程序員只是時間和經驗的問題，然而現實中這兩類程序員的劃分並不太明確，也比較主觀。我寫這篇文章毫不是想要和其餘人爭論「如何定義中級程序員」。

我認爲，能從根本上改變一我的的思惟習慣並讓其從初級程序員轉爲中級程序員甚至是高級程序員的東西，是「習慣」：

習慣就是經過系統性地開始作一件事來使它從陌生變得天然的過程。

造成編程與工做相關的習慣對專業知識的提高和我的的成長相當重要。

讓咱們看看有哪些習慣一旦造成後能幫你成爲更好的程序員並持續取得進步：

1. 保持方法簡短

理想狀況下，每一個方法應包含不超過 20 至 30 行代碼（LoC）。這個習慣很重要，由於它不只會讓你致力於編寫緊湊的代碼，還會讓你在須要模塊化程序時保持較好的分析能力。編寫具備多層嵌套的代碼（好比使用大量 if 語句和 for 循環）簡直就是噩夢，由於雖然這樣作可讓編寫過程更加容易，但當你往後回頭看你的代碼時，你可能再也想不起它是作什麼的了。

除此以外，結構複雜的方法通常具備較低的可複用性。它們一般只在一個項目中具備單一的用途，而且很難在其餘地方使用。

2. 起有意義的名字

不管是方法仍是變量。一箇中級程序員給變量起「x」、「xyz」甚至是「object」這樣的名字確定是不行的。用英文單詞做爲變量名的目的就是爲了讓它們擁有實際含義。

用代碼自己傳遞信息比用文檔和註釋更加劇要。

註釋的目的是解釋「爲何」，而不是「怎麼作」。

使用有意義的變量名不只能幫助你更好地向閱讀代碼的人傳遞信息，還能讓你避免使用大量註釋。這一點同時適用於「變量」和「方法」。另外，若是你實在想不出好的名字，應考慮重構你的代碼來簡化每一個方法。給簡單的方法取名要比給複雜的方法取名容易得多。

想不出名字的時候，看看是否是你寫的方法太複雜了，須要重構。

3. 不要讓方法包含太多參數

若是你發現你寫的方法含有大量的參數，你應該考慮去重構它，由於這樣的方法一般會違背 SRP（單一功能原則），意味着它承擔的工做種類太多了。一個高效、簡潔的方法應當專一於「作好一件事」。Uncle Bob 曾說，一個方法應最多接受三個參數。雖然這不是必須的，但它讓你清楚對於一個方法來講最合適的參數數量。

重構代碼並非要把方法的參數改爲類的變量，而是減小每個方法的工做量，或者拆成兩個方法。

這裏引用 Robert C. Martin 說過的一句話：

「一個方法應儘量減小參數的數量。沒有參數固然是最好的，其次是一個、兩個、三個。三個以上的話就比較有問題了，應儘可能避免。」

4. 不要在一個類裏面寫太多方法

就像一個方法擁有的參數數量同樣，一個類裏面方法的數量也很重要。若是一個類特別龐大、包含不少方法，一般意味着這個類「存儲了太多信息或是承擔了太多功能」。這些類一般被稱爲上帝對象，以形容它們是含有高度耦合代碼的反面模式。

若是你的一個類包含了不少方法，想想你是否須要隨着程序的進化而時常回來修改這個類。若是是的話，你可能違背了開閉原則，也就是「軟件中的對象（類，模塊，函數等等）應該對於擴展是開放的，可是對於修改是封閉的」。

5. 只使用長期支持/穩定版的第三方庫

你的代碼應照顧到往後會用它從新編譯整個項目的程序員。LTS（長期支持）版的庫、插件和框架可能缺乏了一些新鮮的功能，但它們會使其餘人從新編譯一個項目時更加方便。

不要老是想着用最新版的工具，而是要用最安全、最穩定的版本。不管是未來的你仍是你的同事都會感謝你的！

6. 學會識別常見的設計模式

你沒看錯，不少大型項目都會使用一種或多種設計模式來確立設計描述、關係和抽象等級。你不須要了解全部的設計模式，只需掌握關鍵的幾個就夠了，這樣不只有助於你構思和設計本身的程序，還能讓你在閱讀其餘人寫的代碼時從中認出它們。

若是你能在別人的代碼中識別出設計模式，你就能夠很輕鬆地找到各個類和對象所在的位置，進而能夠擴展和添加你想要的功能。

一個好的設計模式可讓項目的全部參與者使用共同的設計語言並高效地藉助代碼進行交流。

7. 爲後來的程序員考慮

不管是未來的你，你的同事，仍是新來的程序員，甚至是別的公司的程序員，都有可能須要基於你寫的代碼擴展或添加新的功能。不少初級程序員不理解這個，由於他們已經習慣爲大學裏面那些獨立完成的項目編寫只有本身才能看得懂的代碼。

然而工做場合的需求跟大學仍是不同的。你可能須要給已經運行幾年的項目編寫代碼，而且你的代碼還要考慮到幾年後會進來的程序員。若是你經過一些奇奇怪怪的手段實現了一個功能，或是在構建程序中添加了一些步驟而沒有寫在文檔裏，亦或是在本該重構的地方沒有這樣作，你都會爲後來的人創造一些早晚須要解決的技術負債。

建議每隔幾小時就回顧一下你的工做，好比往 README 文件裏添加一些必要的說明，或是刪除一些臨時編寫的但再也不須要的代碼和文件。另外當你不肯定你在架構或編程方面的決策是否正確時，能夠請教身邊一些更有經驗的人。照着這樣作，你不只能在工做中寫出更優雅的代碼，還能提高在未來處理相似問題的能力，同時適應自尊心受挫的感受。（這是中高級程序員天天都要面臨的體驗 :D）

結語

從初級程序員躍升到中級程序員並非一晚上之間就能完成的事，你須要養成好的習慣才能在工做上有所提高並變得更加專業。在這篇文章中，我列出了一個程序員想要做出這樣的改變併產生影響力所須要的最重要的習慣。

• 推薦閱讀：成爲高效程序員的 14 個習慣（二）