敏捷开发：高效程序员的45个习惯【转载】

一、态度决定一切

1、最高优先级应该是解决问题，而不是寻找罪魁祸首。指责不能修复Bug。

2、欲速则不达：要投入时间和精力保持代码的整洁、敞亮。在不深入了解真正的问题以及可能的后果，就快速修改代码，这样只是解决表面问题，最终会引发大问题。

3、对事不对人：不带个人情绪并不是盲目地接受所有的观点，用合适的词和理由去解释为什么不赞同。不要谴责，没有评判，只要简单表达自己的观点。因为负面的评论会扼杀创新。

4、排除万难，奋勇前进：重构低质量代码或许需要很大勇气，但是如果你对此妥协，那么问题就会进一步恶化下去。在没有理解代码时，不要轻易地否定和重写它们。那不是勇气，而是鲁莽。

二、学无止境：既要学习新技术、新方法，同时也要摒弃陈旧和过时的开发方法

1、跟踪变化：迭代和增量式的学习，不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。

2、对团队投资：团队成员能力互补。

3、懂得丢弃：在学习一门新技术时，要丢弃会阻止你前进的旧习惯。

4、打破砂锅问到底：不停地问为什么，不能只满足于别人告诉你的表面现象，同时在提问之前想好提问的理由，因为对方很可能会反问“为什么你问这个问题”

5、把握开发节奏：在每天结束的时候，测试代码，提交代码，没有残留的代码，以固定、有规律的长度进行迭代。

三、交付用户想用的软件：提早集成、频繁集成，保持可以发布、易于向用户部署

1、让客户做决定：coder不应该做业务方面的决定，用业务负责人能够理解的语言，解释遇到的问题，并让他们做决定。

2、让设计指导而不是操纵开发：设计满足实现即可，不必过于详细。严格的需求-设计-代码-测试源于理想化的瀑布式开发，敏捷开发可以避免过度的设计。

3、合理地使用技术：不要开发你能下载到的东西，每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或者语言，一定要清楚它的利弊。

4、保持可以发布：记住一个简单的工作流程，在本地运行测试—检出最新的代码—提交代码。

5、提早继承、频繁集成：让子系统不停地增长，不去做系统集成，就等于一步一步把自己置于越来越大的风险中。

6、提早实现自动化部署。

7、使用演示获得频繁反馈。

8、使用短迭代、增量发布：短迭代使人感觉专注具有效率，能看到一个实际并且确切的目标。严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。

9、固定的价格就意味着背叛承诺。

四 敏捷反馈

1、守护天使：编写能产生反馈的代码。NUnit，JUnit

2、先用它再实现它：TDD，Test，Driven，Development测试驱动开发，编程之前，先写测试，可以让你设计出更有用、更一致的接口。

3、不同环境，就有不同问题：要求在多个平台，多个编译环境下进行测试。

4、自动验收测试。

5、度量真实的进度：判断工作进度最好是根据实际已花费的时间而不是估计的时间。

6、倾听用户的声音：客户每一个抱怨的背后都隐藏了一个事实，找出真相、修复真正的问题。

五 敏捷编码

1、代码要清晰地表达意图：代码清晰程度的优先级排在执行效率之前，要编写清晰的而不是讨巧的代码。

2、用代码沟通：不要用注释来包裹你的代码。使用细心挑选的名称和清晰的执行路径，代码可以不需要注释。

3、动态评估取舍：没有最佳解决方案，只有最合适的解决方案，在性能、生产力、优雅、成本以及上市时间之间动态评估权衡。

4、增量式编程：采用增量式编程和测试，会倾向于创建更小的方法和更具内聚性的类，不是在埋头盲目地一次性编写一大堆代码。相反，你会经常评估代码质量，并不是地进行许多小调整，而不是一次修改许多东西。

5、保持简单：不要让自己被迫进行过分设计，也不要将代码过分复杂化，应该为自己能够创建出一个简单并且可用的设计而骄傲。除非有不可辩驳的原因，否则不要使用设计模式、原则和高难度技术之类的东西。

6、编写内聚的代码：让类的功能尽量集中，让组件尽量小。

7、告知，不要询问：不要抢别的对象或是组件的工作，告诉它做什么，而不是提他做什么。

8、根据契约进行替换：Liskov替换规则，任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而使用者不必知道任何差异。针对is-a用继承，针对has-a或uses-a用委托。

六、敏捷调试

1、记录问题解决日志：不要在同一处跌到两次，不妨维护一个保持曾遇到的问题以及对应解决方案的日志。

　　　　可以使用如下条目：

　　　　1）问题发生日期

　　　　2) 问题简述

　　　　3）解决方案详细描述

　　　　4）引用文章或网址

　　　　5）任何代码片段、设置或对话框的截屏

2、警告就是错误：签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样。

3、对问题各个击破：在解决问题时，要将问题域与其周边隔离开，在向问题发起攻击之前，先查找你的问题解决日志。

4、报告所有的异常：并且处理每一个异常。

5、提供有用的错误信息：提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用于陷入其中。

七、敏捷协作

1、定期安排会面时时间。

2、架构师必须写代码。

3、实行代码集体所有制：轮换完成系统不同领域中不同模块的不同任务。 possible?

4、成为指导者：在自己擅长的方面帮助团队成员提升水平的同时也提高自己。

5、允许大家自己想办法：作为指导者，应该鼓励、引领大家思考如何解决问题，而不是直接给出答案。

6、准备好后再共享代码：绝不要提交尚未完成的代码，或者是未通过测试的代码。

7、做代码复查：代码刚刚完成时，是寻找问题的最佳时机。

　　　　最基本的检查列表：

　　　　1）代码能否被读懂和理解?

　　　　2）是否有任何明显的错误？

　　　　3）代码是否会对应用的其他部分产生不良影响？

　　　　4）是否存在重复的代码？

　　　　5）是否存在可以改进或重构的部分？

8、即使通报进展与问题：完不成提前说。

八、走向敏捷

1、要一个新的习惯。

2、用新的习惯拯救濒临失败的项目。