高效程序员的45个习惯, Venkat Subramaniam
敏捷不是只有“快速”的意思。
所有学习上的成功，只靠两件事：“策略”和“坚持”。
开发软件不是线性、确定的过程。
需求永不停止且永远变化
敏捷意味着可以快速地适应变化。
敏捷开发宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
敏捷工具箱：
Wiki：知识管理
版本控制
单元测试
自动构建
做事，把矛头对准问题的解决办法，而不是人，这是真正有用处的正面效应。
出现错误，不要先去追究是造成了错误，优先考虑“如何解决问题”。
欲速则不达，要投入时间和精力保持代码的整洁、敞亮
跟踪变化，不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯
懂得丢弃，在学习一门新技术的时候，要丢去会阻止你前进的旧习惯。毕竟，汽车要比马车强得多。
让客户做决定，开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
保持可以发布，保证你的系统随时可以编译、运行、测试并立即部署。
提早集成，频繁集成，代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
提早实现自动化部署，使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖问题。质量保证人员要像测试应用一样测试部署。
使用演示获得频繁反馈，在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一周或者两周，邀请所有客户，给他们演示最新完成的功能，积极获得他们的反馈。
使用短迭代，增量发布，发布带有最小却可用功能块的产品。
先用它再实现它，使用测试驱动开发（TDD）作为设计工具，它会为你带来更简单更实效的设计。
倾听用户的声音，每一个抱怨的背后都隐藏了一个事实，找出真相，修复真正的问题。
代码要清晰地表达意图，向代码阅读者明确表明你的意图。可读性差的代码一点也不聪明。
用代码沟通，使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。
好的注释：
增量式编程，在很短的编辑/构建/测试循环中编写代码，这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
编写内聚的代码，让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
里氏替换原则
Liskov替换原则：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。换句话说，某段代码如果使用了基类中的方法，就必须能够使用派生类的对象，而且自己不必进行任何修改。
继承是OO建模中被滥用最多的概念之一。记住，继承是一种很“重”的重用方法，一般不轻易使用。
当使用继承时，想想里氏替换原则。思考是否应该使用继承。如果不符合里氏替换原则，还希望重用基类中的代码，可以使用聚合（组合，委托）方式，即在类中包含一个对象，并且该对象是其他类的实例，开发人员将责任委托给所包含的对象来完成。
is-a关系使用继承；has-a或者uses-a关系使用委托。
要多使用委托而不是继承
记录问题解决日志，保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。
问题解决日志：
记得将日志保存为计算机可搜索的模式。
提供有用的错误信息，提供更多易于查找错误细节的方式，发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。
定期安排会面时间。使用立会(站着开的会议)可以让团队达成共识。保证会议短小精悍不跑题。
架构师必须写代码。优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况。是无法展开设计的。
实行代码集体所有制。让开发人员轮换完成系统不同领域中不同模块的不同任务。
成为指导者。分享自己的知识很有趣——付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
做代码复查（Code Review）。对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成果。要让不同的开发人员在每个任务完成后复查代码。
代码复查的关注点：
及时通报进展与问题。发布进展状况，新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。