《高效程序員的45個習慣》總結

一、敏捷——高效軟件開發之道 

• 敏捷的精神：它要求團隊中的每一個人（包括與團隊合作的人）都具備職業精神，并積極地期望項目能夠獲得成功。它并不要求所有人都是有經驗的專業人員，但必須具有專業的工作態度——每個人都希望盡最大可能做好自己的工作。 
  
• 敏捷開發就是在一個高度協作的環境中，不斷地使用反饋進行自我調整和完善。 
  

二、態度決定一切 

1、 做事

• 符合標準不是結果。敏捷團隊重結果勝于重過程。 
  
• 指責不能修復bug 。把矛頭對準問題的解決辦法，而不是人。

2、 欲速則不達

• 不要墜入快速的簡單修復之中。要投入時間和精力保持代碼的整潔、敞亮。 
  
• 不要急于修復一段沒能真正理解的代碼。這種 +1/-1  的病癥始于無形，但是很快會讓代碼一團糟。要解決真正的問題，不要治標不治本。 
  
• 所有的大型系統都非常復雜，因此沒有一個人能完全明白所有的代碼。除了深入了解你正在開發的那部分代碼之外，你還需要從更高的層面來了解大部分代碼的功能，這樣就可以理解系統各個功能塊之間是如何交互的。

3、 對事不對人

• 我們每個人都能有一些極好的創新想法，同樣也會萌生一些很愚蠢的想法。 
  
• 脫離實際的反方觀點會使爭論變味。若對一個想法有成見，你很容易提出一堆不太容易發生或不太實際的情形去批駁它。這時，請先捫心自問：類似問題以前發生過嗎？是否經常發生？

4、 排除萬難，奮勇前進 

• 做正確的事。要誠實，要有勇氣去說出實情。有時，這樣做很困難，所以我們要有足夠的勇氣。

三、學無止境 

5、 跟蹤變化

• 跟蹤技術變化。你不需要精通所有技術，但需要清楚知道行業的動向，從而規劃你的項目和職業生涯。 
  
• 許多新想法從未變得羽翼豐滿，成為有用的技術。即使是大型、熱門和資金充裕的項目也會有同樣的下場。你要正確把握自己投入的精力。

6、 對團隊投資

• 你參加了一個課程或者研討班之后，所學的知識如果不用，往往就會忘記。所以，你需要和其他團隊成員分享所學的知識，把這些知識引入團隊中。 
  
• 堅持有計劃有規律地舉行講座。持續、小步前進才是敏捷。稀少、間隔時間長的馬拉松式會議非敏捷也。

7、 懂得丟棄

• 打破舊習慣很難，更難的是自己還沒有意識到這個問題。丟棄的第一步，就是要意識到你還在使用過時的方法，這也是最難的部份。

8、 打破沙鍋問到底

• 不停地問為什么。不能只滿足于別人告訴你的表面現象。要不停地提問直到你明白問題的根源。 
  
• 你可能會跑題，問了一些與主題無關的問題，這樣的問題是沒有任何幫助的。要問到點子上。

9、 把握開發節奏

• 解決任務，在事情變得一團糟之前。保持事件之間穩定重復的間隔，更容易解決常見的重復任務。 
  
• 在每天結束的時候，測試代碼，提交代碼，沒有殘留的代碼。

四、交付用戶想要的軟件

10、 讓客戶做決定

• 讓你的客戶做決定。開發者、經理或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言，向他們詳細解釋遇到的問題，并讓他們做決定。

11、 讓設計指導而不是操縱開發

• 一旦開始了編碼，一切都會改變。設計及其代碼實現會不停地發展和變化。 
  
• 好的設計應該是正確的，而不是精確的。也就是說，它描述的一切必須是正確的，不應該涉及不確定或者可能會發生變化的細節。它是目標，不是具體的處方。
• 即使初始的設計到后面不再管用，你仍需設計：設計行為是無價的。正如美國總統艾森豪威爾所說：“計劃是沒有價值的，但計劃的過程必不可少。”在設計過程中學習是有價值的，但設計本身也許沒有太大的用處。

12、 合理地使用技術

• 考慮引入新技術或框架之前，要先考慮幾個方面：
  • 這個技術框架真能解決這個問題嗎？
  • 你將會被它拴住嗎？一些技術是賊船，一旦你使用了它，就會被它套牢，再也不可能回頭了。
  • 維護成本是多少？
• 每一門技術都會有優點和缺點，無論它是開源的還是商業產品、框架、工具或語言，一定要清楚它的利弊。
  

13、 保持可以發布

• 任何時候只要你沒有準備好，那就是敵人進攻你的最佳時機。 
  
• 在團隊里工作，修改一些東西的時候必須很謹慎。你要時刻警惕，每次改動都會影響系統的狀態和整個團隊的工作效率。

14、 提早集成，頻繁集成

• 絕不要做大爆炸式的集成。 
  
• 提早集成，頻繁集成。代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。 
  
