别让注释变成“历史遗物”
很多人在重构代码时，习惯性地把旧的注释原封不动地保留下来。比如一段处理用户登录的逻辑，原本是用用户名密码校验，后来改成了 OAuth 授权，但注释还写着“验证用户密码是否正确”。这种注释不仅没用，反而会误导人。
注释不是文物，不该用来纪念过去。它应该是当前代码的“说明书”，告诉别人这行代码在做什么、为什么这么做。
写清楚“为什么”，而不是“做什么”
代码自己会说话。“user.isActive()”这行代码已经说明了它在检查用户是否激活，你再写个注释“检查用户是否激活”纯属多余。
真正该写的是背后的原因。比如：
// 临时绕过风控，因支付网关对接期间频繁误判新用户为风险账户这行注释解释了一个看似奇怪的逻辑：为什么新注册用户能直接进入支付流程。没有它，别人可能会觉得这是个漏洞。
重构时顺便清理注释垃圾
就像搬家时不会把旧家具全搬走一样，重构也不该把所有旧注释都留着。看到过时的、模糊的、重复的注释，顺手删掉。干净的代码配上精炼的注释，读起来才舒服。
有些注释甚至比代码更早该被淘汰。比如：
// TODO: 优化性能（写于2018年）这种“长期未完成”的注释，不如改成一个实际任务，然后删掉它。
复杂逻辑配一段简短说明
有些算法或业务规则没法靠变量名和函数名完全表达清楚。比如计算优惠券叠加的规则，涉及多层条件判断。
这时候可以在函数上方加一段简洁说明：
// 优先使用平台券，店铺券仅在无可用平台券时生效
// 若用户有满减+折扣双重权益，先扣满减再打折扣不需要长篇大论，只要让接手的人能在5秒内理解设计意图就行。
别用注释代替好名字
有些人喜欢写一堆注释来解释一个叫 processData() 的函数是干啥的。其实更好的方式是把函数重命名为 calculateMonthlyRevenueForActiveUsers()。
好名字本身就是最好的注释。当你发现需要大量注释才能说清某个函数的作用时，先想想能不能换个更准确的名字。
重构代码不只是调整结构，也是梳理思路的过程。注释就是这个过程的副产品——它不该是负担，而应是帮助他人快速理解的桥梁。