我所工作的软件产品线很庞大，历史也很久。即使不考虑它继承的另一个产品线，也有快十年的历史了（否则的话是二十年）。现在仍不断的有新的feature加进来。其中有一些长期困扰我们的问题，我想可能在很多其它软件系统中也是存在的。
- 维护的工作量很大。一个新人要至少到半年以后才有可能参与有限的模块的维护。两年工作经验的人可能维护的也就是这么几个模块。
相对于优秀的软件工程师，我们似乎更需要的是考古学家和历史学家。因为只有历史学家才懂得系统的原始设计，在没有历史学家的情况下，就只能靠考古学家了。幸好，我们还有几个这样的人。
测试的资源非常紧张，因为
我们生产的设备非常昂贵
大部分的功能都必须在满配的设备上测，否则就不放心。这种测试非常慢，而且很难自动化。
看上去似乎没有经验的新人或team也可以进行新功能的开发，但最后总会发现，没有历史学家和考古学家的参与这永远不可能实现。
系统看上去比实际需要的复杂的多。
一方面，很多人都说部门里的人数看上去比实际需要的多很多，可是另一方面还老感觉缺人。
这么多人的组织又成了头痛的问题。各种team和部门，千奇百怪，花样百出。组织内部沟通成本、管理成本越来越高。各个流派长年争执，很难说服对方。- 每个release的周期是一年到两年，几乎没有不延期的release。
这些问题背后的原因可能是瀑布开发模型、代码质量、资源管理、测试水平等等。我觉得可能与所有这些问题相关的一个根本原因是系统的耦合性。所谓耦合性，说白了就是系统模块间的依赖性。我们当然需要这种依赖关系，否则各个模块各行各事，无法完成我们需要的功能。然而过多不必要的依赖关系会给我们带来无尽的麻烦。例如：
新人问题。模块间的高耦合性导致模块内部不紧凑（内聚性低），往往模块会很庞大，并且模块间有千丝万缕的联系。这使得理解系统架构和单独的模块都很难。这就是为什么新人要花费这么长时间才能上手工作。这一点在开源软件中会好很多。因为如果开源软件的架构不好理解，单独模块很难入手的话，就会让新加入的人望而却步，从而失去了生存的根本(见我写的Conway's Law）。
开发问题。模块间的高耦合性使得模块间在漫长的产品开发历史上累积了太多纠缠在一起的复杂关系，这些是任何文档都没有办法完整记录的。所以，只有靠懂得这部分的“历史学家”了。然而历史学家们总是要高升或者离开的，只有善于刨根问底的天才“考古学家”才有可能解开这些迷团。我真想建议他们去搞一门“软件考古学”的学问来（google了一下，还真有人发明了这门学问）。可惜的是，要搞“软件考古学”，不单要是天才，而且还要愿意干才行，而这样的人并不多。
维护问题。模块之间的高耦合性使得出问题的几率大大提高。而且出了问题还捉摸不定，很多问题都很难定位，往往在这里改也成，在那里改也说得通。
系统架构设计上的高耦合性也是测试问题的根本原因。
功能模块与系统平台高度依赖。“想在本地测试？”做做单元测试还有些可能（但也受耦合性影响），想做功能测试就不可能了。
系统平台又与硬件平台高度依赖。“想做个模拟环境？”别提那个贵得吓人，功能有限又慢得要命的第三方模拟平台了，还是拿到真的设备上测吧。
模块之间的依赖性高。想用X，必须带上那个Y，而要有那个Y，还得有个Z，然后要想测到这个功能整个系统还必须重启一下，这时候XYZ又乱作一团了。有一个很有经验的测试工程师有一次和我说：“我看到几乎所有的测试人员好像都在测查不多的case，都是在建call”。他们当然做得都是差不多的测试——他们的那部分功能都在里面的，想分也分不出来啊！
测试工具与测试环境依赖性高。因为上面的问题，想写个自动化测试是很难很难的一件事。好不容易写了一个，环境略微变化了一点点，又跑不动了！三天两头儿的出毛病，维护TA case的时间不知道是维护真实功能的多少倍！
- 系统庞大、效率低下的问题。这么高的耦合性起码会使整个系统紧凑起来，大小总会小一点吧？事实并非如此，不但并非如此，就连性能都打了折扣。通常，设计者愿意牺牲一部分性能来换取低的耦合性，然而高的耦合性却往往换不来高的性能。高耦合的设计使得新的功能忙于应付已有的复杂的依赖关系，最终让系统越来越大，越来越慢。我们所做的提高性能的努力无非也就是折解开这些耦合性，然而这很难很难。
- 人员众多的问题。即然系统已经这么大了，架构已经这么难懂了，测试已经这么难做了，那么我们只好招更多的人了。
- 组结结构问题。不知道是不是高耦合的组织产生了高耦合的系统，反正这样的产品系统注定了相应的组织结构的高耦合性。在这种情况下，很难有一种组织结构能被人们公认为是有效的。典型的开发组织形式无非就是component team或者feature team。Component team以模块为单位组织team，倾向于屈从于系统内部的依赖关系。而feature team以客户功能为目标组织team，倾向于挑战系统内部的依赖关系。然而在不改变系统高耦合性的现实的情况下，两者都不能很好的工作。(我个人倾向于feature team，component team只会产生更多的耦合性，然而feature team的挑战太大了，最后可能死得很惨。)
因此，我认为系统的耦合性是大型软件产品开发的各种主要问题的根本原因。
按照原本的计划我想写写：
软件系统设计中的耦合性
已经写了这个，和上一篇周星驰电影道具中的“高内聚，低耦合”
系统耦合性与可测性的关系
- 对于这个话题已经在本文中写了一些，我对测试的理解有限，不知道能不能写出更多的东西来了。
解耦合的一些手段
- 另外还想写写耦合性和组织结构的关系
- 已经写了一篇Conway's Law
- 也许将来有了更多的想法再多写一些
博文
没有评论:
发表评论