工程
在 20 世纪 七八十年代 出现了一系列的 “软件危机”，
不少软件项目的结局都很悲惨，
要么远远超出了规划的时间表，要么软件的质量难以控制。
人们意识到软件领域中遇到的这些问题，其实可以用 工程方法 得以改善和解决。
工程师最关键和独特的特点是，发现、理解并结合实际的局限，来达到满意的结果。
后来又经过几代人的研究和实践，不断丰富形成了软件工程这一学科。
所以，软件工程师这个职业自诞生一来，
就是为了解决上述软件问题的，包括但并不限于软件功能的实现。
这是因为要实现一块功能往往是比较容易的，但对整个软件开发活动进行管控却很难。
我们需要关注项目、产品、质量、人员 等一系列因素，
才能结合实际情况达成满意的结果。
那么现在为什么会有专门的 “工程化” 这个说法出现呢？
这是因为软件工程师出现后，软件行业经历了飞跃发展，人才涌入促进了社会化分工。
大家会考虑如何进行资源重组，能够实现更高的产能。
此外软件领域内部的知识量也越来越大，分治才能解耦进一步提高生产力。
在这种趋势之下，软件工程师被划分成了很多不同的角色，
现在前端、后端、数据库、算法 不同角色的划分只是社会化分工阶段的一次快照，
以后这些角色还会不断的调整。
群体
以上是前些年的事情，最近市场环境又出现了新的变化，
软件工程师的人数进一步扩增，甚至已经变成了不小的一个社会性的群体。
这一群体的出现，会带来如下这些影响，
软件工程师人数增多，逐渐会产生一些社会学效应。比如 996、内卷 很大程度都是被这一群体带动起来的
这一群体具有一定的相似性，会有专门的为软件工程师提供服务的产品出现，不论是生活上还是工作上
一个公司有成百上千名软件工程师的情况已不再罕见，如何解决大规模软件工程师团队的合作和效率问题，关注的人会越来越多
软件危机引发了软件工程，软件工程师的扩增又会引发了新一轮的软件革命。
很多软件工程师或组织，对软件项目的理解还很原始，
或者说 “工程化” 问题还远远没有被解决。
有多少人仍深陷于延期、需求变更的泥沼中，
还有多少组织深陷于技术债务、基建不稳的困境中。
这其实是因为大家一开始就没有用工程方法来执行，
组织内部又缺少对工程理解比较深入的人员。
工程化
有人可能想说，不是有《软件工程》这门课程么？
为什么说大家对工程的理解还不够深入呢？
这是因为课程 和 实际项目 相距甚远，
课程不会说 软件项目的开发过程是按交付日期倒排的，
也不会说 在截止日期之前变更需求应该如何拒绝，
更不会说 软件项目中遇到的大部分风险点其实出现在团队对外沟通的边界上。
这时候就会需要有一些人，既了解软件开发的整个过程，以便从中识别效率瓶颈；
又能洞悉人性，在各种利益纠纷中找到共赢点；
还要对产品定位、项目节奏有牢固的把控。
只有这样才能安全的摆脱 “软件危机”，实现整个组织的 “工程化”。
小结
“工程化” 其实并不仅限于技术这么简单，更多则是 “如何做好一个项目” 的推广和总结。
软件工程师利用各种手段解除 “软件危机”，过程中所形成的方法才是 “工程化” 方法。
做一个脚手架、搭建 CI/CD 系统、做组件库，我认为这些说法不够完整，
它们只是软件项目中的某一些关注点罢了，更核心的要解决的问题可能要复杂得多。
松下问童子，言师采药去。
只在此山中，云深不知处。