在编写代码时，有许多具体的原则旨在使您的代码更易于维护：DRY，单一责任原则，Demeter法则，开放/封闭原则等。这些是遵循的重要原则，但可能是困难的一下子把他们全部留在你的心头上我发现保持一些更广泛的想法往往更容易。

改变你的观点


在编写代码时，我会尝试从加入该项目的新开发人员的角度来不断审查它。我想象第一次读这个代码是什么样的。

我会理解整体流程吗？我是否按照与项目其余部分一致的方式使用条款？如果我不得不在不知道所谓的情况下搜索这个东西，能否快速找到它？

在Atomic Object中，我们经常做配对编程，这是一个很好的方法，可以立即从不是你的人那里得到这些问题的答案。

确保您的代码可由其他人（或您未来的自我）维护的最佳方式之一是使其自我记录。我不是说你应该在整个地方添加评论。应该对由代码本身以外的因素（例如，客户要求或一些历史背景）所影响的罕见的代码段保留注释。而是认真思考一切的命名。毕竟，

计算机科学中只有两件难事：缓存无效和命名。--- 菲尔·卡尔顿


整洁事宜


你有没有看过一个混淆的代码大赛？是的，可以编写一些有用的东西，但本身完全不可读。这些比赛当然是很有趣的，但是很容易陷入糟糕的格式化习惯（或者完全冷淡）。令人愉快的代码也易于快速扫描。

编译器实际上很好地解析和优化代码，而人类不是。怜惜人类，并为他们编写代码首先，机器只是次要关注。

喜欢清晰的聪明。可读性远远超过小型优化。布莱恩·克尼扬说：

大家都知道，调试是首先编写程序的两倍。所以如果你像写的那样聪明，你会怎么调试呢？


避免特殊情况


很少的事情会比特殊情况更快地破坏你的代码。这些东西是把你精心打造的机器上弄几根管上钻孔。在短期内看起来似乎更容易，只是在其上拍一些胶带，并尝试忽略它，但是如果您没有解决根本问题，那么稍后再一次再次泄漏。

这可能看起来像一个快速而肮脏的修复程序，以便及时获取发布的内容。它可能看起来像是重新使用一个组件，而这绝对不是设计的。这是那些大多数工作，但有一些讨厌的锯齿状边缘的东西。

只要简单地使用一些让你最了解方式的东西，可以很诱人，但是需要纪律来重构那个东西，所以让你一路走来。这很值得！