# 《敏捷开发》读后总结

前端开发在软件工程中，占据着很重要的一环。上游对接的是视觉、设计、后端等，下游对应的是用户反馈。更多时候，开发不是单纯的写好代码完成需求就行，写出优雅可读性高的代码只是硬技术之一。还需要在整个软件生产过程中发挥个人软技能，比如如何让团队运作高效，如何让产品可持续优化迭代。毕竟所有人都需要对结果负责，而不是对过程负责。

在软件工程中，你可能已经应用上了该书的一些总结或技巧，只是不自知罢了，笔者在阅读这本书时产生了许多共鸣。以下跟随这本经典图灵奖丛书——《高效程序员的45个习惯-敏捷开发修炼之道》，为敏捷之道提供指引。

# 态度决定一切

• 做事
  • 把矛头对准解决问题的办法，而不是人
  • 敏捷团队重成果胜于重过程
• 欲速则不达
  • 不要坠入快速的简单修复中
  • 深层次的思考是区别优秀程序员和拙劣代码工人的区别
  • 投入时间和精力保持代码整洁、敞亮
• 对事不对人
  • 开会技巧 1. 设定最终期限。防止陷入无休止的争辩中。没有最好的方案，只有更合适的方案。设定期限能在为难时做出决断。 2. 逆向思维。每个人都需要意识到权衡的必要性。尽可能找到优点最多缺点最少的方案，少带个人情感。 3. 设立仲裁人。确保会议正常进行，打算大篇会议之外的讨论以及假大空式发言。 4. 支持已经做出的决定。
• 排除万难，奋勇前进

# 敏捷编码

• 代码要清晰地表达意图
  • 开发代码时，更应该注重可读性，而不是图自己方便。
  • 让自己和别人可以读懂一年前的代码，而且只读一遍就知道它的运行机制。
• 用代码沟通
  • 代码被阅读的次数远远多于被编写的次数。
  • 代码优雅而清晰。比如变量名使用正确、空格使用得当、逻辑分离清晰以及表达式简洁。
  • 良好而有意义的命名方式。
  • 代码自解释。比如：枚举
  • 注释描述代码意图和约束。
• 动态评估取舍
  • 根据现有资源，对手上问题评估，选出最合适的解决方案。
  • 过早的优化是万恶之源。
• 增量式编程
  • 经常评估代码质量，并不时进行许多小调整。
  • 留心许多可以改进的微小方面，改善代码可读性。
• 保持简单
  • 目标：简单、可读性高的代码。
  • 简单的解决方案，也必须满足功能需要。
  • 太简洁不等于简单，那样无法达到沟通的目的。
• 编写内聚的代码
  • 让类的功能尽量集中，让组件尽量小。
  • 每个类或组件只做一件事，职责需要清晰。
• 告知，不要询问
  • 查询和修改分离，单个对象做好自己的职责就好。
• 根据契约进行替换
  • 基于接口，替换代码来扩展系统。
  • 多使用委托而不是继承。

# 敏捷调试

再好的敏捷项目，都会发生bug、错误等。这时候需要进行敏捷调试。调试时面对的真正问题，是无法用固定的时间来限制。有些项目可能调试一天也没有找到问题。对于一个项目来说，这种没有准确把握时间的消耗是不可接受的。

• 记录解决问题的日志。将曾经遇到的问题，记录在wiki上进行维护，大家一起维护这份日志，或许从里面会有一些解题思路。注意记录时的关键字。原则上记录问题的时间不能超过解决问题的时间。
• 警告就是错误。尽量减少错误信息
• 对问题各个击破。尽量减少耦合，得到单元测试的模块。
• 报告所有的异常。不要压制异常，及时抛出。
• 提供有用的错误信息。

# 敏捷协作

团队之间的协作，保持高效率。

• 定期安排会面时间
  • 立会可以让团队达成共识。
  • 保证会议短小精悍不跑题。
  • 时间尽量在早上，也不要在刚上班。
• 架构师必须写代码
  • 新系统的设计者必须亲自投入到实现中
• 实行代码集体所有制
• 成为指导者
  • 激励别人，让他们更出色，同时提升团队整体实力
  • 解释自己知道的，可以让自己理解更加深入
  • 别人提出问题，可以发现不同视角
  • 帮助团队成员提升水平同时提高自己
  • 不必局限自己团队，也可以是个人blog或一小段代码
  • 成为指导者，意味着分享，而不是固守
• 允许大家自己想办法
  • 引领大家思考如何解决问题
  • 指出正确方向，而不是直接提出解决方案
• 准备好后再共享代码
  • 不要提交未完成的代码
• 做代码复查
  • 代码复查可以得到质量较高且稳定的代码
  • 无论经验丰富多与少，都需要对代码复查
  • 代码复查需要思考，而不是单纯的变量名和代码风格。检查列表：
    • 代码能否被读懂和理解？
    • 是否有明显错误？
    • 代码是否对其他部分有不良影响？
    • 是否存在重复代码？
    • 是否可以改进和重构？
• 及时通报进展与问题

# 引入敏捷

• 管理者指南
  • 让大家知道敏捷开发是让开发人员工作变得轻松
  • 项目周转
    • 立会
    • 孤立对架构师带到项目中，参与日常
    • 开展代码复查
    • 让客户和用户也参与进来
  • 基本环境
    • 版本控制
    • 单元测试
    • 自动构建
  • 敏捷协作
• 程序员指南
  • 单元测试保证质量
  • 以身作则