这篇文章不讨论重复造轮子的问题，我希望的是从前端项目的开发过程入手，理清一个典型 Web 前端项目开发过程中都有哪些参与者、各个参与者在开发过程不同阶段的关键任务是什么、这些任务之间的上下游依赖和流转是怎样的，以及它们是在什么时候、以何种方式对前端开发产生影响的，从而探索一种标准的 Web 前端项目开发流程。
于是我画了下面这张图，
一种典型的Web前端项目开发流程
关注开发过程是因为过程相对稳定，稳定决定了我们有机会发现一些普遍问题，解决这些问题是改进流程的关键。分析影响是希望找到前端开发过程中的关键任务，并思考采取什么措施来应对影响和完善这些任务，想要完全消除某些影响也是有可能的，可以通过剧烈改变这种典型的 Web 项目开发流程本身，比如视觉编译，但这可能是另外一个维度的问题，我们姑且相信前端目前还是“没有银弹”的。
这是一个比较典型的 Web 前端项目的开发流程，包括了产品经理、设计师、前端、后端、QA 这几种角色，也列出了在项目不同阶段这些角色的主要任务以及和其他任务的上下文关系。
这篇文章关注的是Web 前端项目开发的一些特点，我不是专门搞软件开发过程研究或者项目管理的，只是参与和带领过一些前端项目的开发，谈一些从 Web 前端开发人员和团队角度看到的一些问题和思考。从上图中可以看到我把项目开发过程大致分成了立项启动、准备、需求、计划、设计、开发、测试/发布几个阶段。下面我们分别分析一下前端开发在这几个阶段的关键任务。
立项启动
首先要找到合适的人
项目启动的时候一般会组织一个项目启动会，通常是召集各个小组的 leader或者没有 title 的 leader 参加，内容通常是产品部门做下项目背景的简单介绍，给参与项目的各方同步一下关于客户、项目目标、大致时间的一些基本信息，让大家对项目本身有一些共同的认识。
这个阶段首要考虑的是人手安排，即需要哪些人、什么时间来参与到这个项目中来。虽然需求尚未细化，但是根据已有的信息我们也大致也可以估计一下项目的规模，到底是一个小型、中型还是大型项目，还需要考虑一下项目的交付时间要求，是宽松、紧张、还是非常紧张。
如果是一个小型项目的话，我们可能只投 0.5 个人进去，通常会选派手头现有项目已经进入维护阶段或者二期开发的同学，可以把主要时间、精力放在新项目上了。也就是说一个前端开发可能同时参与多个项目，他可能需要一天之内在几个项目之间进行切换，典型的一种工作状态是在新项目需求讨论、开发联调的间歇需要快速地处理另一个项目的一些 issue。
另一种情况是项目规模比较大、优先级比较高、时间又很紧张的情况，这个时候我们可以采取 all in突击的方式，即首先指定一个项目的前端负责人，前期的需求分析、评审、计划、排期阶段只需要他一个人参加，进入设计、开发阶段以后再拉更多的前端同学加入项目，每人分一些已经安排排期的功能点，并行向前推进进度，这种临时的集中突击通常不会超过两周的时间，不会对其他项目造成什么大的影响。突击完成之后，又可以把项目单独交给最初的项目前端负责人主要负责跟进，比如跟进需求的变更、接口的更新等，其他人力就可以暂时释放出来了。在 QA 测试阶段，如果 issue 比较多的话，还可以再来一次全军突击，集中处理 bug 和 issue。能够搞得起全军突击的一个前提是前端是一个大的资源池可以统一调度，另一个要求就是统一技术栈，也即是成员之间的能力是可以互换的，这就要求我们在一个组内不要搞多个技术栈，框架、预处理工具、构建工具、UI组件库、状态管理、路由管理、异步数据请求、代码风格和规范这些都要统一，最好是标准化、都是基于同一个脚手架构造的，这样新同学参与到项目中的时候可以快速启动。
前端团队的人力资源往往比较紧张，和后端的人员比往往是 1:6甚至1:10，经常面临人手不足的情况，除了通过优化流程、工具方法来提高效率，首要考虑的还是具体项目的人力投入策略。然后指定的前端负责人也很重要，可能会考虑他过往的项目经验，和该项目的后端同学、UI 同学是否有过合作等。
准备阶段
凡事豫则立，不豫则废
项目启动之后，产品同学就去写具体的产品需求文档了，我们一般叫 PRD（Product Requirements Docuemnt）。在这个时期前端同学需要提前做一些项目的准备工作，这些准备工作跟具体的产品功能关系不大，可能是更宏观一点的问题，我们需要收集更多前端需要关注的项目信息，使用场景，前端工作的侧重点是什么，如何满足客户和项目的要求，分工界面和协作方是谁，会有哪些风险以及如何预防和采取哪些措施。
用户是谁？
首先要进行用户分析，不光是产品和设计师，**前端也要了解用户**，因为前端是跟用户直接交互的，一切产品策划、UI 设计、后台能力最终都是通过前端对用户进行展示。
了解用户需要要考虑我们服务的的是 C 端用户还是 B 端用户？如果是 C 端用户的话，它们的画像是怎样的？如果是 B 端用户的话，用户属于哪个行业吗？它们的特点和习惯是什么？toC 还是 toB 决定了对前端的要求以及前端应该关注的重点是不同的。
如果是 toC项目的话，可能重点考虑前端性能、多运营商机房部署、CDN 服务、转化留存等运营的对接支持、数据上报和监控以及 UI 是否够炫、做一些个性化交互等；如果是 toB 的话可能首要考虑的是 UI 和交互的一致性、交互简单反馈直观明显、帮助信息是否到位、是否会有私有化部署的要求（比如是否要去除对内部系统的依赖）、项目的灵活配置和定制化支持、是否需要准备相应的文档等；如果是两者都有的话，可能意味着我们除了提供一套前台系统之外，可能还需要提供一个后台管理系统，那么后台管理系统和用户前台有哪些模块可以复用，复用会引入复杂性带来某些挑战么，可能都需要纳入考虑范围。toB or toC 是一个比较大的话题，可能需要一整篇的长文才能讲清楚。
PC、Mobile、小程序？
也就是前端的形态是怎样的，开发一个面向PC、移动端的 Web 还是小程序对前端来说可能是完全不同的项目。
面向 PC 的很多是 toB 的项目，特点是使用桌面浏览器，一般不会有性能问题，但是要考虑多种浏览器内核以及对低版本 IE 的支持的情况，也有可能可以通过对用户做出要求而仅支持有限的现代浏览器，也有可能因为行业用户的特点必须要支持较低版本的 IE 浏览器，比如银行，这可能要跟业务方坦诚沟通，一方面是因为现在客户对这方面的要求不那么死板，比如银行内网也有很多的 chrome，看他们 IT 的情况，另一方面对低版本 IE 的支持成本实在太高了。PC 项目在准备阶段重点要明确对浏览器支持的要求和最小屏幕尺寸等，否则后面可能会出各种幺蛾子。
Mobile 项目的特点是浏览器基本都是基于 webkit 内核的，相比浏览器的兼容性问题可能更多需要考虑的是交互和性能，不光是处理器的性能，还包括网络、延迟、缓存各种情况。准备好测试机、代理、证书这些移动端Web开发需要的东西，不光要在浏览器里面通过 Mobile Mode 进行开发，一定要在真机上测试运行。
技术选型和调研
用户和平台搞清楚之后前端的技术规格要求就基本明确了，还需要对项目中需要用到的新的、难的技术点开始做调研，并开发一些简单的原型进行验证，也可以在组内或者给产品做一些演示，看看是否满足项目要求，这些都是在准备阶段需要做的。这些重点难点的东西不在项目准备阶段或者开发初期解决的话，越往项目后期进度压力越大，越没有完整时间系统处理，可能会带来技术上的风险。
项目准备
新建 Git 仓库、立项申请、要集成的内部服务的申请、项目脚手架搭建、协同系统的帐号设置...
合作方都有哪些？
我做项目的时候一般会列一个清单，把全部的项目成员、职责都列出来。可以方便地对接是一方面，另一方面是做项目比较多的时候，有些人可能是第一次合作，甚至是跨部门合作，这时候可能就需要做一些标注、记录一些信息、时间点等，可以及时地做一些提醒、交接，特别是我们依赖的上游的合作方。
需求阶段
项目启动之后，各方也都开始从各自关注的角度开始理解需求。需求阶段是产品的重头戏之一，另一个是产品上线之后的运营分析和策划阶段。在这个阶段，产品会集中做一些用户调研、竞品分析的工作，然后开始写需求；UI 同学也会通过理解需求和竞品分析来确定整体的设计风格。
需求文档应当清晰、规范，要讲清楚需求的背景、解决的问题、为什么要这么解决、有没有更好的方式、竞品是怎么处理的以及为什么。
在产品需求文档完成以后，项目经理通常会组织大家进行需求评审，一般产品、UI、前端、后端同学都会参加，一起对需求进行分析。需求评审很重要，一方面是很少有这种机会把项目组的人都聚集在一起进行讨论，另一方面是如果在这个阶段各方对需求讨论不充分、理解不一致、认识不统一后面的开发、测试阶段一定会出差错。因此，评审前一定要认真阅读需求文档并对其进行标注，有问题的地方一定要记下来，评审的时候如果产品经理的陈述还不能解答这些疑问就可以提问。
对前端而言，需求最终是要落地成实际的操作过程和页面的，因此在需求分析的时候就已经要考虑前端的模块划分、功能点提取和技术实现了。前端在阅读需求的时候首先要提炼出其中的前端工作（如果 PM 没有把前端需求单列出来的话），对需求评审可以有一个自己的 checklist：
这个需求如果按照功能点的话可以划分为哪些子需求？
是否可以把该需求归类成一个个标准的前端模板/模式？比如标准登录页、列表页、表单页、监控页、仪表盘、工作台、标签页、分步表单等
是否有原型图？需求描述和原型图是否一致？
是否有流程图？流程是否有逻辑缺失？
功能是否有冗余？
操作路径是否过深？该突出的重点有没有突出？
是否有不符合 Web 用户操作习惯的地方？
逻辑复杂的地方是否有文案说明？
文字、图片、按钮排版是否合理？
整个产品的用户交互方式是否一致？
可以提炼出哪些标准化的页面、可复用的组件？
技术实现是否有难度？有没有哪个环节会争议在前端还是后端实现？
要确认需求的实现细节。比如搜索，是支持对哪些关键字进行搜索、是精确匹配还是模糊匹配、默认按照什么进行排序？
要确认需求的具体实现方式。比如分页，是上下翻页还是下拉无限加载的方式？
需要用户输入的数据校验规则、提示信息和文案是否完整？
有经验的前端开发人员还应该根据以往的项目经验和技术积累，在产品经理对功能点也不是特别明确的时候，给出适当的建议。
计划阶段
需求明确以后，前后端、UI、QA 就可以分别制定开发计划了。开发计划可以按照先把系统划分为不同的模块，然后把每个模块再划分为不同的功能点，可以按照 MECE 法则进行划分，再估算每个功能点的工时，最后参照上游 UI 和后台接口的排期确定前端每个功能点的开始和结束时间，然后得到整个前端开发的功能列表和排期，也就是开发计划。
计划的时候要注意前端功能的开发需要页面+接口联调才算完成一个具体的功能，这里面的页面开发需要依赖 UI 设计完成的时间，接口联调则需要依赖后端同学的开发计划，因此制定前端计划的时候要跟后端和 UI 沟通好，功能点的先后顺序最好要对齐。还有就是要卡住时间点，因为下游还有 QA 测试同学，也要给测试留出足够的时间，所以必要的时候也需要对设计稿和接口完成的时间有所要求
设计阶段
在设计阶段，前端主要做的是协助上游的工作。
一方面要跟设计师协作，如果有统一的 UI 规范还好，基本上 UI 组件可能也标准化了。麻烦的是 toC 类的项目，每个设计师可能会搞一套新的风格、甚至是非常不同的组件样式和交互出来，这就需要对前端组件进行大改或者完全重写，这个成本是很高的。不光是新开发的成本，新东西可能也不够稳定。这时候就需要跟设计师进行沟通，在保证设计效果的前提下，已有的设计没什么毛病的话不要搞一个全新的设计出来，尽量跟已有的统一，实在要搞评估一下时间是否允许，或者一次不要实现太多的效果，在测试和完善阶段可以继续改进。像我以前做的一个手机上的日历组件，开始只提供点击箭头切换月份的功能，后来逐步加上了滑动切换、支持展开按月浏览收起按周浏览、支持按周按月滑动、优化滑动的顺滑度、支持无限滑动等，最终做的比较完美，而如果一开始就追求完美，可能项目就不能按时交付了。
另一方面需要跟后端同学对齐接口，从 PRD 里面我们整理出接口需求，双方一起讨论具体需要哪些接口、参数是放到 URL 里面还是请求体内、是否需要分页、接口文档以什么形式提供，这个应该是有一个规范的，但是不同的后端团队规范可能还不一样，有些直接用的是第三方的、或者开源的实现，让他统一规范也不可能。但是我们可以有一个最小的要求，就是接口要用 OpenAPI 的形式来描述，这个对我们前端后面的开发无论是做 Mock，还是通过文档自动生成页面和测试代码都至关重要。还要注意的是接口的一致性，比如同属分页查询接口，那么表示分页信息的页码、页面大小、总条数这些表示都要一致，因为前端的接口请求方法往往会统一封装。另外，对接口的时候针对每个接口一定要事无巨细，每个字段的类型、有效值、必选还是可选、数据校验规则都要落实下来，因为这些在前端也都是需要落地的，不要怕讨论的时间过长，否则后面会花更多的时间。
对于复杂的功能和模块，在这个阶段也可以绘制一些图表梳理一下模块之间的交互和关系，比如数据流图、流程图、实体关系图、UML 的类图、时序图等。
开发阶段
开发阶段前端的窘境是需要并行开发，一方面要做页面重构，同时还要跟后台联调接口，需要两条线同时工作，也是手工工作最多的时候。但其实可以作为一个整体来处理，而且要认清数据模型在里面的关键作用，以一个实体相关的典型操作为例，如下图：
这是一个获取信息进行展示，编辑以后再通过接口写回后端的典型过程。在这个过程中前端需要编写详情获取和新建/编辑的接口，需要一个用于展示信息的页面，和一个用于编辑信息的表单，页面和表单可能还需要专门的状态进行管理。
你会发现在这个过程中所有的步骤都是围绕着实体在工作的，这个实体最早是在 API 文档中定义的，通过接口获取之后可能被加上了一些标识信息，在前端组件里面可能又混入了完成交互需要的一些信息，比如是否正在被编辑这种状态，但是没关系，所有这些流程都是可以被标准化和固化下来的，然后就可以通过代码自动化生成的方式生成基本可用的功能点，或者在此基础上再进行微调。这会减少大量的手工工作，说实话，有时间前端开发效率高不高跟键盘的响应速度有很大关系，大部分时间你可能都是在一遍遍地输入各种同样的字段名、格式化、校验、检查、异常捕捉。
实现标准化自动生成要有两个前提，一个是标准模板从哪里来？也就是你至少要先手动实现一个你认为是标准的符合最佳实践的模块，比如一个支持增删改查列的模块，也就是具有完整的列表页、编辑页、支持表格操作区、查询区等，然后把它抽象成模板；如果你还想支持图表的自动化生成，那就得先抽象一个图表的标准模板，得先有:chicken:才能下蛋；第二个前提是UI、接口要统一、前端技术栈要稳定，不能前一个项目是 React，后一个项目就要 Vue，再来一个项目用 Angular，复用不了，这种简单的抽象还是依赖于具体的框架、组件库以及封装的一个帮助类的，比如接口请求库。UI 和接口总变也不行，对于像云控制台这样有统一的 UI 和接口规范的项目其实满试用的，或者是内部的管理系统。我曾经开发过一个连业务代码和测试代码一起生成的 generator，原先需要0.5 天开发完的模块后来只需要十分钟连联调都一起做完了。
联调和自测我都是提倡自动化的，可以看我关于“JavaScript 测试指南”的系列文章。
测试阶段
测试阶段主要想说一下关于前端 issue 的处理，前端 Issue 很多时候问题的根源不在前端，只是表现在前端。一种情况是接口异常，这个时候可能是前端请求参数的问题，也有可能是后端接口不工作，前端可以帮助定位问题，然后分配给后端。当然最好的情况是 QA 同学能直接发现这是后端接口引起的，所以我以前会给 QA 同学做分享，分享 chrome 浏览器的开发者工具如何使用，有经验的 QA 同学碰到问题时一般也会看 console 有没有异常，如果还能同时看一下 Network 面板下的接口请求和应答就更好了。
另一种情况是设计如此，可能是 QA 同学觉得这个地方还可以改进，或者是开发过程中产品设计变更了，但是只同步给了开发而没有同步测试。我的经验就是有 issue 提醒了第一时间查看，快速定位问题然后回复，如果需要别人来处理更要第一时间把情况描述清楚，及时评论和流转。
需要自己处理的话，需要把做过的变更，如何修改的，修改完的效果一并更新的敏捷开发项目管理系统上，有个完整的记录可以回溯，最好和 git commit 记录能够进行关联。
总结
本文系统地介绍了前端项目开发的关键流程，目的是探索出一种标准化操作流程，在这个流程中各个角色可以各司其职，发挥协同作用，实现卓越研发。
同时，通过对流程的分析，我们可以发现前端的瓶颈在于开发阶段要处理产品 -> UI -> 前端，产品 -> 后端 -> 前端两条线，这里面有大量的手动、重复工作，特别是对于中后台 Web 项目，我们可以通过组件化、标准化、工程化的方式实现部分的自动化和智能化。关于如何以数据实体为中心、如何通过 API 文档自动生成 Mock、页面和测试代码，如何设计一种智能组件提高这种自动化生成代码的适用范围后面希望写一篇专门文章集中介绍。
