《敏捷开发》读后总结
前端开发在软件工程中，占据着很重要的一环。上游对接的是视觉、设计、后端等，下游对应的是用户反馈。更多时候，开发不是单纯的写好代码完成需求就行，写出优雅可读性高的代码只是硬技术之一。还需要在整个软件生产过程中发挥个人软技能，比如如何让团队运作高效，如何让产品可持续优化迭代。毕竟所有人都需要对结果负责，而不是对过程负责。
在软件工程中，你可能已经应用上了该书的一些总结或技巧，只是不自知罢了，笔者在阅读这本书时产生了许多共鸣。以下跟随这本经典图灵奖丛书——《高效程序员的45个习惯-敏捷开发修炼之道》，为敏捷之道提供指引。
态度决定一切
- 做事
- 把矛头对准解决问题的办法，而不是人
- 敏捷团队重成果胜于重过程
- 欲速则不达
- 不要坠入快速的简单修复中
- 深层次的思考是区别优秀程序员和拙劣代码工人的区别
- 投入时间和精力保持代码整洁、敞亮
- 对事不对人
- 开会技巧
- 设定最终期限。防止陷入无休止的争辩中。没有最好的方案，只有更合适的方案。设定期限能在为难时做出决断。
- 逆向思维。每个人都需要意识到权衡的必要性。尽可能找到优点最多缺点最少的方案，少带个人情感。
- 设立仲裁人。确保会议正常进行，打算大篇会议之外的讨论以及假大空式发言。
- 支持已经做出的决定。
- 排除万难，奋勇前进
敏捷编码
- 代码要清晰地表达意图
- 开发代码时，更应该注重可读性，而不是图自己方便。
- 让自己和别人可以读懂一年前的代码，而且只读一遍就知道它的运行机制。
- 用代码沟通
- 代码被阅读的次数远远多于被编写的次数。
- 代码优雅而清晰。比如变量名使用正确、空格使用得当、逻辑分离清晰以及表达式简洁。
- 良好而有意义的命名方式。
- 代码自解释。比如：枚举
- 注释描述代码意图和约束。
- 动态评估取舍
- 根据现有资源，对手上问题评估，选出最合适的解决方案。
- 过早的优化是万恶之源。
- 增量式编程
- 经常评估代码质量，并不时进行许多小调整。
- 留心许多可以改进的微小方面，改善代码可读性。
- 保持简单
- 目标：简单、可读性高的代码。
- 简单的解决方案，也必须满足功能需要。
- 太简洁不等于简单，那样无法达到沟通的目的。
- 编写内聚的代码
- 让类的功能尽量集中，让组件尽量小。
- 每个类或组件只做一件事，职责需要清晰。
- 告知，不要询问
- 根据契约进行替换
- 基于接口，替换代码来扩展系统。
- 多使用委托而不是继承。
敏捷调试
再好的敏捷项目，都会发生bug、错误等。这时候需要进行敏捷调试。调试时面对的真正问题，是无法用固定的时间来限制。有些项目可能调试一天也没有找到问题。对于一个项目来说，这种没有准确把握时间的消耗是不可接受的。
- 记录解决问题的日志。将曾经遇到的问题，记录在wiki上进行维护，大家一起维护这份日志，或许从里面会有一些解题思路。注意记录时的关键字。原则上记录问题的时间不能超过解决问题的时间。
- 警告就是错误。尽量减少错误信息
- 对问题各个击破。尽量减少耦合，得到单元测试的模块。
- 报告所有的异常。不要压制异常，及时抛出。
- 提供有用的错误信息。
敏捷协作
团队之间的协作，保持高效率。
- 定期安排会面时间
- 立会可以让团队达成共识。
- 保证会议短小精悍不跑题。
- 时间尽量在早上，也不要在刚上班。
- 架构师必须写代码
- 实行代码集体所有制
- 成为指导者
- 激励别人，让他们更出色，同时提升团队整体实力
- 解释自己知道的，可以让自己理解更加深入
- 别人提出问题，可以发现不同视角
- 帮助团队成员提升水平同时提高自己
- 不必局限自己团队，也可以是个人blog或一小段代码
- 成为指导者，意味着分享，而不是固守
- 允许大家自己想办法
- 引领大家思考如何解决问题
- 指出正确方向，而不是直接提出解决方案
- 准备好后再共享代码
- 做代码复查
- 代码复查可以得到质量较高且稳定的代码
- 无论经验丰富多与少，都需要对代码复查
- 代码复查需要思考，而不是单纯的变量名和代码风格。检查列表：
- 代码能否被读懂和理解？
- 是否有明显错误？
- 代码是否对其他部分有不良影响？
- 是否存在重复代码？
- 是否可以改进和重构？
- 及时通报进展与问题
引入敏捷
- 管理者指南
- 让大家知道敏捷开发是让开发人员工作变得轻松
- 项目周转
- 立会
- 孤立对架构师带到项目中，参与日常
- 开展代码复查
- 让客户和用户也参与进来
- 基本环境
- 敏捷协作
- 程序员指南