研发流程详解
全流程概述
项⽬委员会：这是⼀个很虚的⾓⾊，即能确定项⽬是否要做的那帮⼈，有时候可能就是⼀个⾼级经理就能拍板确定。和我们实际开发没啥关系，不⽤去关⼼他。
PM：产品经理，也是⼀个项⽬的推动者，即兼职项⽬经理的⾓⾊。
UE：交互设计师，负责页⾯布局、交互的设计，不负责视图的细节。
UI：视觉设计师，交互确定之后，设计页⾯样式。注意，很多情况下，UE 和 UI 是⼀个⼈。
RD：后端开发⼈员。
CRD：客户端开发⼈员，安卓和 ios 都是。
FE：前端开发⼈员。
QA：测试⼈员。
OP：服务器运维⼈员，⼀般负责审批上线单。
在说⼏点注意事项：这个流程是站在前端开发⾓度来分析的，因此好多步骤的发起⼈都是 FE。（PS：在此我也希望⼤家在⼯作中都要做到积极热情，主动承担⼀些事情，你会得到收获的。）
这个流程看着⾮常复杂冗长，你可能会担⼼执⾏起来的效率。其实，我只是把所有的细节都画出来了⽽已，实际执⾏起来不会太⿇烦，有些事情很快就能做完，例如联调。
图右侧列出了每个步骤的交付物，即该步骤做完需要产出的⽂档或者其他内容。交付物是项⽬管理中⾮常重要的概念，有了交付物才有能证明你真正做了执⾏并完成了这个步骤，⽽且万⼀后⾯出了问题，也可以回溯（甩锅）。例如评审会结束之后，⼀定发邮件写出会议结论和评审⼈。
上述流程有些可能会被⼤家忽略，或者觉得多余、浪费时间，例如技术⽅案设计和评审，再例如⾃测。其实只要你有点开发经验或者项⽬管理经验，都应该知道这不是浪费时间。拿技术⽅案设计来说，如果你接下来开发程序很顺利，写⼀个技术⽅案并不是难事⼉，你不会因此⽽延期；但如果你技术⽅案写了两天都没写出来，那你开发的时候估计也磕磕绊绊不顺利，延期风险很⼤。
详细流程
接下来我们将假想⼀个实际的案例（因为我们不会在这⾥演⽰如何开发）—— 为页⾯增加评论（发布评
论，评论列表、点赞、回复） —— 这个功能，来把上述各个步骤详细分析⼀下，⼀来是再深⼊了解⼀些细节，⼆来是帮助⼤家加深对整个研发流程的理解和印象。
项⽬⽴项
这个过程我们作为 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 影响严重，
还需要项⽬的主要⾓⾊写检讨，做复盘汇报，总结教训。
项⽬总结（可选）
项⽬总结是可选的，⽽且我发现⼤部分的团队都不会去做总结，觉得上线完了就⼤功告成，该启动下⼀个项⽬了。但我觉得，⽆论是不是做项⽬，做完⼀件事（如看完⼀本书）就应该⾃⼰总结⼀下。回顾⼀下经过，总结⼀下得失，积累⼀点经验，这样才能慢慢成长。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。