我是如何做软件工程化的

这个过程中也发现很多人不理解什么是“软件工程化”。导致的结果就是，很少人知道我干的事的价值，也不知道该如何与我配合。所以，有必要正式给大家介绍一下我做的“软件工程化”指的是什么。

要介绍软件工程化，我们首先要从程序员写出来的代码开始说起。

首先，程序员写出来的代码，并不能直接运行。不同的编程语言，要运行起来，所经过的步骤不同，我们以Java来例。Java代码运行起来需要以下几个步骤：

1. 下载依赖 2. 编译 3. 打包 4. 安装运行环境，即JDK 5. 启动程序

1,2,3步骤，我们通常称为构建过程。Long long a ago，构建过程全在程序员自己的开发机上完成。后来，想偷懒的程序员发明了Ant这款工具，将构建过程自动化了。但是，Ant这款工具本质上只定义了一个基于任务的DSL（领域特定语言），不利于标准化。这时，Maven出现了。它将1,2,3步骤进行标准化。即，构建过程标准化。说多一句，在这方面，Gradle相对Maven其实是开了倒车。

构建过程，除了构建工具本身的标准化，我还会将构建环境标准化。这个过程就是根据不同的构建环境创建相应的标准化的Docker镜像。将来，同一个项目的每一次构建都使用相同的构建环境。

构建过程的标准化只是软件工程化的一个阶段。下一个阶段是构建过程自动化，即，将构建过程放到一个标准化的构建环境中自动化执行。换句话说，程序员依然在本地可以执行1,2,3步骤，只不过，团队不再使用程序员本地构建出来的结果，而是使用标准化的构建环境中构建出来的。

在我做构建自动化的工作的时候，常有程序员不屑地说：我在本地电脑就一条命令，就可以把包上传到制品仓库了。

这样的话，我听了很多了。我想说：是的，你的确可以一条命令解决问题。但是你只是解决了你个人的问题。你并不没有解决软件团队的问题。软件工程化要解决的是一个团队协作的问题，而是个人的问题。你的不屑就像当年在福特汽车厂里手工造车的工人，看不上流水线生产汽车。

在对构建过程工程化后，我们就开始对4,5步骤进行工程化了。4,5步骤叫做部署过程。部署过程的工程与构建过程的工程化类似，也是先标准化，然后自动化。

在没有Docker之前，运行环境的准备和启动程序的标准化是非常困难的，每个公司不一样，同一个公司下的不同团队也大概率不一样。

有Docker之后，一切都变了。一下子任何语言的程序的部署过程的标准化都变得非常容易了。

在将原来的应用改成使用Docker运行的过程，是运行环境标准化的过程，也被我们称之为容器化的过程。

它所带来的好处是部署过程不用关心你的运行环境。也就是部署过程与软件运行环境进行了解耦。

部署过程如何做到工程化，我之前的文章已经有说明，本文就不再细说。

这时，你发现，上面我们对1,2,3,4,5步骤做的，无非就是 把软件生产工程中，体力的部分进行标准化，然后自动化。这就是软件工程化 。关键是，你能否识别什么是体力部分，什么是脑力部分。

另，脑力部分，还是需要发挥每个人创造力。

最后，想想Kubernetes，其实它是软件工程化的集大成者。它标准且自动化了软件的构建、部署、可观察性、软件的运行方式。它真正做到了软件的工程化。

*文章来源于网络，如有侵权请联系本网站*