[zz]慢速软件开发

这是一个急三火四的年代，人们很不得一口吃下一个胖子，做软件开发的恨不得一下子就完成一个软件，然后就在家里数钞票。

心急火燎的结果呢？下面的情景是否会让你有种似曾相识的感觉：
* 费了半天努力修改的bug，仔细想来，其实已经在需求明明白白写好了，只是开发时未曾注意到。
* 好容易写好的一段代码，还没来得及向别人炫耀，却发现原来一个好好的功能出了问题，更糟糕的是，根本看不出这两段代码有什么联系。
* 这个bug让你想骂人，因为它居然是其他人修改另一个bug引入的。
* 这个地方有人改过，不过，修改的代码解决的根本不是真正的问题。
* 客户要的是一个小功能，但是对我们来说，加入它无异于重写整个系统。
……

已经有无数人用无数的事实告诉我们，在软件开发中，要付出就趁早，越晚代价越大。当然，我们能看到的大多数例子是在开发的不同阶段，比如需求比开发便宜，开发比测试便宜，测试比维护便宜等等。其实，在开发之中，也是如此，新鲜出炉的代码绝对比那些陈年旧帐更容易修改，不信的话，找一段自己几个月前写的代码理解一下试试。

前面那些似曾相识的场景，多半都是“急”出来的。可现实是，我们需要在后期用更大的精力为前面的“急”买单，所以，为了不给未来的自己挖坑，我们不妨慢一些：
* 仔细了解一下需求，分析需求是不是合理，而不要低着头就开始堆代码。
* 给出一个解决方案时，考虑一下会对已有的代码造成怎样的影响，打破窗户容易，修补难。
* 多花点时间重构，代码上的臭味越到后期显得越刺激。
* 修改bug时，停下来想想什么才是真正的问题，治标不治本的方案只会让人重回梦境。
* 写测试吧！貌似的浪费会让你在后期遇到bug时感激涕零。
……

软件开发其实是一个跟复杂度做斗争的过程，从某种程度来说，复杂度会一直在增长，我们所能做的就是尽可能降低复杂度增长的速度。我曾经和一些朋友说过，前期所做的一切是让我们在后面有更大空间挥霍。慢下来，让我们有时间思考自己的每一步是否迈得是否稳当，稳当的行进，心里才踏实。

这里的慢，实际上，还是为了快，殊途同归。