小一点的改动，完整一点的答案

简洁的代码，并不总是从少写几行开始。很多时候，它从弄清楚“这次究竟要解决什么”开始。

一个看似局部的问题，可能连接着调用方、配置、测试和用户已有的数据。只改眼前的一行很容易；找到真正的修改边界，需要先读懂这些关系。

先看边界，再动手

修改之前，可以把问题压缩成一句能够验证的话：在什么输入下，当前发生了什么，期望发生什么。描述越具体，越容易分辨哪些改动是必要的。

接着找到相关的入口和调用点。一个共享函数中的修复，通常比在多个调用方重复绕开问题更容易维护。但前提是，已经看清它被谁使用。

让已经存在的东西继续工作

一个项目通常已经有自己的语言：处理错误的方式、组织模块的方式，以及展示状态的方式。沿用这些约定，能减少读者理解新代码时的负担。

新的工具和抽象当然可能有价值，但它们应该回应已经出现的重复或复杂度，而不是为尚未发生的需求预先搭建舞台。

少写代码的前提，是没有把必须完成的事情留给别人。

让验证对应真实的问题

验证不必庞大，却需要命中风险。如果修复的是边界输入，就验证这个输入；如果改动影响已有调用方，就检查这些调用方是否仍然成立。

只照着实现复述一次的测试，很难告诉我们遗漏了什么。更有用的问题是：哪种正常的使用方式，最可能因为这次修改而失效？

把完成也写清楚

一次改动结束后，留下一段简短的说明：改了什么、为什么这样改、如何验证，还有哪些已知限制。它既帮助现在的使用者，也帮助几个月后重新打开文件的自己。

小改动并不意味着低标准。它意味着把注意力集中在问题本身，直到答案足够完整。