从软件工程角度分析大项目的困境与解决

黄翔

摘 要：一般情况下，只有亲身参与过大项目的开发，经历过大团队，才能感受为什么软件工程很重要，又很难做对。软件开发有一个难题，叫做“扩展”（scaling），即怎样服务更多的用户，并发用户数上升一个数量级，软件就必须重构，大量问题随之产生。本文利用軟件工程的思维研究、如何扩展软件和团队，适应大项目的需要，对大项目的困境做出分析研究并提出相应解决方法。

关键词：软件工程;代码解耦;团队解耦

一、引言

大项目的技术难度高，管理难度更高，而且大团队的生产率往往很低，行动缓慢。

只有亲身参与过大项目的开发，经历过大团队，才能感受为什么软件工程很重要，又很难做对。

软件开发有一个难题，即扩展，怎么样服务更多的用户，10000个并发用户，跟有10个并发用户，这是完全不同的概念，哪怕功能完全相同，背后的实现是完全不一样的。并发用户数上升一个数量级，软件就必须重构，大量问题随之产生。

二、大项目的困境分析

一个典型的大型软件项目，开发过程通常是最开始的时候，它是一个小项目，开发人员就是两三个人，甚至可能只有一个人。产品比较简单，功能很有限。第一版发布后，拿给客户使用，反响不错。客户要求的新功能，能够很快开发出来，Bug 修补也很快，因为早期客户往往可以与开发人员直接沟通，快速反馈。

公司于是决定投入更多人员，开发这个项目。团队慢慢变大了，软件开始变得复杂，开发速度逐渐变慢了，2.0 版花费的时间比预期要长一点。Bug 的修复难度开始增加。总之，新功能的开发日程变久了。

公司的自然反应是进一步扩充团队。但是更多的新成员其实会降低其他人的生产率，一个普遍现象是团队规模越大，每个人的平均生产率越低。

几年以后，代码逐渐老化，复杂性不断增加，项目开始停滞不前，最终这个项目成为技术债务，等待被新项目替换。

产生上述困境的其根本原因有两个，其一就是代码复杂度，随着代码量的增长，单个开发者想要理解整个代码库，变得越来越困难，不真正理解系统，过时的代码开始累积，技术债务就这样出现了。其二就是团队问题，随着团队成员的增加，交流成本开始指数式上升。如果整个团队有 n 个程序员，为了了解其他人的工作，你需要跟 n - 1 个人逐一交流，那么整个团队的交流路径总数就是 n * （n - 1） / 2。这意味着，交流成本的增长速度是人员增长速度的平方，团队人数越多，协同的难度就越大。不管怎么做，大型组织都很难保持所有成员的积极参与。

三、软件工程的解决办法

大项目的开发效率不高根本原因是软件规模的增长，必然使得代码和团队变得笨重。解决这个问题就需要从代码和团队两方面去解决。

从软件工程的角度进行代码解耦，将软件解耦，拆分成组件或者模块，防止各个部分紧密地耦合在一起。每个组件和模块，都可以独立开发，通过公开的接口被其它部分调用，每个部分都可以单独重构，不担心影响到其他部分。

从软件工程的项目管理的角度去进行团队解耦，把人员分开。首先，每个子团队都可以独立运作，不依赖外部人员。人数不宜过多，每个子团队最好不要超过5个人。其次，子团队内部的运作，不需要被外部知道。最后，子团队之间的协调，应该按照公开的协议和规则，最好能够自动完成，避免私下协商。

四、结束语

很多大团队按照人员角色分组，比如架构组、开发组、DBA 组、测试组、工程组等等，这是错误的。这样完全没有解耦。正确做法是按照软件的业务功能分组，每组负责一个全流程的软件大功能，设计、编码、测试、部署、支持等人员都在同一组。这样才能做到解耦，以及独立的交付和重构。另外软件架构师的角色也很重要，保障各种服务与整个系统运行状况之间的协议和通信，保证代码和团队可以正确解耦。

本文通过对大项目的问题的分析并提出解决方法。着手从代码复杂度和团队管理两个方面阐述了大项目解决方法。

参考文献：

[1]赵俊，石春. 探究软件开发进程中项目管理与软件工程的结合[J]. 电脑知识与技术，2020，16（11）：82-83

[2]崔萌萌，安强. 项目管理对软件工程开发的必要性研究[J]. 科技风，2017（17）：65. DOI：10.19392/j.cnki.1671-7341.201717057..

[3]周竞亮. 软件工程在大型工程管理系统开发中的实践[J]. 人民长江，2009，40（17）：86-88. DOI：10.3969/j.issn.1001-4179.2009.17.030.