高效程序员的45个习惯

敏捷宣言：

个体和交互胜过过程和工具
可工作的软件胜过面面俱到的文档
客户协作胜过合同谈判
响应变化胜过遵循计划

敏捷是一种一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法，敏捷方法可以快速地响应变化，它强调团队合作，人们专注于具体可行的目标，这就是敏捷精神。敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

没有任何计划在遇敌后还能继续执行，对于软件行业，真正的敌人是变化，敏捷，一种成功的软件开发方法，成功与否取决于你识别和适应变化的能力

敏捷工具箱：

WIKI：用于项目组内知识共享

版本控制：项目开发中所有的产物，都要有版本控制系统统一管理

单元测试：用代码来检查代码，是开发者获得反馈的主要来源

自动构建：又称为持续集成

习惯一：做事

出了问题，最高优先级应该是解决问题，指责不能修复bug，如果你说的话只是让事态更复杂，或者只是一味的抱怨，或者伤害了他人的感情，那么你无意中在给问题火上浇油，把矛头对准问题的解决办法，而不是人，这是真正有用处的正面效应。用于承认自己不知道答案，会让人感觉放心，一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起，因互相帮助，而不是互相指责

习惯二：欲速则不达

不要坠入快速的简单修复之中，要投入时间和精力保持代码的整洁、敞亮，代码复审和单元测试是不错的实践

习惯三：对事不对人

不要否定别人的想法，而是提出引导性的问题，让他意识到自己的问题

做出决策有两种极端：1.一个人说了算   2.需要全票通过

有一些技巧可以解决这类问题：

1.设定最终期限：实现制定好时间限制，没有最好的答案，只有更合适的答案，有最终期限可以避免讨论无休止的进行

2.逆向思维：如果找不到最合适的方案，就找缺点最少的方案

3.设立仲裁人：仲裁人可以防止明星员工操纵狐疑，并及时打断假大空式的发言，仲裁人应该专注于调停，而不是发表自己的观点

4.支持已经做出的决定：一旦方案被确定了，每个团队成员都必须通力合作，努力实现这个方案

让我们骄傲的应该是解决了问题，而不是比较谁出的主意更好

注意点：

1.尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气，不要因为只是想体现自己的想法而对拟定的好思路画蛇添足

2.若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳他

习惯四：排除万难，奋勇前进

要诚实，要有勇气说出实情，有时，这样做很困难，所以我们要有足够的勇气

如果你说天要塌下来了，但其他团队成员不赞同，反思一下，也许你是对的，但你没有解释清楚

如果你说天要塌下来了，当其他团队成员不赞同，考虑一下，也许他们是对的

习惯五：跟踪变化

唯有变化是永恒的

如何更上技术变化的步伐，有几种建议：迭代和增量式的学习、了解最新行情、参加本地的用户组活动、参加研讨会议、如饥似渴的阅读

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

习惯六：对团队投资

找出团队中的高手擅长的领域，帮助其他的团队成员在这些方面迎头赶上

唤起人们对技术和技巧的激情，将会对项目大有裨益

习惯七：懂得丢弃

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

习惯八：打破沙锅问到底

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

习惯九：把握开发节奏

在很多不成功的项目中，基本上都是随意安排工作计划，没有任何的规律，那样的随机安排很难处理，你根本不知道明天将会发生什么。

保持事件之间稳定重复的间隔，更容易解决常见的重复任务。

项目开发需要有一致和稳定的节奏。编辑、运行测试、代码复审，一致的迭代，然后发布。如果知道什么时候开始下一个节拍，跳舞就会更容易。

习惯十：让客户做决定

开发者、经理或者业务分析师不应该做业务方面的决定，用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定

习惯十一：让设计知道而不是操纵开发

设计可以分为两层：战略和战术，前期的设计属于战略，通常只有在没有深入理解需求的时候需要这样设计，更确切的说，它应该只描述总体战略，不应深入到具体的细节，不要一开始就进行战术设计，它的重点是集中在单个的方法或数据类型上，这是，更适合讨论如何设计类的职责

好的设计应该是正确的，而不是精确的，不应该涉及不确定或者可能会发生变化的细节，它是目标，不是具体的处方

