也是以后的工作总结与更新

坑与被坑

  • 不要说别人做没做到，问你自己做没做到。很容易挖坑
  • 合入主动问还缺什么。自己充分验证要留下证据。不要自己合入，自己觉得没问题，但是经不起推敲
  • 实际上Pull Request模板能做到上面的覆盖，但是实际上并不是人人都遵守 or 模板要求不全面，导致各种没对齐，当前项目的用例门禁是不全面的。这本来是流水线/门禁的工作，但实际上推到了实际开发的人身上。本质还是没有充分验证。
  • 推动别人review，没办法。都忙
  • 自己的写法上面不理解不接受怎么办？上面还觉得自己设计的挺好怎么办？
    • 如果自己没有新方案写不出更好的，捏着鼻子忍着
    • 自己写的自认为比原来的好但是不接受 -> 捏着鼻子忍着 or 离职
  • pr信息写全面，简单总结改了啥，没人看你补充的用例。把reviewer当智障
  • 验证是对自己负责。
  • 确认问题是否解决要自己验证一下，不要信别人，不然自己背锅
  • 写代码有点追求。别指望别人给你review，事实上根本review功能就是废的，没人真的细看，用例补充是对自己负责，因为别人没义务负责，顶多挑挑格式问题
  • 接上条，如果之前代码没写好，大家也没review，后面大概率会被鞭尸。躺平任嘲，记住，写好代码的义务在于自己，不要指望别人真能指出问题
  • 完备性，就是边角的用例场景，这种填坑的活真不愿意干。尽量想到吧，想不到没办法。
  • 还是代码，对代码可能有错误理解。这个理解一定要反复确认。
  • 还是代码。注释文档要齐全。补齐。越齐全越好。自己动过那个功能，没有文档，就把功能的文档补齐。
  • 结对编程初衷是好的，但实际上没人真的结对了。大家不过是共同填坑。
  • 效率。定好时间线，早点做完再划水，代码真的没多少，想法时间 > 写代码时间 > 划水时间
  • 对接，坦然面对别人不鸟你。自己热情别减。都是工作。做好记录反馈就好了。保留证据。
  • 还是对接，推不动别人让领导推动。人微言轻啊胖友。

沟通

  • 邮件说清楚，做了什么，做了多少，做到了什么程度，不要图省事儿
  • 打字说问题，完整说清楚，上下文别省略

喷与被喷

  • 定位问题

    • 给上下文相关的信息，简要概述
    • 给自己的简单结论和证据,（现象，日志，回报结果等）给个别误导他人的简单思路，或者跪求帮忙别说话
    • 给他人定位所需的基本信息，别扔一句话跑了等人家反馈

  • 敲定一个默认值，敲定一个方案

    • 验证过是最佳的值了吗？问过别人意见没
    • 是不是需要和其他服务搭配调整？
      • 牵一发动全身的配置改动有没有配套的校验工具？你能不能提供一个？
    • 想不到就是你遗漏，你遗漏就可能会挨喷。想的越仔细越好

  • 还是敲定一个方案

    • 问过别人意见没？确认过了吗，虽然这是你的小小代码，但还是很容易写出垃圾设计

  • 修问题

    • 能从根源搞定，不要用规避方案