高效程序员的45个习惯

看到厨房很脏，去清理一下，总比等到油污沉积再去打扫省力得多。这就是敏捷开发，小步迭代，快速交付，聆听反馈，积极重构的意义。

写一段代码就测试，重构，休息。让代码干净利落

定期安排会面时间，常开会，开短会

控制好时间，养成好习惯，不要加班

主动及时通报进展及问题，不要等人来问

代码要清晰的表达意图，标准是不需要注释也能可读。方法包括：用枚举代替数字

编写清晰而不是讨巧的代码

不要明日复明日，如果现在不做的话，以后也不会做的

可配置变量太多，会导致代码维护及新增困难

一个应用需要从数据库中读取数据并显示在前端，这里有两种做法：

1. 从数据库读取数据，创建对象，返回UI，在UI再拆分。

2. 数据库中做个view，UI直接读

在硬件上多投入以换取性能提升，降低开发成本与缩短上市时间

客户决定将重点放在哪里

保留以前的问题解决方案，以及提供发生问题时更多的有用细节。要想更加有效的重用你的知识，记录问题解决日志是很有用的

面对问题，并解决它们，是开发人员的生活方式。如果一个熟悉的问题再次发生，我们需要记起第一次是如何解决掉的，而且希望这一次能更快地搞定

维护一个保存曾遇到的问题以及对应解决方案的日志。当问题发生时，快速搜索（day log, do not get burned twice!

day log: 日期，问题，发生问题的版本，平台或版本，代码，原因，解决方案，引用。并可供搜索，excel

共享日志给其他人，创建wiki，鼓励其他开发人员使用和更新其内容。维护一个问题及解决方案的日志

解决方案日志应该作为思考的一个来源，可以在其中发现某些特定问题的细节。对于某些相似又有差异的问题，也能从中获得修复的指引

记录问题的时间不能超过在解决问题上花费的时间，要保持轻量和简单

关注编译错误和警告，⚠️出现时也必须停下来，解决掉再继续。比如一个未使用变量的警告，可能意味着其他变量被错误使用了

让IDE的编译器VS，Eclipse将警告作为错误提示出来，不让任何警告被忽略

要保证代码可测试，必须把他从周边的代码中解脱出来。如果代码依赖其他模块，就应该使用mock对象，来将它从其他模块中分离开

在向问题发起攻击之前，先查找你的解决问题日志

处理或者向上传播所有异常，不要将他们压制并keep在自己手里

当发生问题时，让应用详细记录错误的相关数据。错误日志最起码应该以文本的形式维护。或发送到一个系统级别的事件日志，可以使用工具来浏览日志，产生所有日志信息的RSS feed

对于不幸的用户来说，他们一点头绪都没有，不知道自己到底做错了什么，给技术支持打电话时，应该报告点什么

一条好的用户错误警告，应该包含清晰，易于理解的问题描述和解释，详细技术细节可以一个uuid标志。当客户遇到问题时，自动发送信息给支持团队，而支持团队通过uuid查找详细日志记录

程序员在拒绝设计的同时，也就放弃了思考

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

及时提交代码，每个提交具有原子性，链接jira作为回溯和查找修改原因及内容，便于回滚，分析问题及扩展开发。绝对不要提交没有完成的代码

code review代码复查非常重要。每个程序员都应该这么做

code review可以遵循一些原则，或基本列表：

所有的异常处理程序不允许为空，所有数据库调用都要包在事物中进行

及时通报进展与问题，有情况发生时，就不会让别人感到突然，而且他们也很愿意了解目前的进展状况，他们会知道何时应该提供帮助，而且你也获得了他们的信任

在slack channel 里早上发todo list，晚上发status updates.有问题时raise出来，notify others to get a chance to have a look on it 发布进展状况，新的想法和目前正在关注的主题，不要等着别人来问项目状态如何

经常抬头看看四周，而不只埋头于自己的工作

