小改动也要走完整流程：给日常开发的一份自查清单

日常开发里最容易出问题的地方，往往不是难度很大的需求，而是看起来很小的改动。改一行文案、调一个默认值、换一个字段名称，都可能牵动意想不到的链路。本文整理了一份可以反复使用的自查清单，帮助开发者在改动提交前、上线前和上线后，各自多看一眼。一、提交前：先把影响范围画出来

提交代码之前，先回答三个问题。第一，这次改动影响哪些页面、哪些接口和哪些数据。第二，有没有被其他模块复用的公共逻辑。第三，默认值、边界条件和异常分支有没有一起改。如果这三个问题有一个答不上来，就先停下来把链路理清楚，再继续写代码。

二、测试时：不要只测改动点

只验证改动本身通过，往往不够。建议同时做三件事：跑一遍与改动相关的原有测试；手动走一遍最常用的操作路径；再故意试一次边界情况，例如空值、超长输入和重复提交。测试记录不必写得很长，但要写清楚测了什么、结果如何、哪些情况还没有覆盖。三、评审时：让别人能快速看懂改动

一份好的改动说明，应该让评审者不用猜。写清楚改动目的、影响范围、测试方法和回退思路。如果改动涉及配置或数据结构变化，更要单独说明兼容性：旧数据是否还能正常使用，新旧版本同时存在时会发生什么。把这些信息写在前面，可以减少来回沟通，也能让问题在评审阶段就被发现。

四、上线后：留出观察和回退的时间

上线不是结束。建议上线后先观察核心指标和关键日志，确认没有异常波动，再处理下一项任务。同时提前想好回退方案：什么情况下回退、由谁执行、回退后需要通知哪些人。回退方案越具体，真正遇到问题时就越从容。

结语：把清单变成习惯

清单的价值不在于一次用得多完整，而在于每次都能稳定执行。可以先从三条做起：写清影响范围、补齐边界测试、准备回退方案。等这三条成为习惯，再逐步扩充自己的清单。把小改动当作正式改动对待，长期来看反而是最省时间的做法。