每周一次的技术小结。

测试回归、接口依赖、业务隔离、新知识学习（一周小结）

这周时间过得飞快，忙一个提审的大功能，从周一到周五满负荷开发、走查、修bug，
不知不觉一周就过去了，周五晚上也提审了，这个过程算是有惊无险。
这篇文章对本周我自己的思考和总结做下总结。

一、修复的case自己一定要先回归一遍

背景：

1. 产品要上一个新功能，然后上线前让测试同学去回归，结果测试同学说之前不知道有这个功能。
回归路径发现，这个功能产品提出来之后，没有提单，我合入代码时，和另外一个大需求一起合入了。

2. 另外一个组的测试同学在群里问产品某功能的预期，然后我按照预期进行了代码调整，
因为调整得代码很简单，所以我自己没有走回归路径，然后因为测试同学觉得很简单，也没有提bug单，
导致上线前最后一刻才发现修改后的逻辑会被其它业务影响，还是有问题。

所以，

无论是需求变更还是bug，一定要提单！

任何时候都不要自信觉得自己的代码没问题，没有经过测试的代码就是没有完成的状态

二、强依赖接口的需求测试流程选择

背景：

周一设计给了A业务的设计稿，我周一当天就开发完A业务然后合入了测试分支，但因为A业务依赖了B业务，
需要B业务提供一个接口进行密码校验，也就是调用接口返回 suc or fail，
但B业务开发工作比较多，提供接口要在周三晚上才提供到，导致A业务虽然周一已经开发完毕了，
但一直到周三晚上才接入A业务，导致A业务的测试流程后置到B业务开发完毕，
留给测试和开发修bug的时间都非常紧张。

其实在A业务依赖B业务的场景下，测试流程有两种方案：

• 方案一（高风险）：A业务同学提前提供B业务的mock接口，mock回包数据先让测试同学测A业务
  • 收益：提前测试A业务，方便暴露A业务的问题
  • 风险：mock B业务的回包，可能会导致等B业务真正接入后，忘记或者漏测了 A和B业务 真实（非mock）的流程
• 方案二（特殊场景使用）：A业务等B业务开发完，再启动A和B的测试工作
  • 收益：回归的是现网发版本的完整路径
  • 风险：测试和开发风险

方案一和方案二是互斥的，在提审压力不大的情况下，采取方案二，在提审压力比较大，且A业务亟待回归的场景下，可以酌情考虑方案一。

采用方案一带来的风险比方案二大很多，方案二最多只是导致提审延迟，但方案一可能会导致A和B业务对接正式流程未回归，测试用例没有覆盖全。

三、多人协作开发时，强绑定的业务做好业务隔离

背景：

最初我设计了一套面向A业务的功能框架，后续B业务也接入了我的功能框架。
结果我在处理A业务的功能框架时，因为没了解清楚B业务的业务逻辑，
导致修复了A业务的问题，使得B业务也需要跟着变更。

之前我有说过，新业务接入要做好业务隔离，但没有具体指出隔离的方法，
常用的隔离是：

• 添加scene，区分场景值执行对应的action
• 代码隔离，不同业务执行不同的代码，即使代码冗余一点也没问题
• 新增的字段要标注好是 common（通用），还是 particular（业务专用）

四、新知识学习

我渐渐是发现技术能力强，不一定会对公司带来更高的收益，沟通能力、合作意识这些也非常重要。

但在沟通能力、合作意识这些软技能基本相同的情况下，技术能力强可以非常有效地提升贡献力。

我总结了下我工作中遇到的对高技术需求的场景：

• 技术方案：比如最近的 submodule抽取SDK、HDR视频合成相关、skia渲染相关
• 底层知识：比如CPU、GPU实际运转、设计库设计相关，只要稍微优化的场景，都会涉及这些底层知识
• 新技术：比如大前端工具、flutter跨终端原理、各种开源库原理
• 算法：比如团队里正在担当面试官的同学讨论的动态规划算法题、贪心算法题等

做为一名技术人，基本每天我眼前都会出现我没接触过的知识点，
那么我就要思考，我怎么样能够深入且熟练应用这些技术呢？
经过我过往那么多年的经验，发现需要针对性处理。

• 技术方案：提前了解知识点，熟悉原理和实现，掌握应用能力
• 底层知识：只看原理是不够的，还需要动手写代码开展相应的优化工作
• 新技术：面对新技术最重要的是先掌握核心原理
• 算法：刷算法题是程序员的基本工作，相当于在学校老师布置的作业，虽然头疼，但是必须做的。