• 2009-03-25

    从敏捷开始

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

    我们的跨项目组持续集成方案要用到Hg,我们专门介绍了Hg。之后,我们搜集到了一大堆问题。下面就是一个:
    * Hg解决不了我们代码的耦合

    没错,Hg解决不了,事实上,没有工具可以解决。因为版本管理和代码耦合是两件独立的事。

    但是,为什么这样的问题会提出来呢?

    Hg只是我们实施用到的一个工具,这个方案对客户的开发人员而言,是一套全新的工作方式,正是这套工作方式的引入,他们原本一切安稳的工作方式受到了挑战,那些原本不是问题的问题也就暴露出来。

    你或许已经想到了,引入我们的方案,对他们而言,绝不是仅仅把工具安上这么简单,甚至不仅仅是工作方式的改变,也许更大的调整在等待着他们。

    无独有偶,这不是我们遇到第一次类似的情况。

    和我们讨论TDD的时侯,有人和我们说,我承认TDD很好,但是,我们的代码做不了TDD,因为我们的代码耦合太大。

    继续讨论下去,就会发现,他们对现状有很多不满,而根源往往就是这种耦合。既然大家都认为这是个问题,那就应该解决它。面对这种耦合,他们通常表现出的是一种无能为力,认为这是历史遗留问题,无法解决。我们所经历过的实际情况是,还没有代码真正糟糕到让人无能为力的地步,只是他们缺少有效的工作方法而已。经过一些历练的我们,面对遗留代码时,会多几份从容。

    敏捷,给了我们一个新的思考角度,由此,我们得以发现很多的问题。这不是敏捷的问题,而是既有工作方式存在的问题,只不过,敏捷让它暴露出来而已。借由敏捷的引入,努力消除这些问题,让软件开发向着良性的方向前进。

    敏捷,只是一个开始,随着敏捷的深入,我们可以发现更多原本可以做得更好的地方。

    分享到:

    历史上的今天:

    在BJUG讲XRuby 2007-03-25
    引用地址:

    评论

  • 一般来说代码耦合的根本原因是业务耦合严重,或者是对业务分析不足,造成代码耦合。
    引进一种工具应该是一件非常严肃的事,否则只是走走过场,它的本质是会带来组织架构的调整的。如果不调整,那就是走过场。
  • 可以建议他们看一看working effectively with legacy code