9.3引入敏捷：管理者指南9.4引入敏捷：程序员指南西方谚语，原文为：Youcanleadahorsetowater,butyoucannotmakehimdrink（你可以带马到水边，但不能免强它喝水），其意指：善意不足以成事。[][]附录A 资源Unix编程艺术http://www.faqs.org/docs/artu/ch04s02.htmlEricStevenRaymond的《Unix编程艺术》一书节选。 一灯能除千年暗，一智能灭万年愚。——慧能，中国禅宗第6代祖师[][]架构师必须写代码 ①第一次世界大战中，所门战役（theBattleoftheSomme）本应成为一个有决定性意义的突破。实际上，它却成为了20世纪最愚蠢的军事行动。最重要的原因是，由于断绝了通信联系，面对的战场情况与早先的预测已经完全不同了，指挥官仍然坚持按照原计划展开战役。请查看http://www.worldwar1.com/sfsomme.htm。 Youcan’tcodeinPowerPoint“ PowerPoint架构师”[][]复查 代码刚刚完成时，是寻找问题的最佳时机。如果放任不管，它也不会变得更好。代码复查和缺陷移除要寻找深藏不露的程序bug，正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知方法。——CapersJones的《估算软件成本》[Jon98]

1. 代码能否被读懂和理解？
2. 是否有任何明显的错误？
3. 代码是否会对应用的其他部分产生不良影响？
4. 是否存在重复的代码（在复查的这部分代码中，或是在系统的其他部分代码）？
5. 是否存在可以改进或重构的部分？此外，还可以考虑使用诸如SimilarityAnalyzer或Jester这样的代码分析工具。

[][]33记录问题解决日志“在开发过程中是不是经常遇到似曾相识的问题？这没关系。以前解决过的问题，现在还是可以解决掉的。”Don’tgetburnedtwice

1. 问题发生日期。
2. 问题简述。
3. 解决方案详细描述。
4. 引用文章或网址，以提供更多细节或相关信息。
5. 任何代码片段、设置或对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入地理解相关细节。

你也许会对木匠那毫无差错的工作印象深刻。但我向你保证，事实不是这样的。真正的高手只是知道如何亡羊补牢。——JeffMiller，家具制造者、作家代码要清晰地表达意图“可以工作而且易于理解的代码当然好，但是让人觉得聪明更加重要。别人给你钱是因为你脑子好使，让我们看看你到底有多聪明。 ”PIE④原则④PIE=ProgramIntentlyandExpressively，即意图清楚而且表达明确地编程。——编者注代码必须明确说出你的意图，而且必须富有表达力。这样可以让代码更易于被别人阅读和理解。代码不让人迷惑，也就减少了发生潜在错误的可能。一言以蔽之，代码应意图清晰，表达明确。[]用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。

• 在代码可以传递意图的地方不要使用注释。
• 解释代码做了什么的注释用处不那么大。相反，注释要说明为什么会这样写代码。
• 当重写方法时，保留描述原有方法意图和约束的注释。

[][]增量式编程 所开发的代码基于即时的反馈，这些反馈来自以小步幅方式编写代码和测试的过程。采取增量式编程和测试，会倾向于创建更小的方法和更具内聚性的类。在写了几行代码之后，你会迫切地希望进行一次构建/测试循环。在没有得到反馈时，你不想走得太远。[]编写内聚的代码内聚性用来评估一个组件（包、模块或配件）中成员的功能相关性。内聚程度高，表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话，表明各个成员提供的功能是互不相干的。让类的功能尽量集中，让组件尽量小。很多成功的公司都是靠着“吃自己的狗食”活着。也就是说，如果要让你的产品尽可能地好，自己先要积极地使用它。[][]23度量真实的进度 专注于你的方向Focusonwhereyou’regoing如果你最初估计这个任务需要40个小时，在开发了35个小时之后，你认为还需要另外30个小时的工作。那就得到了很重要的度量结果（这里诚实非常重要，隐瞒真相毫无意义）。 待办事项（backlog）的好处[]7懂得丢弃敏捷的根本之一就是拥抱变化。既然变化是永恒的，你有可能一直使用相同的技术和工具吗？不，不可能。我们一直在本章说要学习新技术和新方法。但是记住，你也需要学会如何丢弃。

