高效程序员的45个习惯——敏捷开发修炼之道

这本书一直被很多人推荐，就从学校图书馆借阅后阅读，也从中有所收获吧。

每章小结

第一章敏捷——高效软件开发之道

不管路走了多远，错了就要重新返回。
开发须持续不断，切勿时断续时续。
持续注入能量。
敏捷开发就是在一个高度协作的环境中，不断使用反馈进行自我反馈和完善。
敏捷，重构，迭代。
态度决定一切，学无止境，交付用户想要的软件，敏捷反馈，敏捷编码，敏捷调试，敏捷协作。
建立wiki，版本控制，单元测试，自动构建。
先易后难，掌握方法的平衡。

第二章态度决定一切

为做事而工作，欲速则不达，防微杜渐，对事不对人，排除万难，奋勇前进。
团队之间进行代码复审。
使用单元测试，不要求快速简单的修复。

第三章学无止境

即使正确的轨道，停滞不前，依然会被淘汰。
跟踪变化，对团队投资，懂得丢弃，需要打破砂锅问到底，把握开发节奏。
迭代增量式学习，了解最新行情，参加一些社区讨论，如饥似渴阅读。
团队需要多聚聚讨论方向等多方面问题。
旧的技术也要适时丢弃，沉舟侧畔千帆过，病树前头万木春。
多问几个为什么，表面简单的事情不简单。
定期整理代码，不要拖沓不整理，也不能次次整理，有规律的迭代代码进度。

第四章交付用户想要的软件

计划赶不上变化，没有哪个方案是最终就敲定的。
多和客户交流，让客户做些决定。
提早集成，频繁集成。
自动化部署，随时可以发布。
多向用户演示获得反馈。
短迭代，增量发布。
客户即使不懂，也要让他们了解他们能了解的东西。
软件开发前的设计要有，但无需太详细。
合理使用技术，无论新旧，不能盲目选择，套用。
对于能下载到的代码，第一次学习要敲一遍，之后要灵活运用。
要使得每次提交的代码是随时可以部署运行的。
写代码时要多测试，自动化单元测试，团队之间要及时频繁的集成，当然不是一小时就来集成一次。
自动化部署应当在不同操作系统，环境下都去做。
演示获得客户的反馈需求，而不是先自己闭门造车，才使得不会浪费时间成本。
需要在软件开发过程中勤写日志，会写日志。计划太详细，容易完蛋。
成本难以估量，保持固定数，但需要实时评估。

第五章敏捷反馈

一步行动，胜过千万专家的意见。
经常监督，频繁反馈。
先用它再实现它。
多使用Junit之类软件，有一个自动构建的机器。
不同的环境，可能会出现不同的问题。在每一个不同的平台来实现。
度量真实的进度，不要欺骗自己或者团队。
倾听出用户的抱怨。

第六章敏捷编码

代码要清晰表达出意图，团队之间代码要互相沟通。
增量式编程，编写内聚的代码，降低耦合。
代码设计要尽量简单，利于交接和维护。
代码中具体的数值要有实际的意义，如宏定义，枚举来说明。
善于写注释，而不是乱写注释。
留意写一些技术文档，如JavaDoc
对有些功能的取舍要有度，不能走左右极端，过分追求设计或者性能。
增量式编程，复杂的问题逐步解决。
解决问题在解决一个问题后，方法可能是复杂的，想想有没有简便的方法。而不是过分追求新的框架或者设计。
编写内聚的代码，比如将衣柜分层，提高内聚性。
当有疑问时，自己主动去寻求问题的解决方案，而不是上来就找答案。

第七章敏捷调试

真正的高手知道如何亡羊补牢。
记录问题的日志，记录解决方法。
记住警告其实就是错误，有时也致命。
对问题各个击破，报告所有的异常。
向用户提供有用的错误信息，贴心的错误信息。

第八章敏捷协作

一个团队，需要定期安排会议时间，经常碰面。
架构师也必须加入到项目中去。
代码可以由SVN来管理，集体共享。
小组成员可以各抒己见，不能一言堂。
团队之间做好代码审计，遇到困难及时通报。
会议可以是立会的形式，问题如下：做了什么，计划做什么，有哪些疑惑。
会议不要商讨解决方案，而是提出总体的问题，问题单独解决。
自己手中的代码需要确保没有问题后再提交，不要提交错误的代码。

第九章走向敏捷

一灯能除千年暗，一智能灭万年愚。
养成好的习惯。
再烂手的项目，需要全面彻底的方式改革。
管理者做好立会，彼此讨论，架构师也要动起来，不能纸上谈兵，代码审查很重要，客户也要加入项目。
做好版本控制，单元测试，自动构建。
多看书。
掌握好方法的平衡。
程序员需要养成良好的习惯，提高效率，而不是瞎忙。