大型工厂前端项目的研发过程。也就是说，一线互联网公司，项目开发或产品迭代，从一开始就在线，要经历哪些关键阶段，要经历哪些角色人力。而且，我们的前端程序员是如何参与的。(约翰肯尼迪，程序员，程序员，程序员，程序员)

这个主题是我一年多前想做的，但只是最近才生产了这个共享。我多年前见过创业公司的技术负责人，一直联系不上。有一次和他约好了，他说：“现在公司越来越大，成了几十个人。想知道大工厂的开发规范。否则，越大越难管理。”

当时我也没有做任何准备，所以边吃边聊，把我想的都告诉了他，但是比较乱。从那时起，很多人都认为会遇到这样的困惑。尤其是中小企业的管理者和程序员。所以过了这么长时间，我最后还是整理了这篇共享稿。

但是这次分享不是一般的故事。我不仅会说明每个过程、阶段和角色人员，还会说明我们常用的工具、技术要点。(David Assell，Northern Exposure，MART)我也认为我有能力告诉大家，因为我是大厂的首席前端工程师、开发经验、PMP和项目负责人、项目管理知识积累和实践。

整个过程概述

闲话不言而喻，画了一个流程图，显示了整个过程、作用和交付件的概要。

继之后，我将介绍每个角色。

项目委员会：这个角色是一个虚幻的角色，可以决定项目是否应该做，有时是高级管理者，也可以做出决定。与我们的实际开发毫无关系，所以不必在乎他。PM:既是产品经理，又是项目的推动者和兼职项目经理的角色。UE:负责页面布局、交互设计、视图细节等的交互设计师。UI:视觉设计师，互动决定后设计页面样式。很多时候，UE和UI是一个人。RD:后端开发人员。CRD:客户端开发者、Android、IOs都是如此。FE:前端开发人员。QA:我是测试人员。OP:负责服务器运维人员，一般负责在线发票审批。20:0:40我说几点考虑。

这个过程是从前端开发的角度分析的，所以很多阶段的发起人是FE。PS:我也希望大家在工作中积极热情地承担工作。希望你能得到收获。这个过程看起来很复杂，你可能会担心执行的效率。事实上，我只是画完了所有的细节，实际上不会太麻烦。有些工作很快就能完成。例如，联合组之类的。图右侧列出了每个阶段的交付件，即需要输出的文档或其他内容。交付物是项目管理中非常重要的概念，需要交付物才能证明你实际执行并完成了这一阶段，如果后面出现问题，可以回溯(平底锅)。例如，审查会结束后，必须通过邮件发送会议结论和审查委员会。其中一些过程可能会被忽略，或者会感到不必要的时间浪费，例如设计和审查技术方案、自我测试。事实上，如果你有开发经验或项目管理经验，就应该知道这不是浪费时间。就技术方案设计而言，如果你下一步开发程序顺利，写技术方案不会很难，也不会因此推迟。但是，如果技术方案两天没有写出来，预计在开发的时候也会成为障碍，烟雾风险会很大。详细的过程。

接下来，实际案例(因为这里不展示如何开发)——将在页面上添加评论(发表评论、评论列表、称赞、回复)——功能，详细分析其中的每个步骤。第一个是更详细地查看细节，第二个是整个R & amp就是加深对d过程的理解和印象。

建立项目

这个过程很可能我们作为FE无法参与，或者干脆不知道。因为在需求审查之前，一切都是由PM主导的，只有在项目成立后，PM才能制定需求，才能流向FE。总之，这个过程不需要费心。您只需知道，有了这个过程，PM才能制定需求并开始复查需求。

编写需求和要求审查。

写要求是PM的工作，所以我们不需要费心。接着，PM将召开“各角色”(UE UI RD CRD FE QA)会议进行需求审查。会议的主要阶段：第一，PM根据要求文件说明所有功能，包括C端的功能(例如发表评论、评论列表、称赞、回复)、后台的一些策略(黄斑、敏感词屏蔽)和统计数据。第二，每个角色的参与者提出自己的问题，PM进行解答。第三，问题都解决了，审查就会通过，否则审查就不会通过。

FE参考要求审查与其他RD CRD类似，最重要的是对这些功能的技术实施(是否可行或实现成本不高)感兴趣。例如，PM需要在用户按下赞美按钮时显示华丽的动画，如果使用H5成本太高，可以建议PM从H5侧改为简单的动画。另外，开发人员不一定是技术问题，也可以质疑PM的功能逻辑。

审阅结束后，PM通常会告诉每个开发人员：

