《高效程序員的45個習慣——敏捷開發修煉之道》讀書總結

截止到如今本身已經有了3年多的敏捷團隊實踐，包括有一年多的敏捷團隊管理經驗。我的對敏捷仍是比較推崇的，可是必需要注意結合實際進行落地，不然就成了邯鄲學步。其中我感受落地的重點就是千萬不要生搬硬套敏捷的實施條款，而是去理解其精髓去融匯貫通。剛好《高效程序員的45個習慣——敏捷開發修煉之道》就給了咱們這麼一個機會去深刻了解敏捷的精髓，在第二次讀此書之際我對書中內容進行了些總結概括，分享給你們

---

第1章：什麼是敏捷？

「無論路走了多遠，錯了就要從新返回。」

• 敏捷意味着能夠快速適應變化。

• 敏捷開發宣言：一種把以人爲本、團隊合做、快速響應變化和可工做的軟件做爲宗旨的開發方法。

• 人員：它並不要求全部人都是有經驗的專業人員，但必須具備專業的工做態度——每一個人都盡最大可能作好本身的工做。

• 開發需持續不斷，持續地推動系統前進和完善。

一句話總結敏捷：敏捷開發就是在一個高度協做的環境中，不斷地使用反饋進行自我調整和完善。

第2章：態度決定一切

「選定了要走的路，就是選定了它通往的目的地。」

• 在敏捷團隊中，你們的重點是作事。你應該把重點放到解決問題上，而不是在指責犯錯者上面糾纏。

• 團隊成員在一塊兒工做，應互相幫助，而不是互相指責。

• 壓力會迫使你走捷徑，只看眼前利益，可是請記住：欲速則不達。

• 一個大型系統你天然不可能搞明白全部代碼，可是你能夠從更高的層面來了解大部分代碼的功能。

• 對事不對人：在一個須要緊密合做的開發團隊中，若是能稍加註意禮貌對待他人，將會有益於整個團隊關注真正有價值的問題，而不是勾心鬥角，誤入歧途。

• 工做中不感情用事是須要剋制力的，而你須要能展示出成熟大度來。

• 作正確的事。要誠實，要有勇氣去說出實情。

一句話總結：專業的態度應該着眼於項目和團隊的積極成果。關注我的和團隊的成長，圍繞最後的成功開展工做。

第3章：學無止境

「即便你已經在正確的道路上，但若是隻是中止不前，也仍然會被淘汰出局。」

• 如何才能跟上技術變化的步伐呢？

  • 迭代和增量式的學習；

  • 瞭解最新行情；

  • 參加本地的用戶組活動；

  • 參加研討會議；

  • 如飢似渴的閱讀；

  
  

• 你不須要精通全部技術，但要清楚知道行業的動向，從而規劃你的項目和職業生涯。

• 一個學習型的團隊纔是較好的團隊。

• 新技術會讓人感到有一點恐懼。你確實須要學習不少東西。已有的技能和習慣爲你打下了很好的基礎，但不能依賴它們。

• 爲了解決問題，你須要很好地瞭解系統的全局。

• 許多不成功的項目中，基本上都是隨意安排工做計劃，沒有任何規律，那樣的隨機安排很難處理。項目開發須要有一致和穩定的節奏。

一句話總結：在一個企業化的社會中，只有一我的會爲你負責——你本身。是否能跟上變化，徹底取決於你本身。

第4章：交付用戶想要的軟件

「沒有任何計劃在遇敵後還能繼續執行。」

• 業務應用須要開發者和業務負責人互相配合來開發。這種配合的感受就應該像一種良好、誠實的工做關係。

• 設計能夠分爲兩層：戰略和戰術。前期的設計屬於戰略，一般只有在沒有深刻理解需求的時候須要這樣的設計。更確切的說，它應該只描述整體戰略，不該該深刻到具體的細節。

• 在考慮引入新技術或框架以前，你須要找到須要解決的問題，接下來考慮以下幾個方面:

  • 這個技術框架真能解決這個問題嗎？

  • 你將會被它拴住嗎？

  • 維護成本是多少？

  
  

• 保證你的系統隨時能夠編譯、運行、測試、部署、演示。

• 提前集成，頻繁集成。代碼集成是主要的風險來源。要想規避這個風險，只有提前集成，持續而有規律地進行集成。

• 提前實現自動化部署。

• 使用演示得到頻繁的反饋。

• 大部分用戶都是但願如今就有一個夠用的軟件，而不是一年以後獲得一個超級好的軟件。

• 肯定使產品可用的核心功能，而後把它們放在生產環境中，越早交到用戶手裏越好。

• 讓團隊和客戶一塊兒，真正地在當前項目中工做，作具體實際的評估。由客戶控制他們要的功能和預算。

一句話總結：敏捷——成功的軟件開發方法——取決於你識別和適應變化的能力。只有這樣纔有可能在預算以內及時完成開發，建立真正符合用戶需求的系統。

第5章：敏捷反饋

「一步行動，賽過千萬專家的意見。」