• 根深蒂固的习惯不可能轻易地就丢弃掉

Expensivementalmodelsaren’tdiscardedlightly学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，汽车要比马车车厢强得多。新技术会让人感到有一点恐惧。你确实需要学习很多东西。已有的技能和习惯为你打下了很好的基础，但不能依赖它们。

• 对于所使用的语言，要总结熟悉的语言特性，并且比较这些特性在新语言或新版本中有什么不同。

以下来自我的 Practices of an Agile Developer 笔记

书籍简介

Practices of an Agile Developer: Working in the Real World, by Andy Hunt, Venkat Subramaniam, published in 2005

中文版：高效程序员的 45 个习惯：敏捷开发修炼之道，2010 出版

本书是 Pragmatic Programmers 系列书籍，作者Andy Hunt 是Pragmatic Programmers 的创始人，也是敏捷宣言的起草人之一，另著有《程序员修炼之道：从小工到专家》、《单元测试之道 C# 版：使用 NUnit》。

相关网站： blogs.pragprog.com pragmaticprogrammer.com

6. 对团队投资

午餐会议

P32. 每个人都比你厉害，那太好了。有动力继续提高自己。

P33. 持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。

7. 懂得丢弃

丢弃旧技术、方法和习惯，那些会影响生产力。现在，程序员的时间是稀缺资源。

不是完全忘记旧方法，而是要根据情况转变习惯。

9. 把握开发节奏

每天结束的时候，没有残留的代码、任务。不要把每天最后的尝试性的代码带到下一天，应重新开始。

P41. 时间盒：设定一个短时的期限，最终期限。不知道完成所有任务需要多少个时间盒，但每个时间盒必须是短期的、有限的，并且要完成具体的目标。如：番茄工作时间管理方法。

10. 让客户做决定

如果业务负责人（通常是客户）回答“我不知道”，也许是他们还没有想到那么远，也许是他们只有看到运行的实物才能评估出结果。

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

这是敏捷方法对传统方法，如 统一过程 (UP) 等，最具颠覆性的挑战之一，也体现了敏捷宣言中的：可工作的软件产品胜于面面俱到的文档。

Is Design Dead?, by Martin Fowler，是深入讨论本主题的一篇文章。

不做过度的设计，而非不做设计，请画关键工作图。

设计满足实现即可，不必过于详细。

反面示例：更新和维护详细的设计文档变成了主要工作。

战略设计 vs. 战术设计。CRC：类-职责-协作 卡片的设计方法，应用于战术设计。

P51. 完全无设计情景：深入编码只为了学习或创造原型，随后把这些代码扔掉。

P51. 在设计过程中学习是有价值的，但设计本身也许没有太大的用处。这里指，不可缺少设计过程，但不要巨细。

P51. 白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力，而不是启发你的工作。

23. 度量真实的进度

如果时间表是为工资会计准备的，那么它就很难真实地反映工作完成状况。

随意用一个比率进行度量，如已完成 80%，是没有意义的。

应该测定还剩下多少工作量没有完成，如：估计用 40 小时，已开发 35 小时，认为还需另外 30 个小时。

待办事项 (backlog)

不要花费很多时间来了解你所花费的时间，而没有足够的时间进行工作。意思是，不要说我已工作了多少小时，而要说我已完成了多少个功能，即关注功能，而不是日程表。

Other Chapters

Ch6. 敏捷编码

25. 代码要清晰地表达意图 26. 用代码沟通 27. 动态评估取舍 28. 增量式编程 29. 保持简单 30. 编写内聚的代码 31. 告知，不要询问 32. 根据契约进行替换

Ch7. 敏捷调试

33. 记录问题解决日志 34. 警告就是错误 35. 对问题各个击破 36. 报告所有的异常 37. 提供有用的错误信息

Ch8. 敏捷协作

38. 定期安排会面时间 39. 架构师必须写代码 40. 实行代码集体所有制 41. 成为指导者 42. 允许大家自己想办法 43. 准备好后再共享代码 44. 做代码复查 45. 及时通报进展与问题