# 读《高效程序员的45个习惯》
简介
这本书讲的主要是敏捷开发的好习惯。如果你是在一个小型团队做开发，那么这本书将对你十分有益。
书中对敏捷开发有一句精辟概况：敏捷开发是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
下面将是一些书中的摘录，将夹杂我个人结合实践（游戏开发）的一些思考。
做事
指责并不能修复bug，遇到问题时不应该互相追究责任，而是应该直面问题，解决问题。
互相指责必然会导致团队士气下降，对事而不对人，优先解决问题（矛盾，bug）才是王道。
欲速则不达
- Debug不要堕入简单的快速修复中，而应该理解所做的修改，并且让代码保持整洁。总之，不要急于修复一段你没有理解的代码。
跟踪变化
每天花一点时间来学习新的技术。你不需要精通所有技术，但是需要了解行业的动向，以规划你的职业生涯。
一味着守着过时的技术可能会产生依赖，难以进步。
把握开发节奏
站立进行会议，以节省会议时间。
保持舒服的迭代周期，不要搞得经常加班。
在每天结束时，测试，提交代码。
加班与否通常是一个效率问题，制定好合适的工作量，然后专注去完成它。
合理使用技术
不要重复造轮子。不要开发你能够下载到的东西。
如果有别人写好的，可靠的工具，则利用工具。
保持可以发布
每一次提交到代码仓库的代码必须保证正确。
这一点可以通过持续集成工具达到，比如jekins。
同时也需要你对每一次提交进行测试，对代码负责。
通过演示获得反馈
- 需求是会不断变更的。每次迭代过后都需要进行一次演示（DEMO），获取反馈，以修正下一次迭代。
使用短迭代，增量发布
将迭代周期尽可能缩短，这样能让人感到十分有效率，且能频繁获得反馈。
每一次的迭代应该有一个具体的小目标，通过增量式的而不是一蹴而就的来检查每个目标的完成情况。
度量真实的进度
通过待办事项，每一天结束时，确定哪些任务完成，哪些任务没有完成。
将没有完成的任务列上优先级，然后估算剩下的工作量，一般以小时为粒度。
代码要清晰地表达意图
代码的可读性十分重要，尤其在多人合作的敏捷开发中。
代码不应该炫技，应该清晰明确表明意图。
代码可以通过命名的规范来进行自说明，而不需要依靠多余的注释。
注释最好写在函数接口和极其复杂（一般需要重构）逻辑处。
动态评估取舍
一件事情几乎可以永远优化下去，所以你需要判断一个平衡的点，优化到一定程度就停止。
另外，过早优化是万恶之源。因为过早优化有可能在未来并不适用，然后提前的优化增加了代码的复杂度和理解成本。
增量式编程
不要连续几小时的进行编写代码。
将大任务分解为小问题。然后一个个的去编写相关代码。
写完一个小问题的代码段后，编译运行以保证正确性，然后休息一段时间，再继续。
编写内聚的代码
将类的功能尽量集中，不要创建无所不包的大杂烩的类。
将职责尽可能明确，集中：每个类只做一件事情，然后把它做好。这样bug很容易跟踪，代码也十分容易修改。
告知，不要询问
- 将命令（可能对数据有改动）和查询（只读，不改动）分离。否则很容易出bug。
问题解决日志
- 建立一个问题（坑）和其解决方案的备忘录。以防止趟两次一样的坑。
对问题各个击破
将问题进行分离。比如可以用二分法来定位bug，将代码空间分割成两半，然后分离其中一半，看bug是否在另外一半中。
debug时，要将问题域与周边隔离开来，找到了bug原因，debug就完成了一大半。
提供有用的错误信息
- 程序发生错误时，如果在开发阶段，应该给出明显而详细的报错堆栈；如果在产品交付阶段，则应该记录下log，并找到合适的时机发送回来。
每日立会
每天早上上班前，先开站立会议，回答三个问题：
- 昨天的收获？
- 今天的计划？
- 当前有哪些问题和阻碍？
立会时间一般在10-15分钟比较理想。
小型团队可能不需要每天都碰头，两天一次或者一周两次也可以。
立会不要过多的深入细节，给出具体进度即可。
保持简单
优先使用最简单的技术。因为简单的代码更能一眼看出问题。
除非有不可辩驳的原因，否则不要使用复杂的模式和高难度技术（指针）类的东西。
简单的代码意味着没有重复代码和多余代码，且仍然能完成全部功能。
教学相长
通过详细解释自己知道的东西，也可以使自己的理解更加深入。
分享可以提高队友和自己的能力和水平，为团队增值。
做代码复查
复查的checklist：
- 代码是否能被读懂和理解？
- 代码是否有明显的错误？
- 代码是否会对其他代码产生副作用？
- 是否存在重复代码？
- 是否存在改进和优化空间？
- 代码复查必须给出反馈，然后每个人根据反馈采取行动。