"...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
"设计系统的组织不可避免的要产生与其组织的沟通结构一样的设计。"
---Conway's law
例如由4个团队来开发一个编译器，那么最终的产品很有可能包含4个编译过程。
Conway's Law告诉我们的应该不是一个宿命，而是一个我们要努力摆脱的东西。不是说既然系统结构的宿命是抄袭组织的结构，研发机构就应该乖乖的按component teams的方式来组织。Feature Team的目的就是让组员以end-to-end customer feature为目标，横跨系统架构而工作，充分利用团队的协作与沟通。这使得component架构成为开发的工具而不是宿命，更不是目标。
然而最近读到了一篇文章为Conway's Law提供了大量事实的证据，似乎与上面的观点相冲突：
http://www.hbs.edu/research/pdf/08-039.pdf
该论文以软件行业为例子，研究开发团队组织与沟通结构对软件产品结构的影响。它从软件模块化与耦合性的角度在开源软件和商业软件之间进行比较。结果发现：
- 开源软件被划分成很多小的模块，模块之间的依赖性很小。
- 商业软件却往往有很大的模块，在其内部各单元间依赖性很强，或者模块间的依赖性很强。
产生这种差别的原因可能是：
- 设计的自然演化：
- 商业软件往往是在同一家公司，同一地点，由专职的团队开发的。通常问题可以通过面对面交流来解决。因为容易获得模块内部信息，可以在架构内进一步压榨系统的能力。这些都潜移默化地增加了系统的耦合性。尽管这不是管理者主观的选择，其结果往往是软件架构变得耦合性越来越高。而在开源软件的开发中则刚好相反。大型的开源软件分布在世界各地开发，开发人员可能从未谋面。这使得开源软件越来越模块化。
- 架构设计者的主观选择：
- 商业化软件要面临竞争，在给定时间内实现最大的功能。这种情况下模块化的好处可能不会被看重。而模块化对开源软件却至关重要，没有模块化，开源软件的贡献者几乎不可能理解设计并做出自己的贡献，也没办法在不影响其它功能的前提下开发新的feature或改正旧的错误。所以开源软件需要模块化来吸引开发人员和协调他们工作。
他们的研究对软件合作与外包提供了一些理论上的支持。这可能与我看到的现实情况不符，很多企业因为外包了部分工作而搞得焦头烂额。我猜其原因可能与发包企业的期望有关。发包企业理所当然的期望更好的在短期内应对竞争，而要做到这一点，不单要有开发人员间有效的沟通，也可以从尽量发挥系统模块间的耦合获得大量的即得利益。这些都是外包所不支持的，尤其是off-shore形式的外包。当然，发包企业也关心系统的可维护性和可扩展性。但眼前的竞争看上去事关企业存亡，这使得企业难以发现长远的好处。
更好的模块化并不见得一定以其它性能为代价，而往往是架构设计仍有改进的空间。
那么是不是没有流畅的沟通会更有利于产生模块化、低耦合、易于维护和扩展的系统呢？文章并没有讨论这个问题。但我想，当我们有更好的沟通条件和组织方式时，我们其实多了更多的选择。通过洽当的软件工程手段和管理手段应该能够灵活的吸取在开源软件中积极的经验吧。正如我前面说到的，系统架构应该是工具，而不是宿命。除非真的象Mel Conway在68年时说的那样，这种映射关系对于organization来讲是“constrained”的，或者我在另外一个来源里看到的是“inevitable”的。
我希望那个是玩笑。
记录一下接下来打算写写的几个话题吧：
- 软件系统设计中的耦合性
- 系统耦合性与可测性的关系
- 解耦合的一些手段
博文
没有评论:
发表评论