1.2　架构与工程

一些国外的公司会将开发人员的职称分为Developer（开发者）和Engineer（工程师），国内的IT和互联网公司起步较晚，在职称划分上没有那么精细，通常将一线的开发人员统称为工程师。开发人员（程序员）有时会自嘲为“码农”，把工作称为“搬砖”，因为很多一线的开发日常仅仅是一些在既定环境、架构和规范下执行简单且重复的体力劳动。在相对成熟的技术环境下，一线的开发人员不需要开疆扩土，只需按照统一的规范，使用既定的技术栈完成被分配的任务，然后把编写的代码放到指定的服务器上即可。这种类似工厂生产流水线式的枯燥工作时常令人感到厌烦甚至怀疑自己的价值，但对于整体而言却是一种非常高效的模式。这种模式恰恰是工程师职称中“工程”两个字的意义，其建立者通常被称为架构师。

可能是因为软件架构流行的年代晚于软件工程[6]，学术概念上的软件架构汲取了软件工程早期的一些优秀理念，强调大型软件系统的设计方法论和实施模式。但学术有时候过于“高冷”，现实中并不一定要求项目具备足够高的复杂度才会涉及架构，即使一个最简单不过的静态页面也存在架构，只是太过于简单，缺乏深入研究和讨论的价值。但是不论量级大小，任何项目都会涉及开发、测试、发布和维护，这些流程均属于工程领域。除了项目本身的复杂度以外，业务的类型、场景、平台、用户群体等特征同样是架构的决定性因素。比如，Flash播放器对于一个运行于手机浏览器的直播网站完全没有应用价值；再比如，一个国际化网站的架构中必然要加入对多语言环境的支持。也就是说，任何关于架构的设计和实施必然以业务特征为根本出发点，否则毫无意义。而支撑项目的正常运行仅仅是衡量架构合理性最基础的标准，除此之外，架构的设计往往需要考虑高可用性、可扩展性、可伸缩性、性能以及安全，要保证项目在多变的生产环境下能够高效且稳定地运行，这些因素同样是从工程角度考虑的要点。

软件工程这一概念被提出的初衷是解决软件危机。[7]典型的软件危机有以下几个方面：

● 成本超标，包括硬件成本、人员成本、时间成本等。

● 性能不理想且功能不稳定。

● 开发过程混乱无序难以管理。

● 代码不规范，维护成本高。

从经济学的角度来看，软件危机的问题是昂贵的成本没有换来对应的收益，这也是工程学与学术研究最大的分歧之一。[8]工程学方法的核心是结合实际情况建立科学的、规范的设计和生产流程，降低生产成本。将这一理念带入软件开发领域便形成了软件工程。

代码和流程是软件工程的核心关注点。从代码的角度考虑，工程的目标是保证软件的高可用性、可扩展性、可伸缩性、性能以及安全，这些要素共同组成了软件的技术架构。在架构之外，工程从更宏观的角度完善开发和维护流程的管控，强调项目迭代的规范性、有序性、可控性和高效性，并根据架构特征提供额外的辅助功能。也就是说，架构是工程的子集，两者的关系可以简单概括为图1-3。

为了便于区分和理解，本书将前端工程化于架构之外的部分称为前端工程服务体系。如此便得出了前端工程化的定义：

前端工程化 = 前端技术架构 + 前端工程服务体系

世界上第一个计算机软件产生于什么年代可能无从考究，但自1935年艾伦·图灵建立计算机软件理论以来，软件架构与工程发展至今已然具备了相对成熟的理论并且积攒了丰富的行业实践经验。但是在前端开发领域，相对而言，架构与工程这两个词却仍然比较新颖。前端工程师这一岗位的历史较短，前端架构与工程也仅仅在近几年才刚刚起步，不论是理论还是实践均处于探索阶段，远没有形成成熟的模式和方法论。软件工程与架构着眼于软件的整体，是宏观的概念。将讨论的范畴聚焦于前端（即交互逻辑层），传统的软件工程方法论与架构设计理念并不完全适用，其原因主要有两点：前端技术架构的零散性以及模糊的工程边界。