• 2009-10-21

    管理问题?技术问题?

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

    产品做大了,人多了,就要分组,有了分,自然还要有合。这是一个产品的两个团队,他们原有的工作习惯是,一旦有工作涉及到二者的接口,两边独立开发,等到完全开发完毕,双方“一起”把代码合入代码库。或许,单看两个团队,问题还不是特别明显。在整个产品中,开发团队有很多,类似的情况在底层团队和几乎所有其它团队之间都存在,而且每个团队都有自己的开发进度,由此,你可以想见,采用这种开发模式,协调各组之间的开发计划到底是一件多困难的事情了。

    为什么不能把接口部份先合入代码库,然后,两边一起分别完成各自的工作。经过调研发现,接口中有个双方共用的结构体,在这个结构体中添加一个新的字段,从上层调用者来说,没有任何问题,问题出现在底层。在实现中,会对比这个结构体的长度和从数据库读出内容的长度,在底层还没有实现这个功能时,数据库内容的长度和结构体的长度肯定是不一样的,而这个不一致会导致整个系统启动失败。这是双方不能独立工作的真正原因。

    上面的原因看上去很合理,但放到一起,却给人感觉那么奇怪。因为添加一个字段,导致系统无法启动,所以,两个组要把代码攒到最后一次性提交,所以,计划很难协调。

    为什么双方要依赖于同一个结构体呢?从直观的想法来看,两个部份用到是同样的结构,使用同一个结构体就无可厚非。但结果告诉我们,这样的做法是有问题的。一个改进方案是,上层代码做一层封装,把底层代码隔离开来,这样,上层团队就可以单独开发,不再依赖于底层团队的开发进度,之后,当二者都完成开发时,只要把这一层封装稍做修改,二者的工作己可以连接到一起。

    这是一个常见的手法。比如,Java项目经常会用到一些开源库,我们并不会让程序的所有部份都直接依赖于这个库,而是要做一层封装,这样,哪天我们打算换掉这个库的时候,只要改掉这层封装就可以了,其它部份完全不需要修改。

    设计的一个作用就是解耦。解耦一个表现就是要区分出内外。或许,在整个产品的范围内看来,他们都是“内部”,但是由于跨越了不同的团队,实际上,他们并不是“自己人”。所以,彼此分离才是一个正确的选择。这样一个设计上的改进,解开的不仅仅是代码之间的耦合,也是两个团队开发进度之间的耦合,二者不再需要等待对方,只要把自己的工作做好。唯一需要协调的点,就是最终的集成,但这个点并不影响团队的开发进度。

    初看起来,这是一个管理问题,但真正的问题其实是设计,而这只是一个例子。

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 学习学习。。你的语言很朴实,看得懂。。。看了你过去很多文章。。了解了世界上存在的 有关计算机的公司。。呵呵。还有大会。