優秀程式設計師的45個習慣(轉載)
阿新 • • 發佈：2019-01-11
1. 做實事
不要抱怨，發牢騷，指責他人，找出問題所在，想辦法解決。對問題和錯誤，要勇於承擔。
2. 欲速則不達
用小聰明、權宜之計解決問題，求快而不顧程式碼質量，會給專案留下要命的死角。
3. 對事不對人
就事論事，明智、真誠、虛心地討論問題，提出創新方案。
4. 排除萬難，奮勇前進
勇氣往往是克服困難的唯一方法。
學習篇
5. 跟蹤變化
新技術層出不窮並不可怕。堅持學習新技術，讀書，讀技術雜誌，參加技術活動，與人交流。要多理解新詞背後的所以然，把握技術大趨勢，將新技術用於產品開發要謹慎。
6. 對團隊投資
打造學習型團隊，不斷提高兄弟們的平均水平。
7. 懂得丟棄
老的套路和技術，該丟，就得丟。不要固步自封。
8. 打破砂鍋問到底
不斷追問，真正搞懂問題的本質。為什麼？應該成為你的口頭禪。
9. 把握開發節奏
控制好時間，養成好習慣，不要加班。
開發流程篇
10. 讓客戶做決定
讓使用者在現場，傾聽他們的聲音，對業務最重要的決策應該讓他們說了算。
11. 讓設計指導而不是操縱開發
設計是前進的地圖，它指引的是方向，而不是目的本身。設計的詳略程度應該適當。
12. 合理地使用技術
根據需要而不是其他因素選擇技術。對各種技術方案進行嚴格地追問，真誠面對各種問題。
13. 讓應用隨時都可以釋出
通過善用持續整合和版本管理，你應該隨時都能夠編譯、執行甚至部署應用。
14. 提早整合，頻繁整合
整合有風險，要儘早儘量多地整合。
15. 提早實現自動化部署
16. 使用演示獲得頻繁反饋
17. 使用短迭代，增量釋出
18. 固定價格就意味著背叛承諾
估算應該基於實際的工作不斷變化。
使用者篇
19. 守護天使
自動化單元測試是你的守護天使。
20. 先用它再實現它
測試驅動開發其實是一種設計工具。
21. 不同環境，就有不同問題
要重視多平臺問題。
22. 自動驗收測試
23. 度量真實的進度
在工作量估算上，不要自欺欺人。
24. 傾聽使用者的聲音
每一聲抱怨都隱藏著寶貴的真理。
程式設計篇
25. 程式碼要清晰地表達意圖（免費樣章連結）
程式碼是給人讀的，不要耍小聰明。
26. 用程式碼溝通
註釋的藝術。
27. 動態地進行取捨（免費樣章連結）
記住，沒有最佳解決方案。各種目標不可能面面俱到，關注對使用者重要的需求。
28. 增量式程式設計
寫一點程式碼就構建、測試、重構、休息。讓程式碼乾淨利落。
29. 儘量簡單
寧簡勿繁。如果沒有充足的理由，就不要使用什麼模式、原則和特別的技術。
30. 編寫內聚的程式碼
類和元件應該足夠小，任務單一。
31. 告知，不要詢問
多用訊息傳遞，少用函式呼叫。
32. 根據契約進行替換
委託往往優於繼承。
除錯篇
33. 記錄問題解決日誌（免費樣章連結）
不要在同一地方摔倒兩次。錯誤是最寶貴的財富。
34. 警告就是錯誤
忽視編譯器的警告可能鑄成大錯。
35. 對問題各個擊破（免費樣章連結）
分而治之是電腦科學中最重要的思想之一。但是，要從設計和原型階段就考慮各部分應該能夠很好地分離。
36. 報告所有的異常
37. 提供有用的錯誤資訊（免費樣章連結）
稍微多花一點心思，出錯的時候，將給你帶來極大便利。
團隊協作篇
38. 定期安排會面時間
常開會，開短會。
39. 架構師必須寫程式碼（免費樣章連結）
不寫程式碼的架構師不是好架構師。好的設計都來自實際程式設計。程式設計可以帶來深入的理解。
40. 實行程式碼集體所有制
讓開發人員在系統不同區域中不同的模組和任務之間輪崗。
41. 成為指導者
教學相長。分享能提高團隊的總體能力。
42. 讓大家自己想辦法（免費樣章連結）
指引方向，而不是直接提供解決方案。讓每個人都有機會在幹中學習。
43. 準備好後再共享程式碼
不要提交無法編譯或者沒有通過單元測試的程式碼！
44. 做程式碼複查
複查對提高程式碼質量、減少錯誤極為重要。
45. 及時通報進展與問題（免費樣章連結）
主動通報，不要讓別人來問你。
不要抱怨，發牢騷，指責他人，找出問題所在，想辦法解決。對問題和錯誤，要勇於承擔。
2. 欲速則不達
用小聰明、權宜之計解決問題，求快而不顧程式碼質量，會給專案留下要命的死角。
3. 對事不對人
就事論事，明智、真誠、虛心地討論問題，提出創新方案。
4. 排除萬難，奮勇前進
勇氣往往是克服困難的唯一方法。
學習篇
5. 跟蹤變化
新技術層出不窮並不可怕。堅持學習新技術，讀書，讀技術雜誌，參加技術活動，與人交流。要多理解新詞背後的所以然，把握技術大趨勢，將新技術用於產品開發要謹慎。
6. 對團隊投資
打造學習型團隊，不斷提高兄弟們的平均水平。
7. 懂得丟棄
老的套路和技術，該丟，就得丟。不要固步自封。
8. 打破砂鍋問到底
不斷追問，真正搞懂問題的本質。為什麼？應該成為你的口頭禪。
9. 把握開發節奏
控制好時間，養成好習慣，不要加班。
開發流程篇
10. 讓客戶做決定
讓使用者在現場，傾聽他們的聲音，對業務最重要的決策應該讓他們說了算。
11. 讓設計指導而不是操縱開發
設計是前進的地圖，它指引的是方向，而不是目的本身。設計的詳略程度應該適當。
12. 合理地使用技術
根據需要而不是其他因素選擇技術。對各種技術方案進行嚴格地追問，真誠面對各種問題。
13. 讓應用隨時都可以釋出
通過善用持續整合和版本管理，你應該隨時都能夠編譯、執行甚至部署應用。
14. 提早整合，頻繁整合
整合有風險，要儘早儘量多地整合。
15. 提早實現自動化部署
16. 使用演示獲得頻繁反饋
17. 使用短迭代，增量釋出
18. 固定價格就意味著背叛承諾
估算應該基於實際的工作不斷變化。
使用者篇
19. 守護天使
自動化單元測試是你的守護天使。
20. 先用它再實現它
測試驅動開發其實是一種設計工具。
21. 不同環境，就有不同問題
要重視多平臺問題。
22. 自動驗收測試
23. 度量真實的進度
在工作量估算上，不要自欺欺人。
24. 傾聽使用者的聲音
每一聲抱怨都隱藏著寶貴的真理。
程式設計篇
25. 程式碼要清晰地表達意圖（免費樣章連結）
程式碼是給人讀的，不要耍小聰明。
26. 用程式碼溝通
註釋的藝術。
27. 動態地進行取捨（免費樣章連結）
記住，沒有最佳解決方案。各種目標不可能面面俱到，關注對使用者重要的需求。
28. 增量式程式設計
寫一點程式碼就構建、測試、重構、休息。讓程式碼乾淨利落。
29. 儘量簡單
寧簡勿繁。如果沒有充足的理由，就不要使用什麼模式、原則和特別的技術。
30. 編寫內聚的程式碼
類和元件應該足夠小，任務單一。
31. 告知，不要詢問
多用訊息傳遞，少用函式呼叫。
32. 根據契約進行替換
委託往往優於繼承。
除錯篇
33. 記錄問題解決日誌（免費樣章連結）
不要在同一地方摔倒兩次。錯誤是最寶貴的財富。
34. 警告就是錯誤
忽視編譯器的警告可能鑄成大錯。
35. 對問題各個擊破（免費樣章連結）
分而治之是電腦科學中最重要的思想之一。但是，要從設計和原型階段就考慮各部分應該能夠很好地分離。
36. 報告所有的異常
37. 提供有用的錯誤資訊（免費樣章連結）
稍微多花一點心思，出錯的時候，將給你帶來極大便利。
團隊協作篇
38. 定期安排會面時間
常開會，開短會。
39. 架構師必須寫程式碼（免費樣章連結）
不寫程式碼的架構師不是好架構師。好的設計都來自實際程式設計。程式設計可以帶來深入的理解。
40. 實行程式碼集體所有制
讓開發人員在系統不同區域中不同的模組和任務之間輪崗。
41. 成為指導者
教學相長。分享能提高團隊的總體能力。
42. 讓大家自己想辦法（免費樣章連結）
指引方向，而不是直接提供解決方案。讓每個人都有機會在幹中學習。
43. 準備好後再共享程式碼
不要提交無法編譯或者沒有通過單元測試的程式碼！
44. 做程式碼複查
複查對提高程式碼質量、減少錯誤極為重要。
45. 及時通報進展與問題（免費樣章連結）
主動通報，不要讓別人來問你。