Web 前端项目开发过程导论

你们好，我是tfan，在开发过若干个不一样类型和规模的 Web 前端项目以后，我发现即便在 2019 年前端开发仍是有不少痛点的。正是由于这些痛点的存在，前端领域才不断涌现一些新的框架和工具、观念和方法来解决这些痛点，也就是不断造轮子。

这篇文章不讨论重复造轮子的问题，我以为持续的改进和不断的完善比创新更重要，我但愿的是从前端项目的开发过程入手，理清一个典型 Web 前端项目开发过程当中都有哪些参与者、各个参与者在开发过程不一样阶段的关键任务是什么、这些任务之间的上下游依赖和流转是怎样的，以及它们是在何时、以何种方式对前端开发产生影响的，从而探索一种标准化的 Web 前端项目开发流程。

一种典型的 Web 前端项目开发过程

下图是我根据本身的项目开发经验绘制的一副典型的 Web 前端项目开发过程，

关注开发过程是由于过程相对稳定，稳定决定了咱们有机会发现一些广泛问题，而解决这些问题则是改进流程的关键。

分析影响是但愿找到前端开发过程当中的关键任务，并思考采起什么措施来应对影响和完善这些任务。

这种典型的 Web 前端项目的开发流程包括了产品经理、设计师、前端、后端、QA 这几种角色，也列出了在项目不一样阶段这些角色的主要任务以及和其余任务的上下文关系。

从这张图里能够看到项目开发过程大体分红了立项启动、准备、需求、计划、设计、开发、测试/发布几个阶段。下面咱们分别分析一下前端开发在这几个阶段的关键任务。

立项启动

首先要找到合适的人

项目启动的时候通常会组织一个项目启动会，一般是召集各个小组的 leader或者没有 title 的 leader 参加，内容一般是产品部门作下项目背景的简单介绍，给参与项目的各方同步一下关于客户、项目目标、大体时间的一些基本信息，让你们对项目自己有一些共同的认识。

这个阶段首要考虑的是人手安排，即须要哪些人、什么时间来参与到这个项目中来。虽然需求还没有细化，可是根据已有的信息咱们也大体也能够估计一下项目的规模，究竟是一个小型、中型仍是大型项目，还须要考虑一下项目的交付时间要求，是宽松、紧张、仍是很是紧张。

若是是一个小型项目的话，咱们可能只投 0.5 我的进去，一般会选派手头现有项目已经进入维护阶段或者二期开发的同窗，能够把主要时间、精力放在新项目上了。

也就是说一个前端开发可能同时参与多个项目，他可能须要一天以内在几个项目之间进行切换，典型的一种工做状态是在新项目需求讨论、开发联调的间歇须要快速地处理另外一个项目的一些 issue。

另外一种状况是项目规模比较大、优先级比较高、时间又很紧张的状况，这个时候咱们能够采起 all in突击的方式，即首先指定一个项目的前端负责人，前期的需求分析、评审、计划、排期阶段只须要他一我的参加，进入设计、开发阶段之后再拉更多的前端同窗加入项目，每人分一些已经安排排期的功能点，并行向前推动进度，这种临时的集中突击一般不会超过两周的时间，不会对其余项目形成什么大的影响。突击完成以后，又能够把项目单独交给最初的项目前端负责人主要负责跟进，好比跟进需求的变动、接口的更新等，其余人力就能够暂时释放出来了。在 QA 测试阶段，若是 issue 比较多的话，还能够再来一次全军突击，集中处理 bug 和 issue。

可以搞得起全军突击的一个前提是前端是一个大的资源池能够统一调度，另外一个要求就是统一技术栈，也便是成员之间的能力是能够互换的，这就要求咱们在一个组内不要搞多个技术栈，框架、预处理工具、构建工具、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、接口要统1、前端技术栈要稳定，不能前一个项目是 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、页面和测试代码，如何设计一种智能组件提升这种自动化生成代码的适用范围后面但愿写一篇专门文章集中介绍。

有问题欢迎跟我联系 tom@tfan.org。