看起来很小的改动，往往并不小

我加入团队后接触的第一个功能，看起来小得让人很放心：调整一个信息提示框。

只看工单，我以为这会是一次直接的界面修改。到了需求细化，一位资深开发提醒我们，这个提示框并不是一个单独组件，而是已经存在二十多个版本。 需求没有变。变的是我对它所处系统的理解。

在那之前，我下意识认为复杂度会直接写在任务表面：大功能看起来就大，小改动看起来就小。成熟产品往往不是这样。一个很小的界面改动，可能正好落在多年积累的决定上。

这些版本并不是无缘无故出现的。每一个都曾经解决过某个真实问题：客户差异、法规限制，或者一段已经无法轻易移除的历史设计。

单独看，当时的每个决定可能都很合理。叠加以后，它们却形成了一段新接手的人完全看不见的系统历史。

从那以后，我看到“小改动”时不会先乐观。我会先问：这里已经有多少版本？它们为什么存在？哪些假设被埋在里面？ 这些问题往往比工单本身更接近真实工作量。

软件积累的不只是代码，也积累决定。界面上改了多少，很少能直接说明系统里真正要动多少。