<<高效程序员的45个习惯>>

 

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

Venkat Subramaniam/Andy Hunt 著

钱安川/郑柯 译

敏捷开发：

迭代开发，价值优先；分解任务，真实进度

站立会议，交流畅通；用户参与，调整方向

结对编程，代码质量；测试驱动，安全可靠

持续集成，尽早反馈；自动部署，一键安装

定期回顾，持续改进；不断学习，提高能力

敏捷开发宣言

我们正通过亲身实践和帮助他人实践，揭示了一些更好的软件开发方法，通过这项工作，我们认为：

个体和交互胜过过程和工具；

可工作的软件胜过面面俱到的文档；

客户协作胜过合同谈判；

响应变化胜过遵循计划；

虽然右项也有价值，但我们认为左项具有更大的价值。

敏捷宣言作者 ，2001年版权所有

态度决定一切

做事——把矛头对准问题的解决方法，而不是人，这是真正有用处的正面效应。

欲速则不达——不要坠入快速的简单修复之中，要投入时间和精力保持代码的整洁敞亮。

对事不对人——

排除万难，奋勇前进——做正确的事，要诚实，要有勇气说出实情。

学无止境

跟踪变化——你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。

对团队投资——提供你和团队学习的更好平台，通过午餐会议可以增进每个人的知识和技能，并帮助大家聚集在一起进行沟通交流，唤起人们对技术和技巧的激情，将会对项目大有裨益。

懂得丢弃——学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。

打破砂锅问到底——不停地问为什么，不能只满足于别人告诉你的表面现象，要不停地提问直到你明白问题的根源。

把握开发节奏——解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。

交付用户想要的软件

让客户做决定

让设计指导而不是操纵开发——好设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计（或者设计师）操纵。

合理地使用技术——根据需要选择技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并真实回答。

保持可以发布——

提早集成，持续集成——

提早实现自动化部署——一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要向测试应用一样测试部署。

使用演示获得频繁反馈——

使用短迭代，增量发布——发布最小却可用功能块的产品。每个增量开发中，使用1-4周左右的迭代周期。

固定的价格意味着背叛承诺——基于真实工作的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。

敏捷反馈

守护天使——使用自动化的单元测试。好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何设计和代码修改。

先用它再实现它——将TDD作为设计工具，它会为你带来更简单更有实效的设计。

不同环境，就有不同问题——使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。

自动验收测试——为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般测试一样可以自动运行。

度量真实的进度——度量剩下的工作量。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。

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

敏捷编码

代码要清晰地表达意图——要编写清晰而不是讨巧的代码。向代码阅读者明确表明你的意图。可读性差的代码一点都不聪明。

用代码沟通——使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能代替优秀的代码。

动态评估取舍——

增量式编程——在很短的编辑/构建/测试循环中编写代码。

保持简单——开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式/原则和高难度技术之类的东西。

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

告知，不要询问——不要抢别的对象或是组件的工作，告诉它做什么，然后盯着你自己的职责就可以了。

根据契约进行替换——通过替换遵循接口契约的类，来添加并改进功能特性，要多使用委托而不是继承。

Liskov替换原则告诉我们：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。

敏捷调试

记录问题解决日志——维护一个问题及其解决方法的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似的问题，就可以很快找到并使用了。

警告就是错误——

对问题各个击破——在解决问题时，要将问题域与其周边隔离开，特别是在大型应用中。

报告所有的异常——处理或是向上传播所有的异常。

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

敏捷协作

定期安排会议时间——使用立会。立会可以让团队达成共识，保证会议短小精悍不跑题。

架构师必须写代码——

实行代码集体所有制——让开发人员轮换完成系统不同领域中不同模块的不同任务。

成为指导者——分享自己的知识很有趣。

允许大家自己想办法——

准备好后再共享代码——绝不要提交尚未完成的代码，故意签入编译未通过或者没有通过单元测试的代码，对项目来说，应被视作玩忽职守的犯罪行为。

做代码复查——

及时通报进展与问题——发布进展状况、新的想法和目前正在关注的问题，不要等着别人来问项目状态如何。