优秀的程序员都有哪些习惯？
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.當為個人或小團體開發的時候，把出現的問題累積起來，然后一次性全部解決（或者扔掉代碼庫，然后重新啟動）。當為大型團隊開發時，永遠都不要讓問題堆積，代碼庫應該始終處于新的開發人員可以看懂的狀態，他們會說：“我知道這是做什么的，也知道如何更改它”（代碼的）閱讀者/編寫者的比例結果是這樣的：初始代碼的編寫多過閱讀，因此可讀性不那么重要，但成熟代碼的閱讀多過編寫。（當你要求開發前一種初始代碼去獲得用戶、資金和存活了，轉換到后一種成熟代碼中去就是給閱讀者留下的操練了。）
?
歡迎大家補充。
總結
以上是生活随笔為你收集整理的优秀的程序员都有哪些习惯？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 属性的表示方法和对象的枚举
- 下一篇： linux openh264 编译,在L