bug比＜0.1？这位抖音研发是如何高效支持业务开发的

先介绍一下自己，

• 2020.5月入职抖音后，参与需求50+，总计估分100+，累计提测Bug数10个不到，Bug/估分 < 0.1；
• QA/RD反馈需求质量较高，希望传授方法技巧；
• 思考总结了做需求过程中的经验/方法论，结合几个典型Case，和大家做一分享；

---

1.需求调研

一个需求分配给你，该怎么操作？

1.1了解需求

按照理解的深度，分了几个层次：

1. 初读PRD，知道需求要达到什么效果；

知道「干什么」；

2. 按照自己对项目的理解，再读PRD，发现「技术难点」、「不合理点」；

和PM详评、讨论大致技术方向；
知道「难点」；

3. 详读PRD，理清功能，确定技术方案；

知道「怎么做」；

4. 最后快速回顾PRD，确保技术方案合理性、确保需求完成度；

知道「做对了没」；

1.2.熟悉上下文

需求会有它执行的上下文环境，涉及几个方面：

1. 该需求的历史遗留实验代码；
2. 和该需求有冲突、依赖、关联的相关需求代码；
3. 需求的上下文代码环境，至少了解将要改动代码的调用链路；

在熟悉代码过程中，通过UML图输出代码导读，是比较推荐的方式：

4. 如有机会，主动了解周边同事，是否也同时期涉及这部分的改动；

1.3.技术调研

按照需求的不同分类，技术调研会有不同侧重点：

1. 新feature功能，需要调研之前没有的系统实现；
2. 已有feature功能，需要较大重构；
3. 已有feature功能，功能调整；

技术调研要达到什么效果？

1. 清晰的估分，知道完成这个需求，涉及的任务细分；
2. 所有不确定点都搞定，至少有可行方案；

2.开发

2.1思考

• 开始开发，不要急于敲代码，思考一些问题：
  • 扩展性：之后如果有类似需求，如何高效支持？
  • 功能架构：模块如何保证稳定性，不被别人改坏，如何保证扩展开放修改关闭？
  • 抽象能力：PRD是一种「需求」？还是一种「能力」？
  • 性能问题：是否会有可能的性能问题，如何从设计角度优化？
  • 稳定性：抖音工程体量大，如何保证你的修改不影响已有业务？
  • 可阅读性：代码是给别人看的，如何降低别人对这个业务的理解成本？
• 代码只是将你上述思考的结论，固化为可执行程序；

2.2 副作用

抖音代码体量大，需求任何需求，至少需要保持不影响上线功能，也就是降低需求「副作用」；
下面有几个经验方法：

• 高内聚

  • 一个需求功能，最好内聚到一个模块，集中处理；

• 非实验，功能完整回退

  • 新需求一般会带AB上线，在实验组关闭时，要保证代码完全按照线上逻辑执行；
    • 在实验开启的情况下，走新Feature方案，并提前return；
    • 新Feature实验代码，建议只加一处AB的读取，通过自描述的公开方法，向外界暴露；

Learning

• 降低副作用，别人不用感知新需求最好；

2.3关于注释

建议：

• 新Feature，声明文件带上描述、PRD;
• 至少接口中暴露的方法，提供注释；
• 代码量较多的文件内，代码按照#pragma mark 按照功能分割，尽量注释；

2.4关于日志

建议：

• 功能类Feature，会有该Feature的准入判断，在判断函数处，增加日志；
• 方便后续反馈问题定位；
• 下图是后续查询问题，发现缺失的日志，后期补的；

2.5代码洁癖

• 这个词经常被提及，实际如何操作？
• 体现一个RD对代码的「艺术」追求；

虽然对于性能、架构等，并没有任何实质性的作用；
但是：

1. 上述代码，看起来工整，让作者和阅读者都觉得清爽、舒服；
2. 代码不仅是用来运行的，也是一个RD的「门面」；
3. 对代码的高要求，从「代码洁癖」开始；

3.时间管理

• 人的精力有限，相同时间下，如何更有效的工作？
• 工作时间内，如何保持精力充沛？

3.1作息时间

• 保证睡眠时间，建议调整健康的作息习惯：
• 充分利用早起的时间：
  • 个人习惯9:00开始工作；
  • 不打扰别人，10:30后再使用办公软件交流；

这点强烈建议，早起思路清晰，效率高很多；

• 睡眠保证：
  • 个人建议23:00左右开始准备入睡；
  • 每天保证8h的睡眠时间；
  • 早起工作和熬夜工作，花费时间一样，但是效率/对身体的伤害大有不同；

3.2日常调节

• 精力有限，不可能长期集中精力，需要定时调节；
• 建议1-2h起来走动，调节下自己的节奏；

3.3适当运动

• 程序员长期久坐，对身体不好，要维持职业寿命，保持运动的习惯；
• 个人习惯：
  • 一周至少锻炼3次；
  • 每天中午去健身房跑步30min；
  • 周末保证出门散步1～2h；
  • 饮食健康，一周6次健身餐；

4.开发效率

日常工作不可能只限于需求开发，如何在繁杂的工作中，快速切换上下文？

