最近有些忙，就是给团队里的同事写的代码进行工程化。 只是这些活对我而言有些过于体力活，我干起来提不起兴致。
这个过程中也发现很多人不理解什么是“软件工程化”。导致的结果就是，很少人知道我干的事的价值，也不知道该如何与我配合。所以，有必要正式给大家介绍一下我做的“软件工程化”指的是什么。
要介绍软件工程化，我们首先要从程序员写出来的代码开始说起。
首先，程序员写出来的代码，并不能直接运行。不同的编程语言，要运行起来，所经过的步骤不同，我们以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，其实它是软件工程化的集大成者。它标准且自动化了软件的构建、部署、可观察性、软件的运行方式。它真正做到了软件的工程化。
个人经验总结
- 标准化与自动化的顺序并不是固定的。有时，你需要先自动化，再标准化。因为不自动化，没有人力做标准化。
- 标准化涉及很多技术细节，在你还不了解何种标准更优时，千万要先松后紧，不要一开始就把标准就定得全面且死板。标准是演化出来的。
- 部署过程的标准化，大多数人只记得对应用的部署，却忘记了对配置也进行同样的标准化部署。
- 工程化需要一个人知识面非常的广，要懂多种语言、多种构建工具、多种部署工具、多种监控方式。
