工作周报2025年 3 月 10 日 - 2025年 3 月 16 日

本周工作思考

• 本周100%时间上周的计划的执行，超预期完成问题排查150+，代码上修复了100个类问题，大概有40个多个经排查后走ignore的方式先忽略掉。
  1. 增加了疑难问题分类。部分暂时无法解决，影响人数比较多的，不能确定问题原因暂时放入疑难问题分类，这类问题（1）在14天内持续观察，确认是否是经常性问题，且结合Kibana，对用户没有实际影响，列入ignore分类；（2）如果是新增问题，需要补充日志，能够增加更多的排查线索，以能够代码修复；
  2. 增加待优化分类，部分问题产生的原因是实现逻辑边缘场景造成的，改动范围较大，修复成本较高的，又是非紧急问题，放入待优化分类，等待当前阶段完成目标后，以优化点的开发流程完成修复。
  3. 问题的筛选上，本周调整为最近24小时的范围，同时和14天的问题做一些同类筛选，主要是找到新增问题，以快速找到线上的潜在问题。
  4. 从难易度上说，很多问题的排查比较简单，10分钟能够找到问题所在，然后找到所在的代码，修复方案一般比较明确。目前80%问题是逻辑分支，方法入参检查缺失，数据可用性检查缺失导致。这类问题修复起来很简单，往往一行代码就能解决。另一类比较难的问题，是Sentry上的线索比较少，本地环境无法复现，特别是移动设备上的问题，没法模拟用户环境，这类问题大部分是靠逻辑推演和以及大量的假设去验证，往往需要多次修复，持续观察，这类花费时间比较多多。
  5. 从流程上说，现在从Sentry上到Asana上创建任务，虽然没有走集成的方式，找到了一个比较快速的SOP办法，30分钟左右就能完成数百个任务的获取、筛选和任务创建。
• 养成良好的代码的原子习惯。
  1. 最近2周的Sentry问题排查和修复下来，我发现很多问题的产生是不好的编程习惯造成的。比如很多逻辑，代码里只写了if部分，没有else部分，也就是说，只处理了需求说明的部分，对于需求未说明或者需要挖掘的需求功能，代码上没有继续深挖处理。
  2. 从编程的原则习惯上说，手写if后，肯定是有else部分，哪怕是看门狗模式，逻辑也应该是if-else闭合的，多分支的情况中，switch的default部分也需要数据异常的情况，比如参数错误，有了异常分类，程序要如何处理。写方法是，首先就是参数可用性和合法性检查，特别是公共方法。这些我觉得应该是形成自己的原则习惯，形成一写if，应该就else这种原则习惯。
  3. 使用cursor在写提示词的时候，也要形成这类的原子习惯，比如生成方法的时候，“结合上下文必须对参数做合法性检查“这类提示词一定写上，然后可以补充参数异常的处理。虽然有时候不写，也能生成参数的代码，但是为了逻辑的完整性，一定要在提示词里加上，避免遗漏。当然也可以把这类提示词放在rules里