计划是没有价值的，但计划的过程是必不可少的

习惯十二：合理地使用技术

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

新技术就应该像是新的工具，可以帮助你更好的工作，它自己不应该成为你的工作

习惯十三：保持可以发布

提交代码的流程：

1.在本地运行测试：先保证代码可以编译，并且能通过所有的单元测试。接着确保系统中的其他测试都可以通过

2.检出最新的代码

3.提交代码

保证你的系统随时可以编译、运行、测试并立即部署

习惯十四：提早集成，频繁集成

代码集成是主要的风险来源，要想规避这个风险，只有提早集成，持续而有规律地进行集成

成功的集成意味着所有的单元测试不停地通过

通常，每天要和团队其他的成员一起集成代码好几次，比如平均每天5-10次

习惯十五：提早实现自动化部署

一开始就进行全面部署，而不是等到项目的后期

使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题，质量保证人员要像测试应用一样测试部署

习惯十六：使用演示获得频繁反馈

在开发的时候，要保持应用可见，每隔一周或者两周，邀请客户，给他们演示最新完成功能，积极获得他们的反馈

习惯十七：使用短迭代，增量发布

迭代开发时在小且重复的周期里，完成各种开发任务：分析、设计、实现、测试和获得反馈，所以叫做迭代

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

没有规定一个迭代必须要紧挨着一个迭代，可以在迭代中间安排一些其他任务

习惯十八：固定价格就意味着背叛

让团队和客户一起，真正地在当前项目中工作，做具体实际的评估，由客户控制他们要的功能和预算

习惯十九：守护天使

编写能产生反馈的代码

好的单元测试能够为你的代码问题提供及时的警报，如果没有到位的单元测试，不要进行任何设计和代码修改

习惯二十：先用它再实现它

编码之前，先写测试

先写测试，就会站在代码用户的角度来思考，而不仅仅是一个单纯的实现者，这样做是有很大区别的，你就会发现因为你自己要使用它们，所以能设计一个更有用、更一致的接口

习惯二十一：不同环境，就有不同问题

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

习惯二十二：自动验收测试

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

习惯二十三：度量真实的进度

不应该去计算工作量完成百分比，而应该测定还剩下多少工作量没有完成，如果你最初估计这个任务需要40小时，在开发了35小时后，你认为还需要另外30个小时的工作，那就得到了很重要的度量结果，如果真正花费的时间比最初估计的时间要长，没有关系，这可以作为下一次估计的参考

度量的粒度以工作日作为时间单元比较合适

习惯二十四：倾听用户的声音

每一个抱怨的背后都隐藏了一个事实，找出真相，修复真正的问题

没有愚蠢的用户，只有愚蠢、自大的开发人员，你的用户有可能会阅读所有的文档，记住其中的所有内容，但也可能不会

习惯二十五：代码要清晰地表达意图

PIE原则，代码必须明确说出你的意图，而且必须富有表达力，这样可以让代码更易于被别人阅读和理解。代码不让人迷惑，也就减少了发生潜在错误的可能

习惯二十六：用代码沟通

如果必须通读一个方法的代码才能了解它做了什么，那么开发人员先要投入大量的时间和精力才能使用它，反过来讲，只需短短几行注释说明方法行为，就可以让生活变得轻松许多，开发人员很快可以了解到它的意图、它的期待结果，以及应该注意之处

不要注释绝大部分代码，特别是在方法体内部，源代码可以被读懂，不是因为其中的注释，而应该是由于它本身优雅而清新------变量名运用正确、空格使用得当、逻辑分离清晰，以及表达式非常简洁

如何命名很重要，程序元素的命名是代码读者必读的部分，通过使用细心挑选的名称，可以向阅读者传递大量的意图和信息

注释可用来为读者指定一条正确的代码访问路线图，为代码中的每个类或模块添加一个短小的描述，说明其目的以及是否有任何特别需求，对于类中的每个方法，可能要说明下列信息：

