前面的上、下两篇用了较长时间整理，这里合并一下。
先强调一下：我只待过国内公司，这只是我的个人经历。
笔者在工作过程中，接触下来，每一个开发小伙伴都有各自的开发流程。
本文，希望能够成为“最佳实践”
一、常见的开发模式
在在整个软件开发生命周期中，“研发”只是其中一个阶段；而在“研发”阶段中，又包括了许多与研发相关的流程；在这些流程中，包含了前端开发的流程。
从项目管理的角度来看，前端开发只是一个很小的环节，甚至有些领导“不知道”有专门的前端岗位。然而，经过多年的前端开发工作经验，包括游戏开发、后台系统和H5项目，我发现，在业务开发中，前端的工作量非常大（其他岗位边界更加清晰一些，在整个研发流程中，看起来有很多事情做，实则不然）。
尽管如此，在展示研发成果时，前端开发显得很被动，展示内容也比较少，特别是面对不懂技术的人。外部人员通常更喜欢听到诸如“数据”“安全”“云计算”“分布式”等词汇，对于前端工作的认可较少。这也应验了一句话：“管理流程的人看起来更重要，事情更多；执行细节的人看起来微不足道，产出也少。”
本文中，我会讲在一个常见的团队中，包含产品经理，UI/UX，前端研发，后端研发，测试等岗位，前端开发流程的方法论。秉持着“在粪坑中搞科研”的精神，总结这些年的心得。
1. 瀑布/迭代模型
瀑布模型强调在所有准备工作完成后开始开发；迭代模型则强调“循序渐进”的开发模式。这两者都是线性的开发模型，笔者经常会听到“迭代”这个词。
2. 敏捷开发
敏捷开发是一种灵活的开发方法，强调迭代和持续反馈。它是一种方法论，可以应用到所有能够提升效率的开发模型中。通过短周期的迭代，团队可以不断调整和优化产品，快速响应需求变更。这种方法特别适用于需求动态变化的项目。笔者也接触到许多自称“敏捷开发”的团队。
3. 玄学/其他
有些项目的开发模式难以定义，通常是由老员工或老板制定的，后来者必须适应前者留下的方式。
笔者认为，线性的开发模式对“细节执行”的岗位是有利的，它会明确执行者的上下文和边界，给予执行者“保护”；而非线性的开发模式对执行者是不友好的，会将人性的丑陋暴露出来，体现出人性的“反复无常”。
综合来看，“迭代”开发对于研发同学比较有利。
二、前端开发流程
假设，团队里面只有老板与前端，我们可以“多快好省”的实现老板的目标：产品我们直接从老板（客户）口中获得，UI我们根据UI库提供的组件来实现，数据我们自己来管理。但是，当团队出现了其他岗位以后，所有的事情都变了。我们不能“最大化”的为老板做贡献了，他们成了“魏忠贤”。
1. 前端的视野
在常见的敏捷团队中，前端的视野是这样的：
很明显，前端在开发过程中，属于最下游。
2. 笔者的开发流程
基于最下游的地位，对于拿到一个功能后，笔者的开发流程是这样的。
- 第一步：实现前端骨架（如同”react编程哲学“那样），包含各种嵌套关系，各种静态展示；
- 第二步：mock后台数据，填充；
- 第三步：根据UI稿完成样式，如果有”基础组件“变动，比如 组件库里面的button（设B)与UI设计稿上的button不一致，可能会有两种处理方式，一种自己写一个简单的，丢失了很多交互以及样式，另一种是直接拿组件库里面的button来修改；
- 第四步：根据后台接口数据进行调整，有时候有些状态可能在接口里面不存在，需要各种状态拼接；
- 第五步：自测，完善UI，完善交互；
- 第六步：联调
- 第七步：产品、UI验收
- 第八步：修复问题
- 第九步：提交测试
这几步中，第三步、第四步非常不可控。他们来源于别的岗位，别的人，而他们在做的时候可能会很少考虑到前端实现组件所需要的物料。
在无法push别的岗位的情况下，我们只能调整自己的开发步骤，跟别的岗位battle来获得自己需要的物料。
因此，需要前端调整自己的开发路径，让编码过程可以被可控。
先跟UI同学沟通，是为了保证不需要重新开发组件，防止UI同学自由发挥；
然后与后端同学沟通，是需要让后端同学能够写出符合UI组件需求的数据结构，减少因为后端数据没有”适配UI“产生的不必要的心智负担；
当然，上面所有的只是一个”假设“，有很多情况需要根据具体情形进行调整。
3. 理想的模型
一个相对理想的模型是这样子的：前端可以关注最少得点，心智负担降到最低
这里的关键是：组件库。
UI/UE在设计的时候，就要考虑通用的UI组件，而不是自由设计；
后端在给前端提供数据的时候，也要考虑组件需要的数据结构，而不是直接简单数据库数据拼接；
虽然上面对比第一幅图貌似前端关注点只减少了一根，但是后端、UI/UE提供的物料，对前端友好。
这里，UI/UE与后端同学可能都“不愿意”被前端组件影响到，需要用些时间来对齐思想。
这个时候的开发步骤，就可以重新梳理：
红色背景的框里面的步骤基本上占用的开发时间相对可控，而且较短，前端可以不太”受制“外部的印象，关注点集中于prd功能的实现。
需要强调一下，前端组件库对于后台管理系统来说，至关重要！或者说，是第一位的重要！
三、“敏捷开发”下前端做的事情与他人的事情
看到的大多数技术博客都是前端技能点相关，很少有看到系统的关于前端开发流程的分析与研究。
1. 业务的开发流程
首先明确一点，我这里描述的是一个敏捷小组，包含人员有限，可以独立完成一个项目。这里之所以从业务的开发流程说起，是因为对于整个项目的流程属于更大的范畴，需要更多的人，甚至包含老板，因此，只能将范围约定到业务范围里面。对于整个项目，
当然，有人说，“前端没有业务”。
业务的特征：
- 可以被交付给客户的；
- 满足客户单个需求的；
- 可以在一个短期时间内完成的；
- 明确边界与范围；
- 可以被量化的；
对于单个业务，从项目的视角来看，开发流程如下图所示：
从前端的角度来看，如下图：
2. 前端需要做的事情
从上图中，我们发现，前端处于产品、UI人员的下游，后端人员的中下游，处于测试人员的上游；在提测阶段与测试人员互为上下游。
前端需要根据别的岗位的要求，完成：
- 需要根据产品文档，产出符合功能要求的软件产品；
- 需要根据UI人员的设计稿，产出样式合格的软件产品；
- 需要根据后端人员的接口返回数据，来填充软件的展示数据；
- 为测试人员提供可测试的版本，根据测试人员反馈的问题，来修改或者修复软件。
3. 前端难么
在许多人看来，前端开发并不难。这种误解源于大家在思考业务时，通常采用“流程控制”的思维方式来表达复杂性。以制作香烟为例，可能会被描述为：
- 制作过滤嘴；
- 制作烟草部分；
- 拼合在一起。
这种思维方式适用于状态流转非常确切的场景，如后端开发。然而，前端开发的过程更加复杂。通常，上面的3步只是前端开发需要首先实现基础结构。
在此基础上，还需要对美观性、舒适性等方面进行大量完善。而这些方面，客户和其他角色往往忽视，或者认为是理所当然的。对于客户能直观看到的事物，一般人会认为“不难”。
需求方通常认为，美观、舒适等细节简单且易于实现，因此这些内容常被忽略。人们有“抓大放小”的本能，但正是这些细枝末节需要前端开发投入大量时间来完善。
总结以下几点：
- 前端开发的基础结构部分确实不难，因此其重要性常被低估。
- 然而，在美观性和易用性方面，前端开发需要投入大量时间和精力，这些地方会产生许多细节和不可预知的情况。
此外，前端开发者在处理大量细节时，通过脑力难以全面感知和衡量。经验表明，在业务需求开发上，前端代码复用性较低。例如，第一次开发登录功能可能需要3个工作点，第二次开发即使流程一致，也仍需3个工作点。
综上所述，尽管前端开发在基础结构部分并不复杂，但在细节完善上需要大量时间和精力，这一点常被忽视和低估。
4. 前端,请提出你的要求
很少看到前端开发人员对“上下游“提出过要求，明确界限。
首先，我们看一下前端在一个迭代计划里面的完整生命周期
可以看到，真实的开发周期需要很多节点。每个节点，我们都要对合作岗位提出自己的 合理要求。这里，我罗列一下每个阶段，前端对于合作岗位的要求，以及前端在当前阶段需要做的事情。
由于流程太长，我这里用一张Excel生成的图片来说明（点击放大）。
表格链接：【腾讯文档】前端开发流程的哲学 docs.qq.com/sheet/DWnR1…
总结
作为开发人员，要明白自己的定位，要明白开发的流程；
作为前端开发，一定要有自己的原则，明确自己的边界，明确他人的定位；
作为“底层”，一定要讲规则，有效利用规则，可以“保护”自己；
对于其他岗位，一定要“严格要求，宽于落地”；按照上面各个阶段对其他岗位的的要求，去要求其他岗位；提前把规则确立好，弹性的去验证“对于他人的要求”，“严于立法，选择执法”，这样才能让自己的工作更有效，才能做的更长久。
最终，前端开发在敏捷开发中的作用将更加突出，工作流程也会更加顺畅，有助于提升整个团队的开发效率和产品质量。
