浅谈软件工程的困境

软件开发存在一个典型困境“扩展”（scaling），即怎样服务更多的用户。随着项目规模和团队规模的增加，就会出现管理难度的加大，大团队生产率下降的现象。而《软件工程》就是研究，如何扩展软件和团队，适应大项目的需要。

大项目的困境

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

起初，产品简单，功能有限，开发人员也就一个或者三两人。

随着迭代和新功能不断增加，促使更多的人员的投入，bug修复等待，，后续迭代的速度开始长于预期，总之，新功能的开发日程变长了。自然反应是扩充团队，但是新成员不是 1+1=2的效果。

这所导致的普遍现象是团队规模越大，每个人的平均生产率越低。随着时间推移，代码逐渐老化，复杂性不断增加，项目开始停滞不前。某些极端的情况下，软件的维护成本变得非常高昂，并且几乎不可能进行更改。最终，这个项目成为技术债务，等待被新项目替换。

大项目困境的原因主要有两个：代码复杂度和团队协调管理难度。

代码量增加，复杂度提升，中途加入存在紧张的开发周期和代码是否重构的矛盾，导致技术债不断积累，人才流失。

交流成本的增长速度是人员增长速度的平方。大团队通常被拆分成小群体，对等的交流会被自上而下的交流所取代。团队成员从平等的利益相关者变成普通的工作人员，owner意识和责任感变得淡漠。这些都直接影响团队成员的工作动机。管理层为了解决问题，会尝试组建新团队和新的管理架构。但是，不管怎么做，大型组织都很难保持所有成员的积极参与。

大项目的开发效率低的根本原因是软件规模的增长，必然使得代码和团队变得笨重，除非早采取对策缓解，否则迟早出现困境。从原因入手，解决方方法可以是分别对代码和团队进行解耦。

代码/团队解耦

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

这样的话，就大大减轻了开发者的负担，只需要负责自己的代码即可，不需要关心其他部分的实现。每个部分都可以单独重构，不担心影响到其他部分。

团队也需要解耦。可以参考互联网的架构。互联网是迄今为止最成功的大型软件解耦实例，它之所以能够扩展，是因为它由一个个独立的节点组成。为了防止节点之间互相依赖，各个节点都遵循以下规则。

        1. 遵守公开的通信协议。

        2. 不需要了解其它节点的内部实现，就可以与之通信。

        3. 节点之间不直接共享状态，只通过通信交换数据。

        4. 每个节点单独开发和部署。

类似的，大团队应该遵循：

        1. 每个子团队都可以独立运作，不依赖外部人员。

        2. 子团队内部的运作，不需要被外部知道；

        3. 子团队之间的协调，应该按照公开的协议和规则，最好能够自动完成，避免私下协商。

 

 

其中，团队解耦需注意：

        1. 子团队的人数不宜过多，每个子团队最好不要超过5个人；

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

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

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

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

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

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

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