4.1上下文切换

上下文切换的成本是很高的，理应尽量避免切换；
建议操作：

• 工作安排应该是一个「栈」的数据结构，高优先级的事情，永远在栈顶；
• 按照优先级，一次只做一件事，做完后依此出栈；
• 遇到高优任务，保存刚才工作的上下文，快速解决高优任务后继续；

4.2工具

• MBox

  • 建议MBox 建几个workspace，每个任务一个workspace，任务直接快速切换；

• VSCode + Platuml

  • 结构化/图形化，快速整理代码思维逻辑；

• Lookin

  • 通过UI快速定位代码，在需求开始阶段效率提升；

• Xcode

  • 断点

    • 上面通过Lookin找到类；
    • 设置该类的断点，快速找到调用堆栈；
    • LLDB 调试技巧

  • Xcode Author，显示代码提交记录

    • 建议保持打开状态，阅读代码过程快速了解相关需求；

5.测试

几个问题
Q：测试应该全部交给QA，QA才是质量保障？
Q：RD自测都应该干什么？
Q：要不要写单元测试？

5.1认知测试

• 白盒测试：RD
• 黑盒测试：QA
• 灰盒测试：Code Review

5.1.1白盒测试

这里指RD对一个需求的自测；

• 一个MR涉及什么改动，只有该需求的RD最清楚；
  • 建议每个需求，RD提供一份QA可以读懂的改动记录：[产品技术方案 1604] IM 里视频文件和普通短视频支持上下滑动切换
• 白盒测试范围，应该大于黑盒测试；
  • RD通过对代码上下文的了解，实验的了解，应该比QA 清楚测试的影响范围；
  • 代码会产生什么副作用，带来什么预期；如果和RD的预期都不符合，需求是不达标的；
  • 也就是说，RD的自测case >> QA 的自测case；
• 要降低提测需求的bug数，这步很关键，估分里要考虑进去；
  • 建议保证0.5d - 1d的自测时间；

5.1.2黑盒测试

这里指QA测试；

• QA是质量保障，RD应该提供需求影响范围，供QA更有效测试；
• QA比RD会更熟悉业务场景，在case评审的时候，RD需要从QA侧得知更多关于该需求的关联场景：（实验、关联需求等）；
  • QA/RD 各有所长，理解各有gap，case评审预期应该消除理解的gap；
• QA 更多的是精准化测试，以PRD为导向，非需求涉及的改动，可能测试不到；
• 经过上面系统的白盒测试，理论上这里出现问题的概率应该很低，大家都可以很高效；
• 上线前的最后保障，系统的验证需求，保证质量；

5.1.3灰盒测试

这里指Code Review

• RD/QA测试期间，可以拉同学进行Review代码；
• 研发同学会更熟悉代码上下文，通过代码层面，指出可能存在的问题；
• 因此不要害怕Review提出的意见，应该虚心接受，肯负责Review代码的同学很少；
• 当然也不能完全依赖Review，实属加分项；

5.2如何自测

• 为保证需求质量，不要仅满足通过QA的自测Case；

建议操作：

1. 提代码前，本地Debug一轮测试；
2. 提代码后，出Inhouse包，真机二轮测试；
3. 提测期间，保留版本日常使用，作为随机测试；
4. 根据需求改动，自己想清楚测试用例，都测试OK后，再看QA的自测Case，查漏补缺；
5. 实验关闭/打开测试，保证线上功能OK；
6. 为保障需求质量，建议保证0.5d - 1d的自测时间；

5.3单元测试？

• 端上的单元测试成本确实高，好的一个测试用例，会比需求更难写；
• 如何尽量写单测？
  • 抽象业务无关的数据结构；

单测如何保证质量

• 并不是说有单测就不会有bug，单测只是保证了你写的case会被一直覆盖；
• 上面提到的数据结构，提测后RD就发现了一个边界case：
  • 之前判断了 left == right 时，认为是无效的移动，其实当数据有11个，窗口为10时，第二次移动会到[10, 10]的位置，就被上面的条件错误过滤掉了；
  • 出问题后，修改逻辑，并补充单测，可以说，因为有单元测试，可以保证这个case之后不会再次出现；

Learning

• 复杂业务需求的拆解能力：
  • 解耦业务，抽象数据结构，通过单测保证数据结构质量；
• 遇到单测没有覆盖的case，及时补充，提高质量；

6.代码Review

功能Ready后，至少从头完整的Review一次自己代码；
需要注意以下几个方面：

1. 思考为什么这里要修改，理清上下文关系；
2. 校验自己「固化」的代码，是不是需求开始时的「思路」；
3. 检查逻辑正确性，常见Crash场景是否处理；
4. 没有意义的变更，如「换行」建议revert，保持review的纯净；
5. 自己至少Review一次后，再找同学Review；

7.综述

• 「知易行难」，如何「知行合一」，需要「格物致知」；
• 「做需求」简单的事情也可以做到极致；
• 盲目追求bug比没有意义，修炼内功才靠谱；
• 最后简单说还是「Owner意识」；