1. 目的：为什么需要这个方法？
2. 需求（前置条件）：方法需要什么样的输入，对象必须处于何种状态，才能让这个方法工作？
3. 承诺（后置条件）：方法成功执行后，对象现在处于什么状态，有哪些返回值？
4. 异常：可能会发生什么样的问题？会抛出什么样的异常？

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

解释代码做了什么的注释用处不那么大，相反，注释要说明为什么会这样写代码

习惯二十七：动态评估取舍

对任何单个因素独断地强调，而不考虑它是否是项目成功的必要因素，必然导致灾难的发生

没有适宜所有状况的最佳解决方案，你必须对手上的问题进行评估，并选出最合适的解决方案

考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上，不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化

习惯二十八：增量式编程

在很短的编辑/构建/测试循环中编写代码，这要比话费更长时间仅仅做编写代码的工作好得多，可以创建更加清晰、简单、易于维护的代码

习惯二十九：保持简单

不要让自己被迫进行过份设计，也不要将代码过分复杂化

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

习惯三十：编写内聚的代码

让类的功能尽量集中，让组件尽量小，要避免创建很大的类或组件，也不要创建无所不包的大杂烩类

习惯三十一：告知，不要询问

作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做出任何决策，更不能去改变该对象的状态，这样的逻辑应该是被调用对象的责任，而不是调用者的，在该对象之外替它做决策，就违反了它的翻转原则，而且为bug提供了滋生的土壤

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

习惯三十二：根据契约进行替换

替换原则，相对基类的对应方法，派生类服务（方法）应该不要求更多，不承诺更少，要可以进行自由的替换，在设计类的继承层次时，这是一个非常重要的考虑因素

习惯三十三：记录问题解决日志

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

习惯三十四：警告就是错误

嵌入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法，签入构建工具中的代码不应该产生任何警告信息

习惯三十五：对问题各个击破

单元测试带来的积极效应之一，是它会强迫形成代码的分层，要保证代码可测试，就必须把它从周边代码中解脱出来

在解决问题时，要将问题域与其周边隔离开，特别是在大型应用中

习惯三十六：报告所有异常

必须要处理所有的异常，倘若可以，从失败中恢复再好不过，如果不能处理，就要把异常传播到方法的调用者，这样调用者就可以尝试对其进行处理了

习惯三十七：提供有用的错误信息

一方面要提供给用户清晰、易于理解的问题描述和解释，使他们有可能寻求变通的之法，另一方面，还要提供具备关于错误的详细技术细节给用户，这样方便开发人员寻找代码中真正的问题所在

一种实现上述两个目的的方式：显示清晰的错误说明，该错误信息不只是简单的文本，还包括了一个超链接，用户、开发人员、测试人员都可以由此链接得到更多信息

习惯三十八：定期安排会面时间

要保证会议议题不会发散，每个人都应该只回答下述三个问题。

1. 昨天有什么收获
2. 今天的计划
3. 面临着哪些障碍

习惯三十九：架构师必须写代码

积极的编程可以带入深入的理解，不要使用不愿意编程的架构师---不知道系统的真实情况，是无法展开设计的

习惯四十：实行代码集体所有制

让开发人员轮换完成系统不同领域中不同模块的不同任务

不要无意间丧失了团队的专家技能，如果某个开发人员在某个领域中机器精通，不妨让他作为这方面的驻留专家，而且系统的其它部分代码对他开放，这样对团队和项目都很有帮助

习惯四十一：成为指导者

与团队其他人一起共事是很好的学习机会，知识有一些很独特的属性；假设你给别人钱的话，最后你的钱会变少，而他们的财富会变多，但如果是去教育别人，那双方都可以得到更多的知识

通过详细解释自己知道的东西，可以使自己的理解更深入，当别人提问时，也可以发现不同的角度

习惯四十二：允许大家自己想办法

指给他们正确的方向，而不是直接提供解决方案，每个人都能从中学到不少东西

习惯四十三：准备好后在共享代码

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

习惯四十四：做代码复查

对于提升代码质量和降低错误率来说，代码复查是无价之宝，如果以正确的方式进行，复查可以产生非常实用而高效的成果，要让不同的开发人员在每个任务完成后复查代码

习惯四十五：

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