最近有点忙，就是对团队同事写的代码进行工程化。只是这些工作对我来说有点太体力了，做起来提不起劲儿。在这个过程中，我也发现很多人并不理解什么是“软件工程”。结果是很少有人知道我所做的事情的价值，他们不知道如何与我合作。因此，有必要正式向大家介绍一下我所指的“软件工程”。介绍软件工程，首先要从程序员编写的代码说起。首先，程序员写的代码不能直接运行。不同的编程语言有不同的运行步骤。我们以Java为例。Java代码运行需要以下几个步骤：1、下载依赖2、编译3、打包4、安装运行环境，即JDK5、启动程序步骤1、2、3通常称为构建过程.很久很久以前，构建过程都是在程序员自己的开发机器上完成的。后来，想偷懒的程序员发明了Ant工具，它使构建过程自动化。但是Ant工具本质上只定义了一种基于任务的DSL（DomainSpecificLanguage），不利于标准化。这时，马文出现了。它标准化了步骤1、2和3。也就是说，构建过程是标准化的。多说一句，在这方面，Gradle相比Maven其实是在倒退。在构建过程中，除了构建工具本身的标准化外，我还会对构建环境进行标准化。这个过程就是根据不同的构建环境创建对应的标准化Docker镜像。将来，同一项目的每个构建都将使用相同的构建环境。构建过程的标准化只是软件工程的一个阶段。下一阶段是构建过程的自动化，即将构建过程放到一个标准化的构建环境中自动执行。也就是说，程序员仍然可以在本地执行步骤1、2、3，但团队不再使用程序员本地构建的结果，而是在标准化的构建环境中构建。我在做建筑自动化工作的时候，经常有程序员不屑的说：我本地电脑一条命令就可以把包上传到产品仓库了。这种情况，我听过很多。我想说：是的，你确实可以一条命令解决问题。但你刚刚解决了你的个人问题。你还没有解决软件团队的问题。软件工程要解决的不是团队合作的问题，而是个体的问题。你的不屑就像当年福特汽车厂手工造车的工人，看不起流水线上生产出来的车。在设计构建过程之后，我们开始设计步骤4和5。步骤4和5称为部署过程。部署过程的工程化与构建过程的工程化类似，也是先标准化后自动化。在Docker之前，准备运行环境和规范启动程序是非常困难的。每个公司都不一样，同一家公司下的不同团队很可能不一样。有了Docker，一切都变了。突然之间，标准化任何语言的程序部署过程变得非常容易。把原来的应用改成使用Docker的过程，就是一个运行环境标准化的过程，也叫容器化。它带来的好处是部署过程不关心你的运行环境。也就是说，部署过程与软件运行环境是解耦的。如何对部署过程进行工程化，我之前的文章中已经讲解过，本文不再赘述。这时候你发现我们上面的1、2、3、4、5步骤所做的无非是将软件生产工程的物理部分标准化和自动化。这是软件工程。关键是，你能确定什么是身体部分，什么是精神部分吗？另外，大脑部分还需要充分发挥大家的创造力。最后想想Kubernetes，其实是软件工程的高手。它标准化和自动化软件的构建、部署、观察和运行方式。真正做到了软件工程。个人经验总结标准化和自动化的顺序是不固定的。有时，您需要先实现自动化，然后再进行标准化。因为没有自动化，就没有人力去做标准化。标准化涉及许多技术细节。先放松后收紧，才能知道哪个标准更好。不要一开始就把标准定得全面死板。标准不断发展。部署过程的标准化，大多数人只记得应用的部署，而忘记了同样标准化的部署配置。工程需要一个人的知识面非常广，必须懂多种语言、多种构建工具、多种部署工具、多种监控方式。
