背景
记录下这段时间工作中出现的问题，以此警醒自己，避免再犯同样的问题。
202207～202303
- 代码push完之后，检查下有没有低级的错误，再求CR。
- 解决冲突最好的方法是，先接受对方的所有修改，然后将自己之前的CR内容粘贴过去。
- 作为RD，要对自己的卡片负责，自己生的bug，得好好地将其送走。
- 做数据接入和聚合类型的工作时，应先对数据进行统计分析（比如group by、count等）。如遇到PM给的聚合规则有问题的时候，如果做过数据统计，就可能提前发现给的规则存在问题，问题越早暴露，解决它花费的时间越少。
- 即使是个简单的任务，也可以过下设计，或者问问PM其想要的结果是怎么样的，某个字段要不要，某种情况要不要过滤。
- 任务启动之前，应明确任务的背景，去和PM沟通，确认所写的需求和你理解的需求是否有出入。
- Linux任务用了&进行后台执行时，最好加上nohup。曾因为没加nohup吃过苦，分析任务要执行3小时，跑一半后电脑锁屏，最终没跑出结果，浪费很多时间在排查问题上。
- 编程要悲观防御，尽可能考虑不同的case情况，如解析bid失败的情况。
- 有正则表达式的任务，先把正则表达式测试完毕，再放到代码中执行，这是因为不同的语言中（如Java和Python），正则表达式可能需要插入额外的转义符。
- 代码上线时，先同步主干到分支，解决冲突后再将分支合入主干。这是因为其他人在其他分支上开发的内容合入主干之后，你的分支修改了同一个文件但不是同一个位置时，不需要解决冲突，这个时候直接合入会导致别人的提交的内容被覆盖。
- 迁移逻辑时，最好不要修改位于调用链较深处的方法，而是新增一个方法，然后让顶层的方法来调用它。因为位于调用链较深处的方法可能被其他方法调用，修改它造成的影响和破坏可能超出你的预期。
- 代码上线出现问题时，对于要修改之处，改完之后仍然要测下才能再重新上线，否则只会浪费自己的时间。
- 准备好黑盒测试代码，一旦线上出现问题，修改完后能立即测试回归验证。