在聊工程化之前，对于“工程”我们进行再一次剖析。
首先，何为工程化。 我个人认为即为了适应纷繁复杂的软件变化和演进而提出的相关方式方法，其目的是为了更好的排兵布阵、分工协作。
工程过程中也意味着取舍
软件工程，将工程化的概念左移，在软件设计之初就引入工程化的思想，囊括住软件的全生命周期。
研发效能
当我们在谈”工程化“，我们究竟在谈什么？
有人讨论，是因为存在问题，而问题就在于实际的研发效率，已经远远低于预期了。
企业初创期，一个idea从形成到上线，也许只需要1~2小时，而随着企业的发展，类似的事情的执行与落地往往需要多个团队协同，花费数周甚至是数月才能完成。 这便造成了鲜明的对比，而这一对比，对于没有深入理解软件工程的人来说，显得难以理解，可有往往无计可施。
- 效能：衡量产品的经济效应
- 效率：提升业务的响应能力，提高吞吐，降低成本
本质复杂度与偶然复杂度
21世纪初，早期的互联网从业者开发简易的网站只需要学会使用Linux、Apache、MySQL、PHP（Perl）即可。可如今，在大型互联网公司工作的开发者，，需要学习理解的技术栈早就不知道上升了几个量基本别。如开发框架、分布式、微服务、云原生等等。
如果仅仅是这些复杂度还好，毕竟都是行业的标准技术，以开发者的学习能力，很快就能掌握。令人生畏的是，大型公司中都有一套或多套软件系统，这些软件系统的代码规模往往在百万行以上，质量有好坏而开发者必须基于这些系统开展工作。因此研发效率大幅度降低，其中一个核心的因素——软件复杂度的指数级上升。
Fred Brooks 在其经典著作《人月神话》的【没有饮弹】一文中对于软件的复杂度有着精彩的论述，他将软件复杂度分为本质复杂度与偶然复杂度。
本质复杂度与偶然复杂度这2个词来源于亚里士多德的《形而上学》，在亚里士多德那里，本质属性是一个物体必然拥有的属性，而偶然属性是一个物体可以（也可以不）拥有的属性。
- 例1、一个电商系统必然会包含交易、支付、商品等业务复杂度，而这个复杂度是天然就有的，故称之为本质复杂度。
- 例2、一个电商软件可以是基于容器技术进行管理部署，技术体系选型为Java。而这些间接引入的复杂度，称之为偶然复杂度。
Fred Brooks 所描述的本质复杂度，指的是来自问题域本身的复杂度，除非缩小问题域的范围。 否则是无法消除本质复杂度的，而偶然复杂度是由于解决方案带来的。
我们还可以从所谓的问题空间（Problem Space）和方案空间（Solution Space）来理解这2个复杂度，问题空间就是现实的初始状态和期望状态，以及一系列约束规则（我们通常称之为业务），方案空间就是工程师设计实现的，一些从初始状态达到期望状态的步骤。缺乏经验的工程师往往在还没理解清楚问题的情况下就急于写代码，就是缺乏对于问题空间和方案空间的理解，而近年来领域驱动设计为那么多工程师所推崇，其核心原因就是它指导了大家重视问题空间，去直面本质复杂度。
《人月神话》写于1975年，距今已有47了，Brooks认为软件的复杂度是无法得到本质上的降低的，同时认为随着高级变成语言的演进，开发环境的发展，偶然复杂度会得到本质的降低。
如何进行高效的工程化实践
- 统一概念
- 树立指导思想与标准
- 沉淀最佳实践（软件设计,代码风格,安全编码）
- 工具\平台以及自动化
- 方式方法与规律