北京
一个任务、一个关注点、一到两个文件、一个测试、一条命令。这是软件工程师Anton判断代码拆分何时停止的规则——不是看行数，而是看是否还有任何需要"查一下"的东西。
Anton目前主要用PHP/Symfony和Go做开发，正在把一个运行中的PHP单体架构拆解成Go微服务。这是他系列文章的第二篇，上一篇讨论的是执行者必须知道什么、不该知道什么，这一篇聚焦同一问题的另一半：工作单元要小到什么程度，才能让"不需要查表"成为可能。
四步拆分法，只有最后一步有定义
Anton把工作单元拆成四个层级，其中只有最后一级有明确的定义标准。以"服务应该从平台获取运行时配置"这个任务为例，拆解路径是这样的：任务之下是阶段，阶段之下是子阶段，子阶段之下才是迭代——一个迭代只处理一个关注点，实践中通常是一个代码文件，偶尔是两个同构的文件，加上覆盖它的测试。
如果一个迭代无法在一次通过中完成，就把它拆成两个迭代，而不是拉长成一个漫长的迭代。Anton强调，拆分失败的表现不是"耗时太长"或"diff太大"，而是执行者不得不去查东西——无论是需要嵌入的类型、某个错误的名称、辅助函数所在的包，还是隔壁同事是怎么做的。一旦出现这种情况，说明迭代里藏着一个未言明的依赖，拆分方式就是错的。
真实数据：13、12、40次迭代
Anton给出了最近几个阶段的真实规模：一个阶段包含13次迭代（迁移离开手写运行时），一个包含12次（骨架生成器），还有一个包含40次——那次是把44份四种读取形状的代码迁移到一个通用核心上，每个文件一次迭代。
40次迭代听起来很夸张，但看看每次迭代的实际内容就明白了：改一个文件，移动它的测试，跑一个包的测试。每次15到35分钟。Anton用表格展示了这三个阶段的对比：13次迭代用于迁移离开手写运行时，12次用于骨架生成器，40次用于把44份手写读取形状迁移到一个通用核心上。
唯一的可靠信号
Anton说，他找到的唯一可靠信号是：执行者不得不查东西。不是"花的时间长"，不是"diff很大"。如果任何东西需要被查找——要嵌入的类型、错误的名称、辅助函数在哪个包、邻居是怎么做的——那么这个迭代就携带了一个未声明的依赖，拆分就是错的。
这个标准重新定义了一整类抱怨。当一个迭代带着澄清问题回来时，问题不是执行者的失败，而是任务切分方式的缺陷。所以修复方法从来不是"回答它"，而是补充事实、切得更小。
被排除的"合理"迭代
Anton还列举了几种听起来合理但实际上不合格的迭代类型："走一遍路径，修复每个丢失值的步骤"——这是带修复的搜索，应该先走查，再为每个出问题的步骤写一个迭代；"找到它在哪里崩溃"——这是调查，不是迭代；"搞清楚它是怎么做的"——同样不是迭代的范畴。
这套方法的核心逻辑很直接：如果执行者需要查任何东西，说明信息没有在任务描述中完整传递，切分就不够细。把"查一下"作为拆分的停止信号，比任何行数限制都更接近问题的本质。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
