1. 做事

指责不会修复bug。把矛头对准解决问题的办法，而不是人。这是真正有用处的正面效应。

• 勇于承认自己不知道答案，这会让人感觉放心。一个重大的错误应当为当做是一次学习而不是指责他人的机会。
• 如果一个团队成员的行为一再伤害了团队，我们必须要求他离开。
• 如果大部分团队成员（特别是开发领导者）的行为都不职业，并且他们对团队目标都不感兴趣，你就应该主动从团队中离开，寻找更适合自己发展的团队。

2. 欲速则不达

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

• 一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。
• 在工作压力之下，不去深入了解真正的问题以及可能的后果， 就快速的修改代码，这样只是解决表面的问题，最终会引发大问题。

3. 对事不对人

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

4. 排除万难，奋勇前进

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

• 看到糟糕的代码，不要只是嚷嚷抱怨。相反，你应该重写这些代码，并比较重写前后的优缺点。列出重写理由，会有助于你的老板（以及同事）认清当前形势，帮助他们的到正确的解决方案。

5. 跟踪变化

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

• 迭代和增量式的学习。每天计划用一段时间来学习新技术。
• 了解最新行情。
• 如饥似渴的阅读。

6. 对团队投资

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

7. 懂得丢弃

学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，骑车要比马车车厢强得多。

8. 打破沙锅问到底

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

9. 把握开发的节奏

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

• 以固定、有规律的长度运行迭代。

10. 让客户做决定

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

11. 让设计 指导 而不是 操纵 开发

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

12. 合理使用技术

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

• 这个技术框架真能解决这个问题吗？
• 你将会被他拴住吗？
• 维护成本是多少？

13. 保持可以发布

保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署。

14. 提早集成，频繁集成

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

15. 提早实现自动化部署

一开始就实现自动化部署应用。

16. 使用演示获得频繁反馈

清晰可见的开发。在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一周或两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。

17. 使用短迭代，增量发布

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

18. 固定的价格就意味着背叛承诺

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

19. 守护天使

使用自动化的单元测试。

20. 先用它再实现它

先用它再实现它。将TDD（Test Driven Development，测试驱动开发）作为设计工具，它会为你带来更简单更有实效的设计。

21. 不同环境，就有不同问题

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

22.自动验收测试

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

23.度量真实的进度

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

• 用小时来评估工作量。

24. 倾听用户的声音

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

• 没有愚蠢的用户。
• 只有愚蠢、自大的开发人员。

25. 代码要清晰的表达意图

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

• 应该让自己或团队的其他任何人，可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制。

26. 用代码沟通

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

27. 动态评估取舍

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

28. 增量式编程

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

29. 保持简单

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

• 当你觉得所编写的代码没有一行是多余的，并且仍能交付全部的功能时，这种感觉就对了。这样的代码容易理解和改正。

30. 编写内聚的代码

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

31. 告知，不要询问

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

32.根据契约进行替换

通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。

33. 记录解决问题的日志

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

• 要记录团队做出一个重要决策的原因。否则，在6~9个月后，想再重新恢复决策过程的时候，这些细节就很难再记得了，很容易发生相互指责的情形。

34. 警告就是错误

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

35.对问题各个击破

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

36. 报告所有的异常

处理或向上传递所有的异常。不要将他们压制不管，就算是临时这样做也不行。在写代码时要估计到会发生的问题。

37. 提供有用的错误信息

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

38. 定期安排会面时间

使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。

39. 架构师必须写代码

优秀的设计从积极的程序员那里开始演进。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计的。

40. 实行代码集体所有制

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

41. 成为指导者

成为指导者。分享自己的知识很有趣——付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实力。

• 你会感到给予别人教导，也是提升自己学时的一种方式，并且其他人亦开始相信你可以帮助他们。

42. 允许大家自己想办法

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

• 用问题来回答问题，可以引导提问的人走上正确的道路。

43. 准备好后再共享代码

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

44. 做代码复查

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

45. 积极通报进展与问题

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