高效程序員的45個習慣

1. 做事。與其推卸責任，不如去解決問題。
2. 欲速則不達。要增量編程，步步爲營。沒真正理解一段代碼之前，別急着去修改它。
3. 對事不對人。掌握提問、反駁、爭論的技巧，注意說話口吻，不能帶個人情緒的接受或反駁別人觀點。
4. 排除萬難，勇奮前進。要真誠、有勇氣地說出實情和想法。當你發現某段代碼很混亂，需要重構，好，說出來。
5. 跟蹤技術變化。你要不斷的學習新技術，瞭解新行情，不求精通。
6. 對團隊投資。團隊間經常互相交流，小型的內部知識講座，技術討論，設計方案討論等等。
7. 懂得丟棄。技術、思想、方案、習慣等等，不好的別捨不得。
8. 打破沙鍋問到底。知其然，還要知其所以然。多看看好的代碼是怎麼實現的。
9. 把握開發節奏。當每天都加班加點，累的半死，就要注意了。尋找最佳的迭代週期。
10. 讓客戶做決定。業務方面開發者不應想當然，沒有客戶參與的項目多半得返工重做，費錢費力。
11. 讓設計指導而不是操縱開發。設計文檔不應過於詳細，而只是框架或大體思路。因爲一旦開始編碼，一切都會改變。
12. 合理地使用技術。採用現有框架何以節約成本加快進度，但要權衡利弊。
13. 保持可以發佈。讓你的項目處於隨時可編譯、運行、測試和部署。增加功能時做好版本管理，別讓項目處於既不可發佈，又不可撤銷狀態。
14. 提早集成，頻繁集成。集成會有風險，但早出現總比晚出現好，讓每次集成代碼修改儘量的少，保證項目可控。
15. 提早實現自動化部署。一開始就進行全面部署，讓問題儘早浮現。
16. 使用演示獲得頻繁反饋。讓用戶看到系統在不斷完善，新功能不斷添加，用演示也和獲得用戶的反饋。
17. 使用短迭代，增量發佈。及時發佈功能，保證功能不背離客戶的需求。
18. 固定的價格就意味着背叛承諾。軟件項目是變化無常的，很難準確地預測成本，保證項目在可控範圍即可，如必須提供價格，你需要真正地評估技巧。
19. 守護天使。有效單元測試可以及時發現問題，提供警報。
20. 先用它再實現它。先考慮你會怎樣用它，再去用代碼實現它，就是說，有具體理由纔開始編碼。專注與設計接口。
21. 不同環境，就有不同問題。在不同的機器，不同的系統上測試你的代碼。
22. 自動驗收測試。從用戶那裏獲得測試答案。
23. 度量真實的進度。客觀地預測工作量，通常，工作量是你認爲的2倍。如你認爲1個星期可以完成的功能你應該安排2個星期。
24. 傾聽用戶的聲音。每一個抱怨的背後都隱藏了一個事實。
25. 代碼要清晰地表達意圖。編寫清晰的代碼，而不是展示你的小聰明，過早的優化是萬惡之源。
26. 用代碼溝通。註釋應是簡明扼要的，說明爲什麼會這樣寫代碼。好的代碼是讓自己或他人可以讀懂自己一年前寫的代碼，而且只讀一遍。
27. 動態評估取捨。性能、生產力、優雅、成本及上市時間，要根據現在狀態動態評估權衡。
28. 增量式編程。別馬不停蹄地連續幾個小時地編程，循環重構、測試你的代碼。
29. 保持簡單。把寫出簡單、可讀性高的代碼作爲目標。但你覺得代碼中沒有一行是多餘的，功能也全部實現時就對了。
30. 編寫內聚的代碼。讓類的功能儘可能集中，讓組件儘量小；這樣易於查錯和修改。
31. 告知，不要詢問。各有其職，不要搶其他對象或組件的工作，盯好自己的職責。
32. 根據契約進行替換。Liskov替換原則：任何繼承後的對象，必須何以不知差異地替換被使用的基類對象。掌握好繼承和委託的用法。
33. 記錄問題解決日誌。不要讓自己再同一個地方摔倒兩次。
34. 警告就是錯誤。讓代碼沒有任何錯誤和警告。
35. 對問題各個擊破。在大型項目中，將問題域與周邊隔離排查。
36. 報告所有異常。不是所有問題都應該拋出異常，設計時考慮好由誰處理異常，要傳播不能處理的異常。
37. 提供有用的錯誤信息。沒有必要等待異常拋出來發現問題。
38. 定期安排會面時間。每天早上一個10至15分鐘的立會是個不錯選擇。
39. 架構師必須寫代碼。不知道系統的真實情況，是無法展開設計的。
40. 實行代碼集體所有制。所有制並不意味着可隨心所欲，到處破壞。不是所有場合都適用。
41. 成爲指導者。給予別人教導，也是提升自己學識的一種方式。
42. 允許大家自己想辦法。給別人解決問題的機會。
43. 準備好後再共享代碼。絕不要提交尚未完成的代碼。
44. 做代碼複查。正確的代碼複查方式可以提升代碼質量和降低錯誤率。
45. 及時通報進展與問題。發佈進展狀況、新的想法和關注的主題，而不是等別人來詢問。