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

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