• 如果你集成得不夠頻繁（比如一周一次，甚至更糟），也許就會發現整天在解決代碼集成帶來的問題，而不是在專心寫代碼。如果你集成的問題很大，那一定是做得不夠頻繁。

15、 提早實現自動化部署

• 一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不同的機器上用不同的文件測試依賴的問題。質量保證人員要像測試應用一樣測試部署。 
  
• 部署一個緊急修復的bug 應該很簡單，特別是在生產服務器的環境中。你知道這會發生，而且你不想在壓力之下，在凌晨三點半，你還在手工部署系統。

16、 使用演示獲得頻繁反饋

• 維護一份項目術語表。在項目的開發過程中，從術語表中為程序結構——類、方法、模型、變量等選擇合適的名字，并且要檢查和確保這些定義一直符合用戶的期望。 
  
• 清晰可見的開發。在開發的時候，要保持應用可見（而且客戶心中也要了解）。每隔一兩周，邀請所有的客戶，給他們演示最新完成的功能，積極獲得他們的反饋。

17、 使用短迭代，增量發布

• 增量開發。發布帶有最小卻可用功能塊的產品。每個增量開發中，使用1 ～ 4 周左右迭代周期。

18、 固定的價格就意味著背叛承諾

• 軟件項目天生就是變化無常的，不可重復。如果要提前給出一個固定的價格，就幾乎肯定不能遵守開發上的承諾。 
  
• 基于真實工作的評估。讓團隊和客戶一起，真正地在當前項目中工作，做具體實際的評估。由客戶控制他們要的功能和預算。 
  

五、敏捷反饋 

19、 守護天使

• 一些開發者會對單元測試有意見：畢竟，有“測試”這個詞在里面，毫無疑問這應該是其他人的工作。從現在開始，忘掉“測試”這個詞。就把它看作是一個極好的、編寫能產生反饋的代碼的技術。 
  
• 使用自動化的單元測試。好的單元測試能夠為你的代碼問題提供及時的警報。如果沒有到位的單元測試，不要進行任何代碼設計和代碼修改。 
  
• 人們不編寫單元測試的很多借口都是因為代碼中的設計缺陷。通常，抗議越強烈，就說明設計越糟糕。

20、 先用它再實現它

• 設計的一個重點是：確定什么是成功地實現特定功能的最低成本。程序員很容易走向另一個極端——一些不必要的過于復雜的事情——測試優先會幫助我們，防止我們走偏。
• 先用它再實現它。將TDD 作為設計工具，他會為你帶來更簡單更有實效的設計。

21、 不同環境，就有不同問題

• 不同環境，就有不同問題。使用持續集成工具，在每一種支持的平臺和環境中運行單元測試。要積極地尋找問題，而不是等問題來找你。

22、 自動驗收測試

• 為核心的業務邏輯創建測試。讓你的客戶單獨驗證這些測試，要讓它們像一般的測試一樣可以自動運行。

23、 度量真實的進度

• 我們不應該去計算工作量完成的百分比，而應該測定還剩下多少工作量沒有完成。不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的待辦事項。 
  
• 在你最后真正完成一項任務時，要清楚知道完成這個任務真正花費的時間。在為下一個任務估計工作量時，可以根據這次經驗調整評估。

24、 傾聽用戶的聲音

• 不管它是否是產品的bug ，還是文檔的 bug ，或者是對用戶社區理解的 bug ，它都是團隊的問題，而不是用戶的問題。
• 每一個抱怨的背后都隱藏了一個事實。找出真相，修復真正的問題。 
  

六、敏捷編碼 

25、 代碼要清晰地表達意圖

• 開發代碼時，應該更注重可讀性，而不是只圖自己方便。代碼閱讀的次數要遠遠超過代碼編寫的次數，所以在編寫的時候值得花點功夫讓它讀起來更簡單。 
  
• 要編寫清晰的而不是討巧的代碼。向代碼閱讀者明確表明你的意圖，可讀性差的代碼一點都不聰明。

26、 用代碼溝通

• 用注釋溝通。使用細心選擇的、有意義的命名。用注釋描述代碼意圖和約束。注釋不能代替優秀的代碼。

27、 動態評估取舍

• 動態評估權衡。考慮性能、便利性、生產力、成本和上市時間。如果性能表現足夠了，就將注意力放在其他因素上。不要為了感覺上的性能提升或者設計的優雅，而將設計復雜化。
• 如果現在投入額外的資源和精力，是為了將來可能得到的好處，要確認投入一定要得到回報（大部分情況下，是不會有回報的）。 
  
• 過早的優化是萬惡之源。

28、 增量式編程

• 在很短的編輯、構建、測試循環中編寫代碼。這要比花費長時間僅僅做編寫代碼的工作好得多。可以創建更加清晰、簡單、易于維護的代碼。 
  
• 要像重構你的代碼那樣，重構你的測試，而且要經常重構測試。

29、 保持簡單

• 開發可以工作的、最簡單的解決方案。除非有不可辨駁的原因，否則不要使用模式、原則和高難度技術之類的東西。 
  
