《高效程序员的45个习惯》简介：

“书中‘切身感受’的内容非常有价值——通过它我们可以做到学有所思，思有所悟，悟有所行。”

——Nathaniel T. Schutta，《Ajax基础教程》作者

“此书通过常理和经验，阐述了为什么你应该在项目中使用敏捷方法。最难得的是，这些行之有效的实战经验，竟然从一本书中得到了。”

——Matthew Johnson，软件工程师

十年来，软件行业发生了翻天覆地的变化。敏捷方法大行其道，测试和测试驱动开发在很多开发人员的工作中扮演着重要的角色。作为一名程序员，你应该培养怎样的素质，方能对多变的环境应对自如，始终立于不败之地？

本书简明实用、见解深刻，总结了高效程序员在开发过程中的45个个人习惯、思想观念和方法，有助于开发人员在开发进程、编码工作、开发者态度、项目和团队管理，以及持续学习等5个方面积极修炼。通过学习这些内容，养成这些好的习惯，你可以极大地提升自己的编程实力，更快速、更可靠地交付更高质量的软件，从而成为真正的高效程序员。

《高效程序员的45个习惯》摘录：

敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。 指责不会修复bug，应把矛头指向问题的解决办法，而不是人。 不用要急于修复一段没能理解的代码。 对事不对人。 消极的评论会扼杀创新，脱离实际的反方观点会使争论变味。 试用VS2010：但之前要确定几个问题：1只有它才能最好的解决当前问题吗2你将会被它栓住吗3维护成本是多少 五个为什么很有用，但要问到点子上，不要跑题。 设计是用于指导开发的，而不是牵制开发。敏捷并不意味着不设计，比如用uML画关键工作图：使用类及其交互关系来描绘系统是如何组织的。 保持项目随时可以发布：编译，运行，测试并立即部署。 提早集成，持续而有规律的频繁集成。 在没有询问或征得用户的同意之前，安装程序绝对不能删除用户的数据。用户应该可以安全并完整的地卸载软件。 不一致的术语是导致需求误解的一个主要原因。应该维护一个术语表。 对用户（产品经理）使用演示来获得频繁反馈。 使用短迭代，增量发布。 要强调代码的集体所有制，让开发人员轮换完成系统不同领域中不同模块的不同任务。但也不用无意间丧失了团队的专家技能。开发人员不必了解每个细节，但是也不能因为要处理某个模块的代码而感到惊恐。 好的想法不会因为被许多人了解而削弱。如果你用你的蜡烛点燃了别人的，别人在得到光明的同时，也没有让你的周围变暗。 作为指导者，应该鼓励、引领大家思考如何解决问题，并给大家解决问题的机会，而不是只告诉答案，除非对方真的陷入胶着状态。 代码复查对于提升代码质量和降低错误率的重要作用。需要积极评估代码的设计和清晰程度，而不止是考量变量名和代码格式是否符合组织的标准。当某些代码编写完成、通过编译、完成测试，并已经准备签入时，其他开发人员就可以“捡拾”起这些代码开始复查。当然，更好的方法是编程时就结对。要确保复查人员得到每次复查活动的反馈结果。 如果要将团队带入新的领域，必须...

《高效程序员的45个习惯》目录：

第1章　敏捷——高效软件开发之道
第2章　态度决定一切
1. 做事
2. 欲速则不达
3. 对事不对人
4. 排除万难，奋勇前进
第3章　学无止境
5. 跟踪变化
6. 对团队投资
7. 懂得丢弃
8. 打破砂锅问到底
9. 把握开发节奏
第4章　交付用户想要的软件
10. 让客户做决定
11. 让设计指导而不是操纵开发
12. 合理地使用技术
13. 保持可以发布
14. 提早集成，频繁集成
15. 提早实现自动化部署
16. 使用演示获得频繁反馈
17. 使用短迭代，增量发布
18. 固定的价格就意味着背叛承诺
第5章　敏捷反馈
19. 守护天使
20. 先用它再实现它
21. 不同环境，就有不同问题
22. 自动验收测试
23. 度量真实的进度
24. 倾听用户的声音
第6章　敏捷编码
25. 代码要清晰地表达意图
26. 用代码沟通
27. 动态评估取舍
28. 增量式编程
29. 保持简单
30. 编写内聚的代码
31. 告知，不要询问
32. 根据契约进行替换
第7章　敏捷调试
33. 记录问题解决日志
34. 警告就是错误
35. 对问题各个击破
36. 报告所有的异常
37. 提供有用的错误信息
第8章　敏捷协作
38. 定期安排会面时间
39. 架构师必须写代码
40. 实行代码集体所有制
41. 成为指导者
42. 允许大家自己想办法
43. 准备好后再共享代码
44. 做代码复查
45. 及时通报进展与问题
第9章　尾声：走向敏捷
9.1　只要一个新的习惯
9.2　拯救濒临失败的项目
9.3　引入敏捷：管理者指南
9.4　引入敏捷：程序员指南
9.5　结束了吗
附录A　资源
索引
· · · · · ·