这本书的最后一节，将和大家分享多年来经过实践检验，有助于提高工作效率、优化开发体验的3项制度和流程，通过长效化机制保障我们的前端工程长期保持优异的用户体验和开发体验。
1. RFC征求意见稿制度#
在工作中进行技术优化时，时常会遇到以下痛点：
- 优化方案没有形成共识，技术方案不完善，做完了才被同事指出设计有缺陷；
- 优化过程中缺乏同事领导的参与和支持，无人问津，独木难支，推进乏力，完成后也没能扩大自己的影响力；
- 优化完成后，没有存档记录可查，过一段时间就被遗忘了，无法促进知识共享和技术积淀，无助于团队内形成崇尚技术优化，追求极致的文化氛围；
- 团队成员讨论技术问题，大多停留在随意的口头交流，缺乏正式地深入探讨和实际行动；
总之，技术优化在实际工作中会遇到许多困难和挑战，但通过在团队内推行征求意见稿制度（Request for comments, RFC） ，上述问题都能迎刃而解，开发体验也会有显著改善，最终引领团队形成追求极致的技术优化文化。
RFC 制度是指在开展技术优化改进时，统一通过RFC文档来确定方案，记录进度，开会探讨，达成共识，辅助执行，总结成果的工作制度。
这项制度主要由以下步骤构成：
1. 起草RFC文档#
RFC 文档是 RFC 制度的核心，RFC文档需要简明扼要地涵盖实施技术优化的方方面面。
笔者在多年实践中总结了一套 RFC 文档模板，各位可以按需求复用：2023-01-01 RFC: 征求意见稿（Request for comments, RFC）模板
提前确认优化可行性也是RFC制度的目的之一。所以建议在起草文档阶段，同步编写部分核心代码，验证功能逻辑，作为后续演示的DEMO示例。
在这一阶段，也应该初步确定优化目标，并考虑量化优化效果的手段。
2. 小范围讨论RFC#
RFC制度的灵魂其实并不是公开评审，而是公开评审之前的小范围讨论。
因为任何事情仓促地抛诸公开评审，都难免因为众口难调，导致各方提出大量问题，甚至是责难，最终阻碍优化推进。
尤其是通过会议形式公开评审RFC时，参会的许多人，你一言我一语地提出的大量问题，会导致RFC难以达成共识，甚至进一步加大分歧。
所以我们在实际执行RFC制度时，应该优先进行小范围讨论，通过一对一、当面交流的形式，和2到3位与RFC主题相关的同事进行交流，提前介绍RFC内容，讨论技术优化方案的可行性，请教自己不熟悉的技术细节，倾听他们的疑惑问题，记录并解答，这将会有助于RFC最终达成共识，顺利执行。
小范围讨论的主要目的和工作内容是：
- 提前收集反馈，对技术方案和文档做出相应调整，避免在公开评审时才发现技术方案有重大缺陷。
- 针对同事的问题，准备专门的视频，截图，DEMO演示，答疑解惑，减少技术优化的阻力，寻找同事领导的支持。
3. 公开评审RFC#
文档经历小范围讨论，验证可行性后，就可以面向所有受影响的同事进行公开评审了。
这一步是RFC制度的关键步骤，决定了技术优化的完善程度和影响力，是让技术方案在团队内达成共识的重要方式。
在公开评审时，建议：
- 发布RFC文档链接到相关小组，部门消息群内，周知各位同事上下文信息。
- 呼吁阅读文档的同事，积极评论、点赞支持或当面提出疑问。
- 提前预约评审会议，邀请与优化内容有关的各方同事专门探讨评审，完善改进方案。
- 会议过程中请专人做会议纪要，记录关键信息，重要结论和待确定的问题。并会议结束后，向各方同步会议纪要，并着手逐个解决待定的问题。
4. 实施技术优化#
经过小范围讨论和公开评审，完善技术方案，确定目标收益后，即可正式开始编写代码，具体实施技术优化了。
在具体实施优化前，务必提前部署量化优化效果的指标、Log和埋点代码，充分记录优化前的数据，以便优化完成后能拿出量化数据，证明优化效果。
5. 总结RFC成果#
技术优化开发完成后，应该及时统计改进的收益，对比改进优化前后的区别。
总结成果最好观察7至15天，确保优化效果稳定，避免受到节假日等特殊情况的影响。
确认成果后，可以及时同步给同事领导，公布到工作群里，增强自己的影响力，促进团队形成技术优化文化。
此外，所有的RFC文档应该放在同一目录空间中，最好按时间排序，便于归档查询。
2. 建立技术优化任务池和任命技术产品经理制度#
要想不断打磨产品，追求极致体验、让崇尚技术成为团队内的文化，就不能只靠个别成员，偶尔地进行优化。
推荐建立技术优化任务池和任命技术产品经理，用长效化机制，帮助团队形成技术文化。
1. 简介#
技术优化任务池是指建立包含各类优化任务的汇总任务池，所有同事都可以向这个任务池中添加技术优化相关的任务，并从中选择自己感兴趣的任务接手开发的制度。
技术产品经理是指由团队内有志于技术优化的同事兼职担任技术产品经理的角色，记录团队内的技术痛点、优化机会，帮助团队和其他同事开展技术优化的制度。
2. 实施细节#
在具体实施技术优化任务池和任命技术产品经理制度时，笔者总结了一些有助于制度建立的实践经验，供大家参考。
1. 明确技术优化任务是绩效产出#
技术优化是日常工作的额外任务，是加分项，而非必选项，不是每位同事都有充分的积极性参与技术优化。
所以为了充分调动同事们参与的积极性，应该提前通过会议当面同步或书面记录的形式，告知同事们：技术优化是工作中的绩效产出和加分项，完成技术优化的同事会优先获得升职加薪，评优评奖的机会。
同时也要尽量避免强制摊派任务，避免让技术优化成为同事工作中的负担，甚至痛苦。充分尊重个人意愿，通过升职加薪的形式激励技术优化，避免使用打压加班强制推进。
2. 创建技术优化任务#
为了方便创建、统一管理技术优化任务，推荐使用专用的技术优化任务模板文档，帮助同事们快速创建任务，并记录必要的细节，例如：
- 任务的背景：遇到的问题、痛点；
- 可行的解决方案；
- 相关上下文信息，例如产品文档链接、设计稿链接、参考资料等；
笔者基于实践经验，总结了技术优化任务模板示例：2023-01-01 技术改进任务模板，各位可以参考复用，内容截图如下：
3. 建立任务管理看板#
在具体执行时，推荐基于Jira、看板等任务管理工具，创建专用的技术优化任务管理看板，来统一存放技术优化任务的文档或记录。
此外，技术产品经理也要负责维护看板的任务内容，把控任务进度，积极参与任务的小范围讨论、答疑解惑。
4. 任务内容及优先级#
任务主要来自于同一项目组的各位同事，记录在工作中遇到的：
开发体验痛点，例如：
- 重复繁琐的开发环境配置；
- 效率低下，甚至令人痛苦的工作流程；
用户体验痛点，例如：
- 让开发者都感觉复杂繁琐的产品交互流程；
- 页面加载较慢，内存泄露，网络流量开销较大等与用户息息相关的问题；
技术债务：
- 经过长期迭代后项目架构模块化混乱，模块冗长，代码重复等需要重构的任务；
- 项目依赖版本陈旧，需要更新新版本的任务，尤其是有重大变化（Breaking Changes）的更新；
此外，建议鼓励同事们通过点赞，评论等交互附议任务，基于同事们点赞附议的数量排序，为各任务标记优先级。
5. 任务分配及进度把控#
确定优先级后，建议按自愿原则分配，让对任务感兴趣的同事主动请缨，接手任务，从而获得更好的完成质量。
如果确实没有感兴趣的同事接手，也可以指定有空闲排期的同事跟进完成，不过俗话说强扭的瓜不甜，还是建议充分考虑个人意愿。
在进度把控上，建议承接任务的同事按RFC征求意见稿制度的流程，在起草RFC文档时确定估时，明确开发所需天数。
在具体开发时，允许接手的同事在日常工作中，抽出20%左右的时间（每周5天中的1天）投入到技术优化任务中，逐步推进任务。并由技术产品经理跟进任务的各阶段，确保按时完成。
通过技术优化任务池制度，持之以恒地进行技术优化，既能促进项目的不断优化，为个人带来更好的绩效产出，又能成为项目组甚至整个部门的整体产出，帮助团队形成技术文化。
此外，这些任务作为评估考核工程师绩效的一项指标，也可以显著提高团队内部的量化管理水平，更精准地衡量每个人的产出和贡献。
3. 需求开发流程最佳实践#
笔者工作这些年，陆续在宇宙级大厂、成立了12年的老牌互联网公司和知名外企摸爬滚打过，经历过、听说过许多工作流程上的乱象、奇谈，比如：
- 项目一上线就白屏，后端响应500、前端页面Syntax Error，各种异常层出不穷。
- 项目发版上线，本该相互依赖、同步上线的前后端，最终却只有前端上了线、后端竟然忘了上线部署。
- 上线后发现BUG，研发同事着急忙慌地就要修复，结果越改越错，反复上线了几次才彻底修好。
- 代码部署到了生产环境，产品经理才发现部署的新版本遗漏了功能逻辑。
- 满怀信心约定16点完成上线，可上线期间各种意外频发，上线一再推迟，最终直到凌晨2点才完成部署上线。
- 研发开始开发几天后，才发现想要的功能，技术上无法实现，最后导致项目延期，产品设计甚至也要推倒重做。
- 项目完成时间一再延期，说好的3天完成，但是3天又3天，最后10天也没能完成。
- 产品、设计不满意开发成果，反馈大量问题，反复调整，导致各方都身心俱疲。
- 项目的测试依赖人工手动测试，多年测试积累了1500多个文字截图描述的测试用例，每次上线都需要整个团队腾出一个月时间自测。
- 多个人力辛苦开发了1个月的需求，上线后半年，才发现竟然一直没有用户使用，白白浪费了资源。
1. 工作流程问题的本质#
以上描述的各种问题，相信在职场打拼多年的各位读者也有所见闻，但是这些问题其实只是表象，它们代表的本质是：工作流程不合理，具体表现在：
- 参与各方对产品功能、样式设计缺乏共识，没有解决关于需求的各种疑问。
- 工作时缺乏合作交流，参与者各自为政。
- 技术方案设计粗糙，缺乏有效的审核把关。
- 上线部署流程混乱，要么太过随意，要么太过繁琐。
- 工作没有数据总结、成果反馈。
要解决这些本质上的问题，一套合理、高效的工作流程必不可少。
接下来，笔者以互联网公司中最常见的需求开发工作为例，向各位推荐一套经过多年实践检验的需求开发流程最佳实践。
2. 流程图及简介#
首先，我们通过一张流程图来看一下这一流程的全貌：
具体来说，《需求评审开发流程最佳实践》包括以下3个阶段：
1. 需求评审阶段#
这一阶段的目标是评审需求文档、设计稿，让参与需求的各方互相解答疑问，最终对需求达成共识。
为了实现这一目标，就需要依次完成：
1. 产品经理起草《产品需求文档》#
优秀的产品经理团队会基于统一的文档模板，编写文档来介绍产品需求背景、目标、文案和详细交互逻辑。这份产品文档是一次业务需求的核心，是这一阶段评审的主要目标内容。
2. 设计师制作《设计稿》#
如果产品需求涉及UI样式，应该由产品经理联系设计师同事，基于产品想要的交互逻辑，设计出用户体验优异的UI样式，并制作出有统一配色方案、组件库、字体等统一标准的设计稿，交付给研发来开发实现。
在实际工作中，建议设计师使用Figma、蓝湖等设计平台，保存、分享设计稿文件。
3. 需求启动会议#
这是这一阶段的关键节点，准备好了产品文档及设计稿后，应该安排一场专门的会议，让参与的各方基于文档，评审产品设计、UI样式。
如果关于需求，有重大缺陷或难以解决的分歧，应该判定为需求评审未通过，让参与各方对缺陷和问题进行修复后，再次进行需求启动会议。
直到各方充分交流疑问，解决所有分歧，最终对产品需求达成共识，能做出符合各方预期的需求和产品。
4. 确定需求负责人#
需求启动会议上，还有一件重要的事情就是要确定这次需求的总负责人。这个人最好在团队内有足够的能力和权威，能够承担以下职责：
- 监督各方进度，解决阻塞问题，避免延期。
- 牵头组织各方合作交流。
- 拍板决定争议事项，推动团队达成共识。
- 总结上线后数据。
确定了需求负责人，有助于需求的顺利推进。
2. 调研开发阶段#
第二阶段的目标是评审研发人员调研后编写的《技术方案》文档，确定产品需求的技术实现。
为了实现这一目标，研发人员首先要在上一阶段全面评审、充分理解产品需求文档和设计稿，并编写文档，讲解代码实现的技术方案。
作为前端研发，我个人有一个珍藏多年的设计技术方案秘籍：编写代码实现一遍产品需求的核心逻辑，也就是做一个DEMO。
通过写DEMO，实现一遍核心的产品需求逻辑，能有效地帮助我们研发评估需求的难点和整体所需工时。避免出现：
- 眼高手低，开始写代码了，才发现无法实现的产品需求。
- 估时不合理，导致需求开发延期。
这一阶段的关键节点也是一次会议，主题是《技术方案评审》。
在这次会议上，应该有产品经理、设计师、QA测试等同事参与，主要的议题是评审研发设计的技术方案，是否符合产品需求和设计稿。另外，研发同事也要基于设计的方案，给出开发估时，确保需求顺利如期完成。
如果技术方案不符合需求，或有重大缺陷，也要判定为技术评审未通过，让研发对提出的问题进行调整后，再次进行技术方案评审会议。
3. 测试验收阶段#
第三阶段的目标是在开发完成后，由QA测试、设计师和产品经理对开发结果进行充分的测试验收，确保要上线部署的功能逻辑、UI样式和各方预期一致。
为了实现这一目标，需要依次进行：
1. 设计测试用例#
由QA测试同事，按照产品需求中的功能逻辑，设计需求测试用例，尽可能覆盖到需求的方方面面，并以文档或思维导图的形式记录。
如果测试同事有代码开发能力，强烈建议使用前文介绍的Playwright、Jest等自动化测试工具辅助测试，提高效率。
2. 测试用例评审会议#
QA测试同事设计的测试用例，也应该由产品、研发等相关各方进行评审，查缺补漏，确保测试覆盖率足够。所以就需要组织一场专门的 《测试用例评审会议》 ，让相关各方专门投入时间精力来评审QA同事设计的测试用例。
另外，测试同事也要在这场会议上，明确测试完成所需的时间，给出测试工作估时，确保测试工作如期完成，不耽误后续上线流程。
测试用例如果有遗漏、缺陷，就可以由各方在这场会议上提出，让QA测试再次修改完善。
3. QA功能测试#
测试用例评审通过后，QA测试同事就可以正式开始对开发成果进行功能测试了。
测试如果遇到问题应该即时和产品、研发沟通同步，确定是BUG的问题，也应该有专门的文档或任务看板统一记录。
4. 产品经理、设计师验收#
这一步骤是确保开发成果符合产品需求、和设计稿对齐的必需环节。细致的验收，能帮助研发规避上线后才发现功能逻辑缺陷等低级错误。
这一阶段的测试验收如果不通过，应该联系研发同事确认状况，等待修复问题、完善代码逻辑后，再次进行测试验收，直到开发成果符合各方预期。
4. 上线总结阶段#
最后的第四阶段的目标是产品需求部署上线，并获得线上真实用户的使用数据。
为了顺利完成上线总结这一阶段，我们需要：
1. 上线前准备#
要想顺利完成上线部署，充分的准备必不可少。尤其是对于研发同事而言，以下环节是准备时必须要检查的事项：
- 代码能否通过CI构建测试
- 代码Review是否通过
- 多项目上线的先后顺序
- 用于收集数据的埋点、Log是否已添加
如果上线的需求比较复杂，牵扯多方配合，强烈建议组织专门的 《上线讨论会议》 ，由任务负责人牵头，拉上各方确定每一个上线步骤的准备情况、上线顺序、精确到分钟的预计上线时间，并为每个项目、每一步骤预留好充足的时间缓冲，记录成文档后，供各方周知，最终按顺序执行上线。
2. 金丝雀小流量验证#
上线部署阶段是项目运行的高危时期，极易因为上线部署引起项目异常。
所以，在上线前进行小流量验证非常必要，一般的做法是，由后端或运维同事配置实现，将生产环境5%左右的用户访问，导向即将部署的项目新实例，观察一段时间后，检查是否有后端5XX、前端白屏、功能逻辑异常、用户直接反馈等严重问题。
如果有严重问题，在这一阶段就回滚修复，能最大程度降低对用户体验和项目声誉造成的损失。
3. 部署到生产环境及验证#
小流量验证通过后，就可以正式上线部署到生产环境了。
在这一步骤中，并非上了线就万事大吉了，容易忽视的一环是生产环境验证，上线完成后，产品经理、研发和QA测试应该对需求功能再进行一次验证，至少覆盖核心流程，再次确认（Double Check）生产环境的需求和功能一切在正常、符合预期。
如果这一阶段验证发现异常，应该优先考虑回滚，回滚后再进行代码修复。避免立刻进行代码修复，因为在这一阶段中容易因为心态紧张、时间紧迫，导致各方忙中出错，越改越错。回滚后再进行修复，有助于提高修复质量。
4. 总结数据#
最后，上线顺利完成一段时间后，也要基于提前准备的埋点、日志Log等方式，统计总结产品需求在线上环境的数据表现，统计PV、UV、点击量、转换率等数据，并同步给各方。
如果数据符合预期，那就说明参与各方完成了一项成功的需求开发，这些数据，既可以说明开发的需求给公司带来了收益，也能作为我们个人作为争取升职加薪机会的依据。
最后，也许有些读者会认为上述需求评审开发的流程看起来很复杂，甚至有些多余，但事实上流程中的每一个环节，都经过了多年实践检验，运行效率很高，是基于大量的成功经验和失败教训形成的。
欲速则不达，这个道理同样适用于商业公司内的开发工作。越是急于求成，追求快速完成开发工作，越容易忙中出乱，导致出现低级错误。
反倒是按照上述流程，一步一个脚印，多一些评审、确认，最终才能保证产品需求按时高质量完成。
后记#
从2022年底，到2024年初，历时一年多，终于完成了这本《前端工程体验优化实战》的编写，感慨颇多，和各位读者分享分享。
最初写这本书的初衷是，我和朋友都觉得，一辈子打工上班，永无出头之日，永远身不由己、受制于人。但是个人想要摆脱这个困境，现阶段能做的似乎又不多，想来想去，多写技术文章，保持终身学习，似乎是当下可行性比较高的选项了。
再加上，笔者工作近7年，到了现在的第3家公司工作后，突然发现，自己又做了一些之前就重复做过的工作，并且这些重复的工作都有一个共同的主题：用户体验优化和开发体验优化。想到这里，我的脑海中很快就浮现出来这个主题的目录大纲。于是就萌生了把自己这6、7年的工作经验总结成前端优化系列文章发布的想法。
我个人平常也会在掘金发文章、学习，看过了一些前端优化相关的文章和小册之后，感觉也不过如此，很多讲的内容还是几十年前老掉牙的优化思路。
如果让我来写前端优化，一定比市面上的书更好！
于是就开始了漫长的征程，因为平常还有全职工作在干，所以只能用下班放假后的业余时间来写，平均每天只能写300字左右，进度比较慢。陆续用了几个月构思大纲，写草稿，半年后才开始正式写第一版。
期间也遇到过几次挫折。
先是时间紧迫，半年过去，第一版规划的主题，才写了三分之一，进度太慢，只好大刀阔斧地删去了一大半主题，集中注意力先写最有价值的一批主题。
期间把其中2节率先发布成了掘金文章，试了试市场的反响，可惜表现并不理想，只有寥寥二三十个点赞。
后来联系掘金申请发布小册时，又遇到一项重大挫折。提交的写小册申请竟然被拒绝了…顿时感到了绝望。
不过幸好我没有放弃，又咬着牙写出了第三节：https://juejin.cn/post/7274889579076108348 ，发布后，终于功夫不负有心人，登上了全站的热榜第二名，几天就收获了几百个点赞。凭着这篇文章，再次和掘金申请，才终于通过了审核，获得了写小册的资格。
真的是好事多磨。
后来发布前定价时，也犹豫了很久，一方面想定个高价、多挣些钱。另一方面又担心价格太高，把读者拒之门外。
最终还是决定不挣钱、交个朋友。选了较低的19.9元定价，希望能多一些读者、多交些朋友。截止目前的销量虽然不高，挣的钱还比不上全职工作几天的工资，但作为新人初出茅庐的第一本书，人活一生能实现写书这样的成就，已经让我很欣慰了。
最后，希望这本书能为各位读者带来收获，祝大家早日飞黄腾达。也希望能和大家成为朋友，欢迎大家通过评论、微信（xinghuamantou）等各种形式多多交流。