• 要將目標牢記在心：簡單、可讀性高的代碼。強行讓代碼變得優雅與過早優化類似，統一會產生惡劣的影響。

30、 編寫內聚的代碼

• 讓類的功能盡量集中，讓組件盡量小。要避免創建很大的類或組件，也不用創建無所不包的大雜燴類。

31、 告知，不要詢問

• 面向過程的代碼取得信息，然后做出決策。面向對象的代碼讓別的對象去做事情。 
  
• 作為某段代碼的調用者，開發人員絕對不應該基于被調用對象的狀態來做出任何決策，更不能去改變該對象的狀態。這樣的邏輯應該是被調用對象的責任，而不是你的。 
  
• 告知，不要詢問。不要搶別的對象或是組件的工作。告訴它做什么，然后盯著你自己的職責就好了。

32、 根據契約進行替換

• 通過替換代碼來擴展系統。通過替換遵循接口契約的類，來添加并改進功能特性。要多使用委托而不是繼承。 
  

七、敏捷調試

33、 記錄問題解決日志

• 維護一個問題及其解決方案的日志。保留解決方案是修復問題過程的一部分，以后發生相同或類似問題時，就可以很快找到并使用了。 
  
• 如果通過搜索Web ，發現沒人曾經遇到同樣的問題，那也許是搜索的方法有問題。

34、 警告就是錯誤

• 將警告視為錯誤。簽入帶有警告的代碼，就跟簽入有錯誤或者沒有通過測試的代碼一樣，都是極差的做法。簽入構建工具中的代碼不應該產生任何警告信息。

35、 對問題各個擊破

• 很多應用的代碼在編寫時沒有注意到隔離問題這一點，使得分離變得特別困難。此時，最好花一些時間把關注的代碼提取出來，而且創建一個可讓其工作的測試環境。 
  
• 對問題各個擊破。在解決問題時，要將問題域與其周邊隔離開，特別是在大型應用中。

36、 報告所有的異常

• 處理或是向上傳播所有的異常。不要將它們壓制不管，就算是臨時這樣做也不行。在寫代碼時要估計到會發生的問題。

37、 提供有用的錯誤信息 

• 展示有用的錯誤信息。提供更易于查找錯誤細節的方式。發生問題時，要展示出盡量多的支持細節，不過別讓用戶陷入其中。 
  

八、敏捷協作 

38、 定期安排會面時間

• 使用立會。立會可以讓團隊達成共識。保證會議短小精悍不跑題。 
  
• 要保證會議議題不發散，每個人都應該只回答下述三個問題：
  • 昨天有什么收獲？
  • 今天計劃要做哪些工作？
  • 面臨著哪些障礙？ 
    
• 雖然大多數團隊需要每天都碰頭，但對于小型團隊來說，這樣做可能有點過頭了。不妨兩天舉行一次，或者一周兩次，這對小團隊來說足夠了。

39、 架構師必須寫代碼

• 設計會隨著時間而演進，如果忽略了應用的現狀（它的具體實現），要想設計一個新的功能，或者完成某個功能的提升，是不可能的。 
  
• 優秀的設計從積極的程序員那里開始演化。積極的編程可以帶來深入的理解。不要使用不愿意編程的架構師——不知道系統的真實情況，是無法展開設計的。 
  
• 不要運行任何人單獨進行設計，特別是你自己。

40、 實行代碼集體所有制

• 在團隊中實行任務輪換制，讓每個成員都可以接觸到不同部分的代碼，可以提升團隊整體的知識和專業技能。

41、 成為指導者

• 成為指導者。分享自己的知識很有趣——付出的同時便有收貨。還可以激勵別人獲得更好的成果，而且提升了整個團隊的實力。 
  
• 如果一直在就同一個主題向不同的人反復闡述，不妨記錄筆記，此后就此主題寫一篇文章，甚至是一本書。

42、 允許大家自己想辦法

• 給別人解決問題的機會。指給他們正確的方向，而不是直接提供解決方案。每個人都能從中學到不少東西。

43、 準備好后再共享代碼

• 準備好后再共享代碼。絕不要提交尚未完成的代碼。故意簽入編譯未通過或是沒有經過單元測試的代碼，對項目來說，應被視為玩忽職守的犯罪行為。

44、 做代碼復查

• 復查所有的代碼。對于提升代碼質量和降低錯誤率來說，代碼復查是無價之寶。如果以正確的方式進行，復查可以產生非常實用而高效的成功。要讓不同的開發人員在每個任務完成后復查代碼。 
  
• 同樣的功能，不同開發人員的代碼實現可能不同。差異并不意味著不好。除非你可以讓某段代碼變得更好，否則不要隨意批評別人的代碼。 
  
• 如果不及時跟進討論中給出的建議，代碼復查是沒有實際價值的。可以安排跟進會議，或者使用代碼標記系統，來標識需要完成的工作，跟蹤已經處理完的部分。

45、 及時通報進展與問題

• 及時通報進展與問題。發布進展狀況、新的想法和目前正在關注的主題。不要等著別人來問項目狀態如何。

九、尾聲：走向敏捷

Bug Fix