• 2008-11-26

    慢速软件开发

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/31825593.html

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

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

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

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

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

    这里的慢,实际上,还是为了快,殊途同归。
    分享到:
    引用地址:

    评论

  • 你说的我都同意,我也努力想这么做,可领导不同意啊,领导要的是快速做个垃圾把客户忽悠了再说。
  • 同意这个观点
  • "软件开发其实是一个跟复杂度做斗争的过程"
    精辟,太精辟了。
  • 列举的很全,有些问题我也正在考虑。加强开发前的需求分析已经列入下一期的改进目标。