软件工程的难题-解耦问题

一、引言

大学有一门课程《软件工程》，研究如何组织和管理软件项目。

国外有很多专著，研究这个问题。前些日子，我读到一篇文章，推荐了两本书。第一本叫做《加速：构建和扩展高性能技术组织》，第二本叫做《规模：生物，城市和公司的普遍法则》。

二、大项目的困境

一个典型的大型软件项目，开发过程通常是下面这样。

最开始的时候，它是一个小项目，开发人员就是两三个人，甚至可能只有一个人。产品比较简单，功能很有限。

最终，这个项目成为技术债务，等待被新项目替换。

（2）团队原因

随着团队成员的增加，交流成本开始指数式上升。如果整个团队有 n 个程序员，为了了解其他人的工作，你需要跟 n – 1 个人逐一交流（口头或者书面），那么整个团队的交流路径总数就是 n * (n – 1) / 2。这意味着，交流成本的增长速度是人员增长速度的平方，团队人数越多，协同的难度就越大。

四、解决方法：代码解耦

大项目的开发效率不高，把这个问题归咎于程序员的技术水平低和管理不善，都是没用的。 根本原因是软件规模的增长，必然使得代码和团队变得笨重。 除非很早就认识到问题的根据，采取缓解对策，否则前面描述的情况，迟早都会出现。

解决这个问题，要从代码和团队两方面着手。

代码层面的解决方法是，将软件解耦，拆分成组件或者模块，防止各个部分紧密地耦合在一起。每个组件和模块，都可以独立开发，通过公开的接口被其它部分调用。

（2）子团队应该是一个小型的全功能软件开发组织。

很多大团队按照人员角色分组，比如架构组、开发组、DBA 组、测试组、工程组等等，这是错误的。这样完全没有解耦，还是瀑布式流程，各组之间依然互相依赖，工作时必须与别组单独协商。而且，可能会产生利益冲突，比如，开发组希望尽快交付，而测试组希望多一点时间测试。

正确做法是按照软件的业务功能分组，每组负责一个全流程的软件大功能，设计、编码、测试、部署、支持等人员都在同一组。这样才能做到解耦，以及独立的交付和重构。每组内部使用什么工具、如何实现某个功能，都是自己决定，各组之间不需要共享内部细节，也不依赖别组的工作。

（3）大团队应该保障子团队的自主权，按照子团队提供的功能和商业价值，进行资源分配。

（4）软件架构师的角色很重要。

软件架构师的关注点，不应该是团队使用的工具和技术，而是各种服务与整个系统运行状况之间的协议和通信，保证代码和团队可以正确解耦。

（5）代码解耦和团队解耦的关系。

理想情况下，代码解耦与团队解耦保持一致，形成一对一的关系，一个子团队负责一个独立的模块。实际运作中，一个子团队负责几个模块也可以，但是一个模块不能由多个子团队来参与。

（6）通信（模块之间的、子团队之间的）尽量规范化，争取做到过程简单、文档充分，最好有规范的 API，这样无需任何人员交流，就能建立通信。

• 参考：
• 软件工程的最大难题
• 应对复杂之道：组织架构和技术架构的双解耦
• CODE RANT