## 《高效程序員的45個習慣——敏捷開發修煉之道》 ### 序一 一般誤認為敏捷就是快，越快就是越敏捷。豈不知它本來要以 **lightweight processes**（輕量級過程）命名，只不過有些參會者不喜歡被看做是在拳臺上跳來跳去的輕量級拳手，所以才用了“敏捷”。 ### 序二 敏捷不是目的，只是手段。只要某個手段適合某個場景，有助于提升質量，提高交付能力，提高開發者水平…… 成功 = 策略 + 堅持 ### 譯者序 > 武功者，包括內功、外功、武術技擊之術總和。有形的動作，如支撐格拒，姿勢回環，變化萬千，外部可見，授受教易，晨操夕練，不難熟練。而無形的內功指內部之靈惠素質，及識、膽、氣、勁、神是也，此乃與學練者整個內在世界的學識水平密切相關，是先天之慧根悟性與后天智能的總成，必須尋得秘籍方可煉成。 > <p style="text-align: right">——《武林秘籍大全》</p> <br/> >[success] 迭代開發，價值優先 分解任務，真實進度 > 站立會議，交流暢通 用戶參與，調整方向 > 結對編程，代碼質量 測試驅動，安全可靠 > 持續集成，盡早反饋 自動部署，一鍵安裝 > 定期回顧，持續改進 不斷學習，提高能力 ### 第一章 敏捷 —— 高效開發軟件之道 > 不管路走了多遠，錯了就要返回 重構 —— 在功能不變的情況下，重新設計部分代碼，改善代碼的質量。 迭代 —— 確定一小塊時間（一周左右）的計劃，然后按時完成他們。 ### 第二章 態度決定一切 #### 1. 做事 出現問題不要一味抱怨，而要問問“為了解決或緩解這個問題，我能夠做些什么”。 > 指責不能修復 BUG。 ##### **切身感受** 勇于承認自己不知道答案，這會讓人感覺放心。一個重大的錯誤應該被當作是一次學習而不是指責他人的機會。團隊成員們在一起工作，應互相幫助，而不是互相指責。 ##### **平衡的藝術** * “這不是我的錯”，這句話不對。“這都是你的錯”，這句話更不對。 * 如果你沒有犯任何錯誤，就說明你可能沒有努力去工作。 * 如果一個團隊成員的行為一再傷害了團隊，則他表現得很不職業。那么，他就不是在幫助團隊向解決問題的方向前進。這種情況下，我們必須要求他離開這個團隊。 * 如果大部分團隊成員（特別是開發領導者）的行為都不職業，并且他們對團隊目標不感興趣，你就應該主動從這個團隊中離開。 #### 2. 欲速則不達 在工作壓力下，不去深入了解真正的問題以及可能的后果，就快速修改代碼，這樣只是解決表面問題，最終會引發大問題。**不要墜入快速的簡單修復中，要投入時間和精力保持代碼的整潔、敞亮。** 不要孤立地編碼，要花些時間 **閱讀** 別人的代碼，閱讀代碼的頻率越高越好。實行 **代碼復審** 是發現 bug 最好的方法之一。 ##### **平衡的藝術** * 你必須要理解一塊代碼是如何工作的，但是不一定需要成為專家。只要你能使用它進行有效的工作就足夠了，不需要把它當作畢生事業。 * 如果一個團隊成員宣布，有一塊代碼其他人很難看懂，這就意味著他很難維護。 * 不要急于修復一段沒能真正理解的代碼。要解決真正的問題，不要治標不治本。 * 大型系統需要從更高層面上了解大部分代碼的功能，這樣可以理解系統各功能塊之間是如何交互的。 #### 3. 對事不對人 讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好。 ##### **切身感受** 一個團隊能夠很公正地討論一些方案的優點和缺點，你不會因為拒絕了太多缺陷的方案而傷害別人，也不會因為采納了某個不甚完美（但是更好的）解決方案而被人嫉恨。 ##### **平衡的藝術** * 盡力貢獻自己的好想法，如果你的想法沒有被采納也無需生氣。不要因為只是想體現自己的想法而對擬定的好思路畫蛇添足。 * 脫離實際的反方觀點會使爭論變味。若對一個想法有成見，你很容易提出一堆不太可能發生或不太實際的情形去批駁他。這時，請先捫心自問：類似問題以前發生過嗎？是否經常發生？ * 在開始尋找最好的解決方案之前，大家對“最好”的含義要達成共識。在開發者眼中的最好，不一定是用戶認為最好的，反之亦然。 * 只有 **更好**，沒有 **最好**。盡管“最佳實踐”這個術語到處在用，但實際上不存在“最佳”，只有在某個特定條件下更好的實踐。 * 不帶個人情緒并不是要盲目地接受所有的觀點。用合適的詞和理由去解釋為什么你不贊同這個觀點或方案，并提出明確的問題。 ### 第六章 敏捷編碼 #### 31 告知不要詢問 不要搶別的對象或是組件的工作。告訴它做什么，然后盯著你自己的職責就好了。 **將命令與查詢分離開來。** 面向過程的代碼取得信息，然后做出決策。面向對象的代碼讓別的對象去做事情。P121