高效程序员的45个习惯

1. 做事。与其推卸责任，不如去解决问题。
2. 欲速则不达。要增量编程，步步为营。没真正理解一段代码之前，别急着去修改它。
3. 对事不对人。掌握提问、反驳、争论的技巧，注意说话口吻，不能带个人情绪的接受或反驳别人观点。
4. 排除万难，勇奋前进。要真诚、有勇气地说出实情和想法。当你发现某段代码很混乱，需要重构，好，说出来。
5. 跟踪技术变化。你要不断的学习新技术，了解新行情，不求精通。
6. 对团队投资。团队间经常互相交流，小型的内部知识讲座，技术讨论，设计方案讨论等等。
7. 懂得丢弃。技术、思想、方案、习惯等等，不好的别舍不得。
8. 打破沙锅问到底。知其然，还要知其所以然。多看看好的代码是怎么实现的。
9. 把握开发节奏。当每天都加班加点，累的半死，就要注意了。寻找最佳的迭代周期。
10. 让客户做决定。业务方面开发者不应想当然，没有客户参与的项目多半得返工重做，费钱费力。
11. 让设计指导而不是操纵开发。设计文档不应过于详细，而只是框架或大体思路。因为一旦开始编码，一切都会改变。
12. 合理地使用技术。采用现有框架何以节约成本加快进度，但要权衡利弊。
13. 保持可以发布。让你的项目处于随时可编译、运行、测试和部署。增加功能时做好版本管理，别让项目处于既不可发布，又不可撤销状态。
14. 提早集成，频繁集成。集成会有风险，但早出现总比晚出现好，让每次集成代码修改尽量的少，保证项目可控。
15. 提早实现自动化部署。一开始就进行全面部署，让问题尽早浮现。
16. 使用演示获得频繁反馈。让用户看到系统在不断完善，新功能不断添加，用演示也和获得用户的反馈。
17. 使用短迭代，增量发布。及时发布功能，保证功能不背离客户的需求。
18. 固定的价格就意味着背叛承诺。软件项目是变化无常的，很难准确地预测成本，保证项目在可控范围即可，如必须提供价格，你需要真正地评估技巧。
19. 守护天使。有效单元测试可以及时发现问题，提供警报。
20. 先用它再实现它。先考虑你会怎样用它，再去用代码实现它，就是说，有具体理由才开始编码。专注与设计接口。
21. 不同环境，就有不同问题。在不同的机器，不同的系统上测试你的代码。
22. 自动验收测试。从用户那里获得测试答案。
23. 度量真实的进度。客观地预测工作量，通常，工作量是你认为的2倍。如你认为1个星期可以完成的功能你应该安排2个星期。
24. 倾听用户的声音。每一个抱怨的背后都隐藏了一个事实。
25. 代码要清晰地表达意图。编写清晰的代码，而不是展示你的小聪明，过早的优化是万恶之源。
26. 用代码沟通。注释应是简明扼要的，说明为什么会这样写代码。好的代码是让自己或他人可以读懂自己一年前写的代码，而且只读一遍。
27. 动态评估取舍。性能、生产力、优雅、成本及上市时间，要根据现在状态动态评估权衡。
28. 增量式编程。别马不停蹄地连续几个小时地编程，循环重构、测试你的代码。
29. 保持简单。把写出简单、可读性高的代码作为目标。但你觉得代码中没有一行是多余的，功能也全部实现时就对了。
30. 编写内聚的代码。让类的功能尽可能集中，让组件尽量小；这样易于查错和修改。
31. 告知，不要询问。各有其职，不要抢其他对象或组件的工作，盯好自己的职责。
32. 根据契约进行替换。Liskov替换原则：任何继承后的对象，必须何以不知差异地替换被使用的基类对象。掌握好继承和委托的用法。
33. 记录问题解决日志。不要让自己再同一个地方摔倒两次。
34. 警告就是错误。让代码没有任何错误和警告。
35. 对问题各个击破。在大型项目中，将问题域与周边隔离排查。
36. 报告所有异常。不是所有问题都应该抛出异常，设计时考虑好由谁处理异常，要传播不能处理的异常。
37. 提供有用的错误信息。没有必要等待异常抛出来发现问题。
38. 定期安排会面时间。每天早上一个10至15分钟的立会是个不错选择。
39. 架构师必须写代码。不知道系统的真实情况，是无法展开设计的。
40. 实行代码集体所有制。所有制并不意味着可随心所欲，到处破坏。不是所有场合都适用。
41. 成为指导者。给予别人教导，也是提升自己学识的一种方式。
42. 允许大家自己想办法。给别人解决问题的机会。
43. 准备好后再共享代码。绝不要提交尚未完成的代码。
44. 做代码复查。正确的代码复查方式可以提升代码质量和降低错误率。
45. 及时通报进展与问题。发布进展状况、新的想法和关注的主题，而不是等别人来询问。