優秀的程序員都有哪些習慣？

（點擊

上方藍字

編譯：伯樂在線 -

阿慧

如有好文章投稿，請點擊 → 這裡了解詳情

【伯樂在線導讀】：「我不是卓越的程序員，我只不過是一個有著卓越習慣的程序員。」技術大牛 Kent Beck 曾這樣說過自己。

7月初，nostrademons 在 Hacker News 發起一個討論，是哪些習慣成就了優秀/卓越的程序員？

可變的習慣：學習著在不同的情況中採用不同的習慣。考慮到這一點，我總結了一些適用於不同情況的通用技巧：

為了數據科學類問題研究新領域的發展：

1.盡量親自動手去完成事情。你將會有一種直覺，知道如何去處理該事物。

2.積累案例，從數據表中標註著你已獲得的數據開始。

（關於這一點：rluhar 評論補充說，這不僅適用於數據科學，也適用於解決任何數值問題。用一個電子表格（或一個R／Python Notebook）來實現演算法並獲得一些結果，在過去幫助我真正理解了問題，避免走死胡同。例如，在建立一個外匯定價系統時，我能夠使用電子表格來描述定價演算法是如何工作的，並向交易者（最終用戶）解釋它。在執行和部署演算法之前，我們可以調整計算並確保一切都清楚。很好的建議！）

3.在找到通用辦法之前，先找到一種能解決當前問題的辦法。

4.讓演算法本身輸出調試信息。你應該能夠轉儲每一步的中間結果，並用文本編輯器或是 Web 瀏覽器手動檢查它們。

5.不要為單元測試操心，定義出正確行為才是首要的。

維護大的、不熟悉的代碼庫程序

1.檢查文件的大小。最大的文件總是包含了程序的實體部分，至少是指向程序實體內容的分派程序。 main.cc  通常很小，並且對尋找代碼結構毫無用處。

2.從主循環調度開始單步調試程序。可以學到很多關於控制流的東西。

3.尋找數據結構，特別是做為參數傳遞到許多函數中的那些。大多數程序具有一個小的關鍵數據結構集合，找到它們，理解代碼的其餘部分會變得容易的多。

4.寫單元測試。這是確認你所理解的代碼與真實代碼工作方式無誤的最好方法。

5.移除代碼，看看什麼出問題了。（但不要 check in！）

性能工作：

0.一般不需要做，除非你所構建的東西對用戶來說太慢了。制定出需要提高的性能目標，達成這個目標即可。

1.在開始所有工作之前，甚至是在剖析（profile）之前，建立一套代表典型現實世界的使用基準。別讓性能倒退，除非你確信已經登峰造極，高處不勝寒，並且更好的解決方法還藏在世界的某個角落裡無人發現（如果出現了那種情況，在版本控制系統（VCS）中標記你的分支，以便在發現錯誤之後回來更改。）。

2.許多性能瓶頸都出現在系統的交叉處。在所有 RPC 框架中搜集時間統計數據，並且有一些方式來傳播和可視化每個伺服器的請求時間，以及哪些部分的請求是並行的，哪裡是關鍵路徑。

3.剖析（Profile）。

4.通常，避免不必要的工作可使你贏在起跑線上。緩存最大的計算結果，粗略評估不常用的東西。

5.不要忽視常量因素。有時候一個漸進性更差的演算法在實踐中執行的很好，原因是其具有更好的緩存局部性。為此，你可以在多次調用的函數中識別出威脅。

6.當你獲得了程序大致剖析之後，更改數據結構往往會獲得更多收益。注意內存的使用，時常縮小內存需求來減小緩存壓力，可顯著地提高系統的速度。注意局部性，將常用數據放到一起。如果你的編程語言允許（為 Java 感到遺憾 ），可以消除指針雕鏤（pointer-chasing）來支持值控制。

譯註：指針雕鏤（Pointer-chasing）程序：該程序中會遍歷一個由指針鏈在一起的數據結構，即一個鏈表。但是在遍歷的過程中會不斷的引起內存操作。因為下一個元素總不在 Cache 中。

編碼

常規

1.不要想當然地去構建，確保你所加入的每個特性都有客戶在用。

2.謹慎地控制依賴。為了某個效果而引入的庫，可能會幫你節省一個小時，但也會導致更多地方被破壞——部署、版本控制、安全性、日誌記錄、意外的進程死亡。

3.當為個人或小團體開發的時候，把出現的問題累積起來，然後一次性全部解決（或者扔掉代碼庫，然後重新啟動）。當為大型團隊開發時，永遠都不要讓問題堆積，代碼庫應該始終處於新的開發人員可以看懂的狀態，他們會說：「我知道這是做什麼的，也知道如何更改它」（代碼的）閱讀者/編寫者的比例結果是這樣的：初始代碼的編寫多過閱讀，因此可讀性不那麼重要，但成熟代碼的閱讀多過編寫。（當你要求開發前一種初始代碼去獲得用戶、資金和存活了，轉換到後一種成熟代碼中去就是給閱讀者留下的操練了。）

歡迎大家補充。

看完本文有收穫？請轉發分享給更多人

關注「程序員的那些事」，提升編程技能

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！