员要排期。注意，这时候不能立刻答应，最好的回复方式是：我们回去讨论一下，明天下班之前（或者某个未来不太久的时间点，都行）给你答复。这样，你可以和其他 FE 或者架构师来讨论技术方案，一起评估一个比较靠谱的排期。PS：如果你的项目有拍死的 deadline ，那没招了，你就安排加班吧。

编写技术方案

这一步容易被大家忽略，人类好像是本能的眼高手低，感觉看似比较简单的事情就很乐观。越是这种心态，越要谨慎行事，在这里我建议所有的公司或者团队，都把编写技术方案作为一个必要的步骤，即打开开发前必须编写技术方案，并完成评审。

技术方案到底写什么——技术方案就是写你计划如何实现需求中的功能。拿这个评论项目来说，发布功能如何实现？要调用什么接口，输入输出时什么？要不要考虑 xss 攻击？再如点赞，是先执行动画再调用接口，还是先调用接口再执行动画？还有，你的代码如何拆解，分几个模块，有哪些核心的方法。这些都要写。技术方案没有一个固定的格式可供参考，因此是否能把技术方案写的清晰且使用，是判断一个人技术能力的标准之一。

技术方案评审

技术方案编写完成之后，需要拉内部的经理、架构师（或者技术负责人）、其他对接的角色（RD CRD）来评审技术方案。内部人员注意评审这个方案是不是符合设计原则，有扩展性，以及是否有其他坑（如性能问题，安全漏洞等）。外部对接的角色主要评审接口是否全面，输入输出设计是否合理。

技术方案评审通过之后，就得给 PM 反馈排期了。注意，估算工期一定要留有 buffer ，给自己留好余地。有工作经验的人都知道，一个人在一个公司里，一般会同时担任很多的工作，你不能保证接下来不会有其他功能耽误你的时间。例如，这个项目你本来预估是 10 人/天工作量，那你最好反馈 12-13 人/天。PS：评审之前反馈排期也可以，只是评审之后反馈，更加靠谱一些。

补充一句。这里我们仅仅提到了 FE 的技术方案评审，其实 CRD 和 RD 也会有他们的技术方案评审，评审时也需要拉着 FE 。其实大家的关系都是相互的，彼此相互把关，出来的设计方案就不会有太大问题。

交互视觉设计和评审

交互和视觉的设计，是 UE 和 UI 要做的事情，我们不管他们怎么做。他们做完之后会拉着 PM FE CRD QA 进行设计稿的评审，即看看这个页面最终是什么样子。FE 去参加主要看看视觉的实现是否有难度，特别是对一些透明、渐变、毛玻璃、阴影等特效，要慎重对待，还有比较常见的例如 1px 边框的问题。这些如果你遇到了，但是不确定是否可以实现，那最好回去查查再回复他们。

评审通过之后，UI 将产出设计稿给 FE 。按照惯例，UI 应该给 750 像素的图，即以 iphone 6 两倍屏为标准的图，并且设计稿中标出所有的颜色色值和间距、字体的大小。他们有专门的工具来导出这些，例如用 sketch 就可以轻松导出。注意，此时如果你已经给了排期，但是设计稿比较复杂的话，必须及时和 PM 沟通修改排期，有问题早发现早处理。

开发

有了前端的技术方案，有了客户端、后端的接口，有了视觉设计稿，这时候就可以进行开发了。一般需要从 git 里新拉一个分支，使用 mock 数据（此时后端还没有接口）。如有客户端的对接，还需要用到一些模拟 native 能力的插件，如果你们没有那就只能等到和客户端联调时再看了。开发产出的不仅仅是代码，还应该有开发文档（也可以是比较丰富的注释）和测试用例。

我们作为技术人员，往往以为一个软件项目最关键的就是代码开发，而传统的项目管理流程说，代码开发只占软件生命周期的 1/6 。根据本文相信你能体会到，代码开发真的只占软件项目的很少一部分。所以，作为程序员你要想自己值钱、有不可替代性，就要从整个软件项目的阶段入手，而不仅仅是提高开发能力。

视觉联调

代码开发完成之后，所有界面都做完了，你要告诉 UI 进行视觉联调。虽然你自己是按照 UI 给的设计稿做的，但是你不一定每一个细节都做的正确，需要 UI 确认。另外，各个手机屏幕的响应式做的怎样，也需要 UI 拿不同手机测试。他如何测试你不用管，只需要配合他就行了，遇到问题你就改。

这一步的产出是“联调报告”，不要被这个词给吓着，以为要写一个正规的文档。现实不是这样的，待 UI 联调完了之后，让他在项目群里 @ PM 回复一下说“视觉联调通过”，这样就行了，这就是联调报告，有这个记录即可。包括图中所有的“报告”，最常见的形式就是邮件和群信息。但是，哪怕就是一封邮件或者群信息，短短的一句话，这个步骤也不能省略。否则谁知道视觉联调已经成功了？

