先强调一下：我只待过国内公司，这只是我的个人经历。
笔者在工作过程中，接触下来，每一个开发小伙伴都有各自的开发流程。
本文，希望能够成为“最佳实践”
一、常见的开发模式
在在整个软件开发生命周期中，“研发”只是其中一个阶段；而在“研发”阶段中，又包括了许多与研发相关的流程；在这些流程中，包含了前端开发的流程。
从项目管理的角度来看，前端开发只是一个很小的环节，甚至有些领导“不知道”有专门的前端岗位。然而，经过多年的前端开发工作经验，包括游戏开发、后台系统和H5项目，我发现，在业务开发中，前端的工作量非常大（其他岗位边界更加清晰一些，在整个研发流程中，看起来有很多事情做，实则不然）。
尽管如此，在展示研发成果时，前端开发显得很被动，展示内容也比较少，特别是面对不懂技术的人。外部人员通常更喜欢听到诸如“数据”“安全”“云计算”“分布式”等词汇，对于前端工作的认可较少。这也应验了一句话：“管理流程的人看起来更重要，事情更多；执行细节的人看起来微不足道，产出也少。”
本文中，我会讲在一个常见的团队中，包含产品经理，UI/UX，前端研发，后端研发，测试等岗位，前端开发流程的方法论。秉持着“在粪坑中搞科研”的精神，总结这些年的心得。
graph TB;
需求分析阶段 --> 设计阶段;
设计阶段 --> 实现/编码阶段;
实现/编码阶段 --> 测试阶段;
测试阶段 --> 部署/交付阶段;
部署/交付阶段 --> 维护和支持阶段;
测试阶段 --> 实现/编码阶段;
维护和支持阶段 --> 需求分析阶段;
1. 瀑布/迭代模型
瀑布模型强调在所有准备工作完成后开始开发；迭代模型则强调“循序渐进”的开发模式。这两者都是线性的开发模型，笔者经常会听到“迭代”这个词。
2. 敏捷开发
敏捷开发是一种灵活的开发方法，强调迭代和持续反馈。它是一种方法论，可以应用到所有能够提升效率的开发模型中。通过短周期的迭代，团队可以不断调整和优化产品，快速响应需求变更。这种方法特别适用于需求动态变化的项目。笔者也接触到许多自称“敏捷开发”的团队。
3. 玄学/其他
有些项目的开发模式难以定义，通常是由老员工或老板制定的，后来者必须适应前者留下的方式。
笔者认为，线性的开发模式对“细节执行”的岗位是有利的，它会明确执行者的上下文和边界，给予执行者“保护”；而非线性的开发模式对执行者是不友好的，会将人性的丑陋暴露出来，体现出人性的“反复无常”。
综合来看，“迭代”开发对于研发同学比较有利。
二、前端开发流程
假设，团队里面只有老板与前端，我们可以“多快好省”的实现老板的目标：产品我们直接从老板（客户）口中获得，UI我们根据UI库提供的组件来实现，数据我们自己来管理。但是，当团队出现了其他岗位以后，所有的事情都变了。我们不能“最大化”的为老板做贡献了，他们成了“魏忠贤”。
1. 前端的视野
在常见的敏捷团队中，前端的视野是这样的：
很明显，前端在开发过程中，属于最下游。
2. 笔者的开发流程
基于最下游的地位，对于拿到一个功能后，笔者的开发流程是这样的。
- 第一步：实现前端骨架（如同”react编程哲学“那样），包含各种嵌套关系，各种静态展示；
- 第二步：mock后台数据，填充；
- 第三步：根据UI稿完成样式，如果有”基础组件“变动，比如 组件库里面的button（设B)与UI设计稿上的button不一致，可能会有两种处理方式，一种自己写一个简单的，丢失了很多交互以及样式，另一种是直接拿组件库里面的button来修改；
- 第四步：根据后台接口数据进行调整，有时候有些状态可能在接口里面不存在，需要各种状态拼接；
- 第五步：自测，完善UI，完善交互；
- 第六步：联调
- 第七步：产品、UI验收
- 第八步：修复问题
- 第九步：提交测试
graph TB;
A[实现前端骨架] --> B[mock后台数据，填充];
B --> C[根据UI稿完成样式];
C --> D[根据后台接口数据进行调整];
D --> E[自测，完善UI，完善交互];
E --> F[联调];
F --> G[产品、UI验收];
G --> H[修复问题];
H --> I[提交测试];
I --> H
这几步中，第三步、第四步非常不可控。他们来源于别的岗位，别的人，而他们在做的时候可能会很少考虑到前端实现组件所需要的物料。
在无法push别的岗位的情况下，我们只能调整自己的开发步骤，跟别的岗位battle来获得自己需要的物料。
因此，需要前端调整自己的开发路径，让编码过程可以被可控。
graph TB;
A[与UI沟通样式] --> B[与后端沟通接口];
B --> C[实现前端骨架];
C --> D[实现数据填充];
D --> E[自测，完善UI，完善交互];
E --> F[联调];
F --> G[产品、UI验收];
G --> H[修复问题];
H --> I[提交测试];
I --> H
先跟UI同学沟通，是为了保证不需要重新开发组件，防止UI同学自由发挥；
然后与后端同学沟通，是需要让后端同学能够写出符合UI组件需求的数据结构，减少因为后端数据没有”适配UI“产生的不必要的心智负担；
当然，上面所有的只是一个”假设“，有很多情况需要根据具体情形进行调整。
3. 理想的模型
一个相对理想的模型是这样子的：前端可以关注最少得点，心智负担降到最低
这里的关键是：组件库。
UI/UE在设计的时候，就要考虑通用的UI组件，而不是自由设计；
后端在给前端提供数据的时候，也要考虑组件需要的数据结构，而不是直接简单数据库数据拼接；
虽然上面对比第一幅图貌似前端关注点只减少了一根，但是后端、UI/UE提供的物料，对前端友好。
这里，UI/UE与后端同学可能都“不愿意”被前端组件影响到，需要用些时间来对齐思想。
这个时候的开发步骤，就可以重新梳理：
graph TB;
A[mock数据] --> C[实现前端骨架];
C --> D[实现数据填充];
D --> E[自测，完善UI，完善交互];
E --> F[联调];
F --> G[产品、UI验收];
G --> H[修复问题];
H --> I[提交测试];
I --> H
红色背景的框里面的步骤基本上占用的开发时间相对可控，而且较短，前端可以不太”受制“外部的印象，关注点集中于prd功能的实现。
需要强调一下，前端组件库对于后台管理系统来说，至关重要！或者说，是第一位的重要！
GO ON
后续补充中~~~~