• 爲了應對代碼的變化，你須要持續得到代碼健康狀態的反饋：它是在作你指望的事情嗎？最近一次修改有沒有無心破壞了什麼功能？這時你該帶上守護天使——自動化單元測試。

• 進行單元測試的理由：

  • 單元測試能及時提供反饋。

  • 單元測試讓你的代碼更加健壯。

  • 單元測試是有用的設計工具。

  • 單元測試是讓你自信的後臺。

  • 單元測試是解決問題時的探測器。

  • 單元測試是可信的文檔。

  • 單元測試是學習工具。

  
  

• 人們不編寫單元測試的不少藉口都是由於代碼中的設計缺陷。一般，抗議越強烈，就說明設計越糟糕。

• 只在有具體理由的時候纔開始編碼。你能夠專一於設計接口，而不會被不少實現的細節干擾。

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

• 咱們不該該去計算工做量完成的百分比，而應該測定還剩下多少工做量沒有完成。

• 若是能一直讓下一步工做是可見的，會有助於進度度量。最好的作法就是使用待辦事項（backlog）。

• 無論它是不是產品的bug，仍是文檔的bug，或是對用戶社區理解的bug，它都是團隊的問題，而不是用戶的問題。

• 每個抱怨的身後都隱藏了一個事實。找出真相，修復真正的問題。

一句話總結：從實踐中獲得反饋，確保你明確知道項目的正確狀態，而不是主觀臆測。

第6章：敏捷編碼

「任何一個笨蛋都可以讓事情變得愈來愈笨重、愈來愈複雜、愈來愈極端。須要天才的指點以及許多的勇氣，才能讓事情向相反的方向發展。」

• 開發代碼時，應該注重可讀性，而不是隻圖本身方便。

• 做爲一個開發者，應該時刻提醒本身是否有辦法讓寫出的代碼更容易理解。

• 代碼被閱讀的次數要遠超過被編寫的次數，因此在編程時多付出一些努力來作好文檔（利用代碼自己；利用註釋），會讓你在未來受益不淺。

• 與其花費時間去提高千分之一的性能表現，也許減小開發投入，下降成本，並儘快讓應用程序上市銷售更有價值。總而言之，要想應用成功，下降開發成本和縮短上市時間一樣重要。

• 對代碼作一些持續而有用的事情，而不是作一段長時間的編程或重構。

• 開發人員更應該爲本身可以建立出一個簡單而且可用的設計而驕傲，不要進行過度設計，也不要將代碼複雜化。

• 讓類的功能儘可能集中，讓組件儘可能小。

• 保持系統靈活性的關鍵方式，是當新代碼取代原有代碼以後，其餘已有的代碼不會意識到任何差異。

一句話總結：在編寫代碼時，天天付出一點小的努力，能夠避免代碼「腐爛」，而且保證應用程序不至變得難以理解和維護。

第7章：敏捷調試

「你也許會對木匠那毫無差錯的工做印象深入。但我向你保證，事實不是這樣的。真正的高手只是知道如何亡羊補牢。」

• 把你曾經遇到的棘手問題的解決方案記錄下來，方便下次使用。不要在同一個地方跌倒兩次，也不要付出更多地時間成本查找曾經的解決方案。

• 儘可能將編譯器的警告視爲錯誤來解決，但實際中有些編輯器或第三方庫會產生一些沒法也沒必要消除的警告，你須要仔細區分。

• 識別複雜問題的第一步，是將他們從大型系統中分離出來。

• 處理或是向上傳播全部的異常，而不是忽略或者壓制。

• 一方面要提供給用戶清晰、易於理解的問題描述和解釋；另外一方面還要提供關於錯誤的詳盡技術細節來方便開發人員定位解決問題。

一句話總結：即便運做得最好的敏捷項目，也會發生錯誤，你所要作的就是提升本身的調試能力去「亡羊補牢」。

第8章：敏捷協做

「我不只發揮了本身的所有能力，還將我所仰仗的人的能力發揮到極致。」

• 使用站立會議，每一個人都應該只回答下述三個問題：

  • 昨天有什麼收穫？

  • 今天計劃要作哪些工做？

  • 面臨着哪些障礙？

  
  

• 一個真正的架構師應該指導開發團隊，提高他們的水平，以解決更爲複雜的問題。架構師也應該參與代碼編寫，一個系統的設計者也應該親自投入到實現中去。

• 實行代碼集體全部制：版本管理系統，結對編程，代碼評審都是手段。

• 分享本身的知識——付出的同時便有收穫。還能夠激勵別人得到更好的成果，並且提高了總體團隊的實力。

• 做爲一個指導者，告訴團隊成員解決問題的方法，培養他們的思惟和能力，而不是直接幫助他們解決。

• 及時通報進展與問題。讓協做者和管理者瞭解項目的進度與問題。

一句話總結：項目的成功與否，依賴與團隊中的成員如何一塊兒有效的工做，如何互動，如何管理他們的活動。全體成員的行動必需要與項目相關，反過來每一個人的行爲又會影響到項目。