代码洁癖系列（八）：迭代的原则

我们都知道，一个软件的维护成本往往要高于其研发成本。在维护过程中，我们的代码需要不断的进行迭代。迭代的目的有两个：修复bug和增加新特性。但是迭代也会带来一系列新的问题，比如新的bug，或者是破坏代码的整洁性。这里我们从保持代码整洁性的角度来讨论一下迭代的几个原则。

运行所有测试

没错，首先的要说的还是测试，我们要在每次迭代代码之后，运行所有的测试，如有必要，也要编写新的测试。我们要编写尽量简单的测试，简单的测试会驱使我们降低类与类之间的耦合度。如果还不了解如何编写单元测试，可以参考一下旧文代码洁癖系列（七）：单元测试的地位。良好的测试不但是代码质量的保证，同时也是良好设计的引导。

不要重复“造轮子”

记得我的leader曾经告诉过我：写每一行代码之前，要先思考一下有没有必要写这行代码。在实现一个功能之前，先确认一下这个功能是否已经被实现了。永远不要重复“造轮子”。但是，当我们进行一定的共性抽取时，可能已经违反了SRP原则（Single Responsibility Principle）。因此，抽取出的方法可能需要放在其他类中。

可读

代码是程序员之间的交流工具，要想获得其他程序员的尊重，必须使你的代码具备可读性。这也是我们要保持代码整洁的原因。如何保证代码的可读性呢？首先需要的就是有意义的命名，关于命名规则，可以参考代码洁癖系列（二）：命名的艺术这篇文章，其次就是通过测试用例让别人了解你的代码。

尽可能少的类和方法

在代码洁癖系列（三）：整洁的类和函数一文中，我们说过类和函数都应该尽量短小。有人问了，为了类和函数都足够短小，我要把代码拆分成许多的类吗？这里需要说明一下，在这方面，我们并不需要追求极致。应该根据实际情况，合理的拆分。所以，也要尽量减少类和方法，这可能与“类和函数应该短小”这一原则相矛盾。这需要工程师自己去衡量了，首先要保证“类和函数应该短小”，其次才是尽可能减少类和方法。

结束语

到这里，”代码洁癖系列“的文章要告一段落了，希望大家在写代码的时候可以多思考，保证自己代码的整洁性。文章有什么问题，或者我有哪些遗漏的地方，大家可以通过去我的微信公众号后台留言和我讨论。