程序联调

FE 开发 h5 页，CRD 开发客户端，RD 开发后端接口，待大家都开发完成之后，也需要把代码放在一起联调一下。将 h5 和后端代码打包到同一个测试机上，既可以联调 h5 和后端接口。将客户端的访问地址指向这个测试机，就可以联调客户端和后端接口，也可以联调客户端和 h5 。联调成功之后，最好再给 PM 看一眼，让他确定这就是做出来的效果。

自测

这一步我是自己加的，也是我自己的做事风格。但这一步不是我自创的，在传统软件项目管流程里，就有“冒烟测试”这一步骤，也就是自测。但是，我在所有带过的团队中，都没有发现规定必须自测且产出自测记录。但是，我还是坚持自己的观点，我负责的项目必须要有自测步骤，而且我呼吁大家也要坚持自测。

自测并不是把所有功能全部详细测试，而是把核心功能都测试一遍，并记录测试结果，保证主流程是能跑通的。我相信每个有工作经验的同学都遇到过这种情况，程序员代码写完就提测给 QA 了，QA 一运行立马报错，无法继续测试，打回来找程序员重新修改。这种事情极大影响效率，谁都不乐意看到。如何避免呢？答案就是提测前，先自测。

自测依据需求的核心功能，可以是人肉手动测试，有可以是自动化单元测试，这个不要求。但是最后要产出一个自测记录，即用一个表格，列出所有核心功能，并记录每个功能你的测试结果。为何要有这个产出，就是为了证明你真的测试过每个功能了，而不是眼高手低看两眼就通过了。一般需要产出交付物时，大家都会认真对待，没有交付物大家就可能敷衍了事。

提测

自测完成，并产出自测记录，即可以提测了。提测需要 FE CRD RD 和 PM 一起，将需求文档、代码、自测记录提交给 QA ，并发正式的提测邮件，告知所有项目角色该项目提测了。QA 收到之后，确认分析完成，需要回复计划的测试完成时间。然后 QA 开始测试。

测试

QA 测试过程中肯定会不断的产出 bug 列表，此时 FE 应该要求 QA 把所有 bug 的描述都写清楚，即能让个自己傻瓜式的复现这个 bug ，以便快速修改。遇到复现不了的问题，一定要第一时间找 QA 来复现，有些问题复现了一次再也复现不了，那你就先别管它，先去改别的问题。QA 测试完成之后，要发准出邮件，告诉所有项目角色该项目测试通过，可以准备上线了。

上线 & 回归测试

QA 测试完之后不一定能立马上线，因为一般产品的上线都是例行的。频率比较快的产品，可能规定每周一到周四下午的某个时间点可以上线，晚上一般不上线，周五一般不上线，除非紧急修复 bug 。因为，上线之后就有可能带来一些 bug ，可能晚些才能发现，如果晚上或者周五上线，一旦发现 bug 大家已经回家睡觉或者过周末了，不容易集中人力修改。

上线的步骤一般是先合并代码到 dev 或者 master 分支，每次上线可能是多个功能一起上线，因此合并代码时还可能会出现冲突，得先解决冲突。然后开始发起上线审批，生成上线单，需要 PM QA 和各个技术经理审批确认，OP 才能将这个上线单解锁，这样就可以发起上线。

上线的机器一般也分好几步，每一步都需要 QA 参与回归测试。第一步是预览机，预览机只对内有效，外网看不到，但是加载线上的真实数据。第二步是单台机器，即线上机的一台机器。第三步是单机房，即线上机的一个机房。第四部是全量，即线上机的所有机房。这些步骤全部操作完成，并且 QA 全部回归测试完成，才算真正的结束。

如果其中一个步骤遇到问题，就需要启动快速回滚。回滚就是用 git 的上一条记录重新上线，覆盖目前的代码，步骤也是先预览机、单机器、单机房、全量，每一步也需要 QA 回归测试。如果 bug 影响严重，还需要项目的主要角色写检讨，做复盘汇报，总结教训。

项目总结（可选）

项目总结是可选的，而且我发现大部分的团队都不会去做总结，觉得上线完了就大功告成，该启动下一个项目了。但我觉得，无论是不是做项目，做完一件事（如看完一本书）就应该自己总结一下。回顾一下经过，总结一下得失，积累一点经验，这样才能慢慢成长。

有想要学习前端或者转行前端的朋友可以私信小编“学习”，前端开发全套教学资料，大神带你学前端