76 | 软件工程的未来

软件工程是一门非常年轻的学科，相比其他动辄跨世纪的自然科学而言，软件工程只有 50 年的历史。只有如此短暂实践的科学，今天我们来探讨它的未来，条件其实还并不算太充分。

但是我们的宗旨就是要每个领域都应该谈清楚过去（历史）与未来（趋势判断），所以今天不妨也理性来探讨一下。

在 “软件工程的宏观视角” 一讲中，我们引入了下图来表达软件工程的瀑布模型：

在这样一个模型里面，涉及的角色分工已经非常多：

产品经理；

架构师；

开发工程师；

质量保障（QA）工程师；

网站可靠性工程师（SRE）；

……

但这还只是常规描述的工种。实际的分工要细致很多。更不要说对特殊的领域，比如企业服务，也就是大家常说的 2B 行业，它的基本过程是这样的：

比之纯粹的产品研发上线过程，它多了单个客户的跟进与落地实施过程，也由此引入更多的角色分工，比如：售前工程师、交付（实施）工程师、售后工程师、项目经理等。

未来软件工程会走向何方？

首先 “快速变化” 是软件工程的自然属性，其 “不确定性” 也只能抑制而无法消除。

但显而易见的是，软件工程的问题最终还是由软件解决。事实上今天很多问题已经解决得很好，比如源代码的管理。我们经历了 cvs、svn，最终到今天的 git。基本上开发人员的协同问题已经形成非常约定俗成的方法论，并以软件或云服务的方式被固化下来。

今天，线上服务管理正如火如荼的发展。假以时日，不需要多久之后，一个全新的时代开启，我们中大部分人不必再为线上服务的稳定性操心。关于这块更详细的讨论，可以参考第四章 “服务治理篇”。

需求管理与测试这块也已经得到很好的解决。唯一比较遗憾就是是界面（UI）相关的测试虽然也有相关的工具链，但当前的普及率仍然极低。

这可能与大部分公司都较难保证界面的稳定性有关。如果我们经常变动界面，这就如同我们经常调整一个模块对外的接口规格一样，必然导致相关的测试案例编译通不过，或者测试通不过。这会让人沮丧，进而丧失对实现界面（UI）测试自动化的信心。自动化测试极其依赖被测模块接口的稳定性，这是我们今天常规自动化测试方法的限制。

当然另一方面，这也与界面测试相对高维，大部分公司的质量保障水平都还没有到达这个级别有关。从现实来看，虽然单元测试方法论已经极其成熟，但是仍然有不少企业在推行中遇到不少障碍。

可以预期，随着企业的平均工程水平逐步提升，最终会形成越来越多的有效的界面测试最佳实践的方法论，并得以大范围的推广。

从全局来看，今天软件工程已经形成较为成熟的分工。但各类分工的最佳实践与软件系统，仍然是相对孤立的。

这一定程度上也与软件工程还很年轻有关。从软件工程的软件系统发展来说，可以预期的是，未来一定会形成更加一体化的系统，上一道 “工序” 的输出就是下一道 “工序” 的输入。

但是今天一些 “工序” 的输出仍然是人肉进行传递，甚至没有标准化的仓库管理它。例如，产品经理输出的产品界面设计原型、架构师输出的架构设计文档，其传递过程仍然有极大的随意性。

但是，软件工程的最大不确定性就来源于 “设计” 类工作，包括产品设计与软件的架构设计。今天虽然产品设计和架构设计也都有一些独立的工具，但普及度与刚才说的开发与测试类工程实践相比完全是小巫见大巫。

这是可以理解的，产品经理与架构师在软件工程中属于小众群体，其培养难度极高，很多经验也很难形成传统意义上的 “知识点” 来传递。所以真正意义上合格的产品经理与架构师是比较少的，和程序员（软件开发工程师）的规模完全无法相比。

就拿架构师这个岗位举例。架构师的职责是什么，架构师工作的方法论是什么、培养架构师的方法论又是怎样的，这些今天并没有一个被广泛接受的实践。

而事实上，产品经理的培养有更高的难度。严格意义上来说，成为产品经理前，首先应该成为架构师。我这个观念可能与大部分人的常识相悖，但是个人对此深信不疑。

软件工程的未来发展会怎样，细节上很难给出确定性的判断。但是，我们相信，软件工程极大成熟的标志，是一体化的软件工程支撑系统，和高效的人才培养体系。包括今天仍然极为稚嫩的架构师培养体系，和产品经理培养体系，都应该得到了极大的完善。

到那个时候，软件工程就成为了一门真正成熟的科学。

结语

软件工程项目迭代快速、充满变化、充满不确定性。这使得软件工程成为一门极其独特魅力的科学。今天这门科学仍然还非常年轻，其发展只能以日新月异来形容。

软件工程的未来，它的成熟不单单是工程方法论和业务系统软件的成熟，也需要包括人才培养体系的成熟。因为，软件工程的不确定性与它充满设计与创造有关，人的主观能动性是它的优势，但也意味着不确定性无法得到彻底的消除。

我们要做的，只能说在大量的不确定性中，找到尽可能多的确定性。