降低软件质量能让你更快吗？

    我们经常听到一个说法，说团队软件质量低是因为面临工期压力，为了快速交付不得不做出来的让步。通过降低交付的软件质量换取了交付速度。乍一听这个说法觉得挺合理。于是各种屎山代码就有了充分的理由：我们没有足够时间，我们需要快速交付。然而真的是这样吗？

    说到软件质量，我们需要界定一下什么是软件质量。我的观点是软件质量至少可能在说两件事儿。一是软件外在质量：是否有Bug，是否考虑到了更多的场景；二是内在质量：主要体现在代码质量上，比如代码的可阅读性、可扩展性等。

    如果我们说软件的外在质量，通过降低外在质量，比如容忍一些Bug，考虑较少的使用场景。毫无疑问确实可以让我们交付得更快一些。毕竟我们的工作量因此降低了，相当于做了更少的工作。表现出来是我们交付的功能似乎更多了。所以看起来交付得更快了。

    如果我们说软件的内部质量。通过降低软件的内部质量会让我们交付的更快吗？如果不注重代码的内部质量，我们很显然得到的更加混乱的代码、不清晰的架构。在后续对代码的修改、阅读上会耗费更多的时间，除非你的代码规模非常小（比如几百行上千行）。

    软件之所以称为软件，是因为其容易修改，因此软件的需求也是不断变化。我们把软件写出来只是第一步，在后面需求不断变化中，我们需要不断修改代码库来满足新的需求。要提高修改代码库的效率，就要有容易阅读、容易修改的代码，这是显而易见的。在项目初期，由于代码规模小，混乱的代码给我们带来的困扰不多，这时候降低内部质量可以换来更快的交付。不过随着代码规模的增加，低质量带来的暂时性优势很快就消失无影无踪。

    我曾经编写过一个规模很小的软件。第一个能运行的版本我花了不到10个小时就出来了。但后面持续不断地增加特性，修改Bug，然我又耗费了2周左右的时间。是因为我不愿意编写内部质量更高的软件吗？并不是，实际上那时候是没有能力。

    和一般认识不同，编写内部质量更好的软件并非一种选择。不是说你想编写更好的就可以编写更好的，没有写得更好是因为不想。编写内部质量更好的软件是一种能力。作为一名普通的软件工程师，我和绝大多数人一样，缺乏能直接写出高质量软件的能力。幸运的是，行业的前辈已经为我们准备了并不是很困难的方法。

    这个方法就是极限编程的核心实践：测试驱动开发、重构。这个实践的逻辑是这样的：

• 在实现业务的时候。我们通过测试驱动开发来编写测试和业务代码以让程序能够工作。

• 当业务实现后。这时候代码可能已经出现坏味道，由于我们有快速的测试保护我们的业务代码，我们就有足够的勇气对代码进行重构。如果重构出问题，测试代码能及时告诉我们避免引入Bug。这样我们就可以通过重构获取更好的代码。

  通过这样的纪律编写的代码，可以持续具备较高的代码质量，可以在项目进行很久后，拥有几十万甚至更多的代码行数后，依然比较容易阅读和修改。这样我们就可以持续保持生产力，而不用在代码的屎山上打滚。