## 《高效程序员的45个习惯——敏捷开发修炼之道》 ### 序一 一般误认为敏捷就是快，越快就是越敏捷。岂不知它本来要以 **lightweight processes**（轻量级过程）命名，只不过有些参会者不喜欢被看做是在拳台上跳来跳去的轻量级拳手，所以才用了“敏捷”。 ### 序二 敏捷不是目的，只是手段。只要某个手段适合某个场景，有助于提升质量，提高交付能力，提高开发者水平…… 成功 = 策略 + 坚持 ### 译者序 > 武功者，包括内功、外功、武术技击之术总和。有形的动作，如支撑格拒，姿势回环，变化万千，外部可见，授受教易，晨操夕练，不难熟练。而无形的内功指内部之灵惠素质，及识、胆、气、劲、神是也，此乃与学练者整个内在世界的学识水平密切相关，是先天之慧根悟性与后天智能的总成，必须寻得秘籍方可炼成。 > <p style="text-align: right">——《武林秘籍大全》</p> <br/> >[success] 迭代开发，价值优先 分解任务，真实进度 > 站立会议，交流畅通 用户参与，调整方向 > 结对编程，代码质量 测试驱动，安全可靠 > 持续集成，尽早反馈 自动部署，一键安装 > 定期回顾，持续改进 不断学习，提高能力 ### 第一章 敏捷 —— 高效开发软件之道 > 不管路走了多远，错了就要返回 重构 —— 在功能不变的情况下，重新设计部分代码，改善代码的质量。 迭代 —— 确定一小块时间（一周左右）的计划，然后按时完成他们。 ### 第二章 态度决定一切 #### 1. 做事 出现问题不要一味抱怨，而要问问“为了解决或缓解这个问题，我能够做些什么”。 > 指责不能修复 BUG。 ##### **切身感受** 勇于承认自己不知道答案，这会让人感觉放心。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作，应互相帮助，而不是互相指责。 ##### **平衡的艺术** * “这不是我的错”，这句话不对。“这都是你的错”，这句话更不对。 * 如果你没有犯任何错误，就说明你可能没有努力去工作。 * 如果一个团队成员的行为一再伤害了团队，则他表现得很不职业。那么，他就不是在帮助团队向解决问题的方向前进。这种情况下，我们必须要求他离开这个团队。 * 如果大部分团队成员（特别是开发领导者）的行为都不职业，并且他们对团队目标不感兴趣，你就应该主动从这个团队中离开。 #### 2. 欲速则不达 在工作压力下，不去深入了解真正的问题以及可能的后果，就快速修改代码，这样只是解决表面问题，最终会引发大问题。**不要坠入快速的简单修复中，要投入时间和精力保持代码的整洁、敞亮。** 不要孤立地编码，要花些时间 **阅读** 别人的代码，阅读代码的频率越高越好。实行 **代码复审** 是发现 bug 最好的方法之一。 ##### **平衡的艺术** * 你必须要理解一块代码是如何工作的，但是不一定需要成为专家。只要你能使用它进行有效的工作就足够了，不需要把它当作毕生事业。 * 如果一个团队成员宣布，有一块代码其他人很难看懂，这就意味着他很难维护。 * 不要急于修复一段没能真正理解的代码。要解决真正的问题，不要治标不治本。 * 大型系统需要从更高层面上了解大部分代码的功能，这样可以理解系统各功能块之间是如何交互的。 #### 3. 对事不对人 让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。 ##### **切身感受** 一个团队能够很公正地讨论一些方案的优点和缺点，你不会因为拒绝了太多缺陷的方案而伤害别人，也不会因为采纳了某个不甚完美（但是更好的）解决方案而被人嫉恨。 ##### **平衡的艺术** * 尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。 * 脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳他。这时，请先扪心自问：类似问题以前发生过吗？是否经常发生？ * 在开始寻找最好的解决方案之前，大家对“最好”的含义要达成共识。在开发者眼中的最好，不一定是用户认为最好的，反之亦然。 * 只有 **更好**，没有 **最好**。尽管“最佳实践”这个术语到处在用，但实际上不存在“最佳”，只有在某个特定条件下更好的实践。 * 不带个人情绪并不是要盲目地接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。 ### 第六章 敏捷编码 #### 31 告知不要询问 不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。 **将命令与查询分离开来。** 面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。P121