1.4　模糊的前端工程边界

“大前端”也好，“泛前端”也罢，不同的分工模式说明目前市场对于前端工程师没有明确的定位，前端工程师的工作范畴并不清晰。这种局面不仅造成了前端与其他职能岗位之间模糊的分工，同时也影响了前端工程服务体系的界定原则。

前端与X端

业务的类型和特征决定技术团队的组织架构，从而影响了各职能岗位之间的分工和协作模式。比如，对于传统的PC网站，与前端工程师接触最多的是服务端开发人员；而对于混合应用（App+Web），前端工程师则需要与App客户端开发人员频繁协作。分工模式的差异直接影响前端工程服务体系的具体形态，比如无SEO（Search Engine Optimization，搜索引擎优化）需求的Web应用可以大胆地采用SPA架构，这是目前最普遍、成本最低的前后端分离模式，可以实现动静资源的分离部署和发布。而对于涉及服务端渲染的Web应用，是否具备中间渲染层是影响前端工程服务体系的决定性因素。

前端与测试

一款软件或者应用的测试阶段一般需要依次通过单元测试、集成测试、端到端测试和验收测试。单元测试通常指对单个组件或者模块的逻辑正确性进行的验证过程。集成测试是单元测试的逻辑扩展，将多个组件或模块组合为一个复杂模块，然后测试其逻辑和功能的正确性。单元测试和集成测试通常由开发人员在将应用程序交付测试之前进行。端到端测试指的是将所有组件和模块组装成完整的应用程序后进行的技术性测试，测试范畴包括功能、性能、健壮性、稳定性等。目前我们所说的测试工程师通常主要负责这部分工作。验收测试可以简单理解为站在用户的角度去评估应用程序是否满足了需求，由需求方（通常是产品经理）负责，也有团队将验收测试交由测试工程师负责。

从Web应用程序整体架构的角度理解，前端和服务端的开发工作分别对应交互逻辑模块和业务逻辑模块，则前端单元测试的目标是在既定接口规范的前提下保证交互逻辑的正确性；服务端单元测试的目标是正确响应由前端发起的网络请求。在团队配合过程中，进行前后端集成测试之前有一个必要的流程：联调。顾名思义，联调就是将前后端联合起来进行调试，一般由前后端开发人员协作完成。在联调之前，前后端单元测试的具体实施均直接受到前后端分工模式的影响。

现实开发过程中一种很常见的场景是：开发和测试阶段使用测试接口，测试通过后前端开发人员将接口地址修改为线上接口地址后再进行部署和发布。这个流程不合理的地方在于：第一，很容易发生人为疏忽；第二，前端代码需要二次构建。虽然可以通过制定严格甚至烦琐的审查流程尽量减轻这些问题带来的影响，但仍不能完全避免。目前比较普遍的解决方案有两种：第一种是将与环境相关的所有数据抽离为单独的模块，作为配置参数单独放置于一个文件中，这是一种成本较低、易实施的方案；第二种是在仿真环境中进行测试，这种方案要求开发团队建立与生产环境基本一致的仿真环境。

前端与运维

如果说前端与其他职能团队之间的分歧主要在于某些功能如何实现，那么前端与运维的分歧便集中在某些功能应该交给谁来做。一部分（可以说是绝大部分）企业对于技术团队的组织架构划分秉承着研发与运维分离的原则，即将负责业务开发、测试、设计等职能的岗位汇总在一起组成“应用研发团队”，将运维岗位独立为“线上保障团队”。这种组织架构模式下典型的协作流程，如图1-4所示。

图1-4　传统的研发与运维职能分配

项目经过需求设计、交互设计、开发以及测试之后，开发人员将项目代码递交给运维人员，递交的方式多种多样，可以通过SVN或者Git平台作为递交中介，也可以通过特定的运维平台上传文件，甚至干脆将压缩包通过QQ或者邮件直接交付。运维人员收到上线请求之后将项目文件进行部署和发布。同时，运维人员还负责服务器预警处理以及版本回滚等操作。可以说开发人员将项目文件交付给运维人员之后便无须关心后续环节了，他们只需静静地等待项目上线以后修复用户反馈的bug。

将开发与运维分离的主要目的是保障线上的稳定性。开发人员不直接接触生产环境，减少了很多人为失误导致的低级错误。除此以外，通常还会建立固定的上线周期，比如非紧急情况下只允许周二和周四上线。这种模式的优劣本书不做评价，但毫无疑问影响了迭代的自由度。近几年，与这种组织架构相反的DevOps模式开始崛起，目标是实现软件开发、测试和发布的敏捷性和持续化。但DevOps在国内企业的布道仍然任重道远。

开发与运维的协作关系直接影响工程体系在部署环节的具体形态。比如，在开发与运维分离的模式下，开发人员基本不需要关心持续化的问题，但是在DevOps模式下，持续化与每个人都息息相关。本书将在第8章详细讲解其中的细节。