「我不是卓越的程式設計師，我只不過是一個有著卓越習慣的程式設計師。」技術大牛 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.當為個人或小團體開發的時候，把出現的問題累積起來，然後一次性全部解決（或者扔掉程式碼庫，然後重新啟動）。當為大型團隊開發時，永遠都不要讓問題堆積，程式碼庫應該始終處於新的開發人員可以看懂的狀態，他們會說：“我知道這是做什麼的，也知道如何更改它”（程式碼的）閱讀者/編寫者的比例結果是這樣的：初始程式碼的編寫多過閱讀，因此可讀性不那麼重要，但成熟程式碼的閱讀多過編寫。（當你要求開發前一種初始程式碼去獲得使用者、資金和存活了，轉換到後一種成熟程式碼中去就是給閱讀者留下的操練了。）
歡迎大家補充。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
