• 2008-07-16

    忍无可忍

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

    几个月前,一个同事跟我说,这个bug改不动了,我问为什么,他的答案是,那块的代码太乱了,改一丝会动全身。

    昨天,一个同事跟我说,这块太乱了,做不动了。

    两次,我做了相同的选择:重构。

    重构和开发新功能在很多PM眼里一直是一对很难调和的矛盾。对于PM来说,来自客户的压力让他更关注项目的进展,而重构往往代表项目的原地踏步,只有开发新功能才是“正道”。放弃“正道”,选择看不见进展的重构,站在PM的角度上,这是难以接受的。

    “破窗户”理论告诉我们,一旦置破烂于不理,其结果通常是烂得更多更快。

    一个同事和我聊天时,提到了他正在做的一个系统,他们在开发的过程中发现了很多问题,很多bug改起来都非常困难。他们想重构,但是强势的PM坚持要开发新功能,于是,这些问题有幸在代码中继续生存下去。随着项目的进行,这些问题暴露得越来越明显,以致于有些问题已经成为项目继续开发新功能的障碍。当问题到了不得不进行修改时,发布的日期也逐渐临近了。

    当我做出重构的选择时,我知道,我会失去对当前进度的控制。但我期望得到的是一个合理的设计,以此,后续的一些开发工作会得到大幅度加快,前面失去的进度后面在一定程度可以得到弥补。

    几个月前,那段时间,项目进度如预期的慢了下来,但随着重构的进行,我对代码质量也逐渐的越来越有信心了。事实证明,项目后期出现了进度井喷的现象,原本耽误的进度到最后居然出现了提前完成。

    这次,当我和那个同事讨论了新版设计之后,我从那个曾经失望的眼里看到了光芒。今天开始工作之前,项目组的所有开发人员又在一起重新讨论了这个新的设计,并进行了一些完善。于是,一个Pair开始采用这个新的设计方案进行编码。事实出乎意料的顺利,原本预计耽误很多的进度,在他们生花妙手的努力下,在今天下班之前,就将大部分赶了回来,让我着实惊讶于他们的开发速度。

    从这几个项目的经验来看,重构,短期上在阻碍开发的进度,但是站在长期的角度,却可以大幅度提升软件开发速度,也提高了软件本身的质量,更重要的是,通过重构,解决掉一些原有实现中固有的缺点,可以将程序员从痛苦中解救出来。编程本应该是快乐的,不是吗?

    忍无可忍,无须再忍,重构吧!
    分享到:

    历史上的今天:

    引用地址:

    评论

  • 重构应该最好是可以融于开发当中,将重构的思想浸入细节
  • 权衡重构的代价和带来的好处,是决定是否重构的关键吧。当然前提是有很好的测试代码,否则重构就是自找麻烦。
    回复cyn0sure说:
    好在我在ThoughtWorks,好在我们采用TDD,所以,测试不是问题。
    2008-07-17 17:54:22
  • 确定的进度和未知的冒险之间,通常项目管理者选择前者,程序员选择后者,而且毫无疑问,后者更需要时间和精力的投入(相对于当前)。在多数时候,只是因为,如我所说是“未知的冒险”,重构的好处,或者说对将来的好处实在是虚无,对非程序员更是。接受这个现实可能更合适一些,这样可以有利于选择另一种方式。
    我也忍过,而且现在也还在忍,因为项目进度或者说稳定对我来说也是重要的,而一次性的大重构,我觉得非常人所能,额外的时间和精力投入以及压力是非常巨大的,干过一些,也看到别人干着。
    从另一个角度来说,凡事并非一蹴而就,所以为什么要忍?让我想起一个保护地球保护环境的广告,其实代码环境又如何不是呢。
    所以我开始用另一种方式,那就是自己键盘所到之处,所需之处,绝对清理,之外的视情况而定。这需要更多的忍耐,循序渐进真的很难,就好像骑自行车,依靠惯性快点骑比慢慢骑要容易一些,我每次都是恨不能一蹴而就,但其实只要考虑到重要的东西其实非常多,比如持续集成,其极限设为一天,那么很显然你这一天是很难做非常大的重构的,所谓小不忍则乱大谋,所以暂时让视野之外的垃圾留一留,甚至是为之存活加点生活垃圾也行,当然,前提是你还会回来清理掉它。
    相对来说,为加新功能进行必要的重构是很容易让人接受的,而我更认为基本上别人不能干预,PM总不能关心我一天中每个小时都在干什么吧,关心也无所谓,没有动到PM的奶酪,人家肯定愿意放手让你撒野。
    回复Li Xiao说:
    准确的说,我这几次做的,都是中等规模的重构。太小的,如你所说,在日常开发中已经涵盖到了。太大的,就需要有一个权衡,到底是为了重构,让自己有个更好的未来,还是忍着,赶项目进度。再有,这几次所做的还有另外一个特点,不做不行,因为如blog开头提到的,基本上到了做不下去的时候,所以,重构是不得已而为之的选择。

    做一个好的程序员真的很难,即便自己做得很好,也很难保证项目组所有人都做得很好,所以,眼之所及,会有许多不甚理想的地方。很早的时候,我就告诫过自己“不要完美”,要权衡收益。如果收益小于付出,容忍一些垃圾是可以的,反之,放手去做是最好的选择。
    2008-07-17 17:53:36