我印象很深的一次代码评审我指着一行刚提交的逻辑问这个getData到底是什么的简称写代码的同事挺坦然就是拿数据这段本来就是历史遗留能跑就行。旁边另一位同事补了一句别纠结了这文件里还有三处一模一样的重复逻辑先上线再说。结果那个模块后来变成了整个系统里最让人头疼的地方。三个月后被迫重写重写成本是最初顺手改名成本的几十倍。那时候我还没系统地想过破窗和童子军军规这两件事但那次经历让我记住了代码里的小问题从来不是小问题。这篇文章我想把这两条来自《程序员修炼之道》的原则掰开揉碎讲清楚包括它们背后的心理机制、我在代码库里见过的典型破窗长什么样、童子军军规到底怎么落地以及落地时最容易踩的坑。适合刚入行的程序员也适合正在为代码质量头疼的技术负责人。1. 破窗理论从犯罪学到代码腐化为什么小问题杀伤力最大1.1 原始理论是怎么来的上世纪80年代初两位犯罪学者在一篇研究城市治安的文章里提出了一个后来广为人知的观察如果一栋楼有几扇窗户破了而没人及时修很快就会有更多窗户被砸碎甚至引发更严重的破坏。原因不是窗户本身有多重要而是破损本身传递了一个信号——这里没人管这里的秩序已经失守。一个街区只要出现这种失守感轻微的失序就会像滚雪球一样放大。这套逻辑被引入软件工程之后成了讨论代码质量时绕不开的理论基石。我第一次读到的时候脑子里马上浮现出自己刚入行那年维护的一段老代码一个函数里有十几处被注释掉的历史逻辑缩进混乱中间还夹着一行这里先临时处理回头再改。那个回头到现在已经过了好几年。1.2 软件世界里的第一扇破窗是什么在代码库里破窗不一定是多大的技术债。它可能只是一个含义不明的变量名、一个空着的catch块、一行被注释掉的测试、一次用来绕过校验的临时开关。这些单独拎出来看都极其不起眼修复成本往往只要几分钟。但它们存在的意义不在自身而在它们向每个路过这段代码的人传递的信息这段代码不重要这段代码没人维护随便改改没关系。一旦读者接收到这个信号他接下来的行为就会跟着改变——不再追求这段代码的质量不再遵守团队约定只求能跑。1.3 能跑就行是最危险的一句话我后来总结过绝大多数代码腐化起点都不是一场糟糕的架构设计而是某个人在某次排期压力下说出了那句能跑就行。这句话本身不可怕可怕的是它形成了一种局部共识在这一小片区域里标准是可以降低的。下一次有人路过这里会参照这个更低的标准继续往下写然后标准再降低一档。这就是破窗的传染机制。开篇提到的那个getData最终没被改。后来我回溯那段历史发现这个模块里几乎每个关键决策都被能跑就行筛选过一遍异常被吞掉、校验被跳过、重复代码被复制三份。每一处单独看都能找到当时的理由合在一起就是一座没有人敢碰的屎山。2. 代码仓库里的破窗全景六类高频破损点与修复成本对照2.1 我归纳的六类破窗这些年我在不同团队、不同项目里做代码评审发现破窗其实是有固定款式的。我归纳了六类最高频的每一类都有清晰的信号特征和扩散后果。破损类型典型信号单次修复成本如果不修的后果命名混乱temp、data、getXxx、a1/a22-5分钟阅读成本持续叠加误解引发新bug死代码注释掉的逻辑、无人调用的函数5-10分钟新人误读为重要逻辑不敢删错误处理缺失空catch、打印异常后继续跑10-30分钟故障被吞掉线上问题无法定位重复代码复制粘贴的相似片段30分钟-2小时改一处漏一处回归风险成倍上升临时开关硬编码参数、绕过校验的开关5-30分钟生产事故隐患且没人记得为什么加测试缺失关键路径零断言30分钟以上重构失去安全网越改越慌2.2 命名破窗的扩散路径以命名举例。一个叫做getData的函数第一次出现时也许只是偷懒五秒钟。但下一个接手的同事看到它需要花十秒猜参数含义再花十秒猜返回结构。如果他猜错了他会在调用处写一个.get(name)来防御而这个防御本身又成了新的破窗。更麻烦的是命名破窗通常会传染。当代码库里充满了data、info、flag这样的名字新来的同事会误以为这就是团队风格于是他提交的新代码也会出现result2、tmpList。我在一个模拟项目里见过最夸张的情况同一个业务实体在三个模块里有三种叫法分别是user、account、member导致跨模块沟通时反复确认你说的用户到底是哪个表。2.3 错误处理破窗是最贵的破窗在所有破窗里我最担心的是错误处理。空catch块和打印异常后继续这两类问题在开发环境几乎无感但到线上就是定时炸弹。它真正的危险在于错误被吞掉之后系统的表现是数据静默出错而不是崩溃这会让排查成本呈指数级上升。我看过一个支付相关模块的教训一段对账逻辑捕获异常后只记了一条日志就返回了成功结果。第一次出现时加代码的同事理由很充分——不能让对账流程因为单条数据异常而整体中断。但他没有做的事是把这个异常单独标记出来后续集中重试和告警。结果是在一场模拟演练里一批异常数据静默流过没有任何人察觉。这就是典型的破窗扩散第一块玻璃碎了没有修后面所有人都默认这个区域可以容忍异常。2.4 破窗清单的价值在于发现即修复要对抗破窗第一步不是制定宏大的重构计划而是让问题可见。很多团队不做这件事是因为觉得这些问题太琐碎、太小不值得写进规范。但恰恰相反破窗理论的核心就是小问题必须被当作真问题处理因为它的杀伤力不在于自身而在于它开启的传染链。我建议每个团队都拉一份属于自己的破窗清单——不用长十项以内写清楚看到什么算破窗、默认怎么修、修不动怎么上报。这份清单放在代码评审的检查项里也放在新人入职文档里。这个动作本身就能把顺手修窗户从个人美德变成团队共识。3. 破窗为什么会传染三个心理机制的拆解3.1 社会认同别人都这么写那我也可以人是社会性动物在不确定的场景下我们会下意识参照身边人的行为来做决策。写代码这件事尤其如此。当一个新人第一次提交代码时他一定会先看周围已有的代码长什么样。如果仓库里到处是TODO、注释掉的死代码、空异常捕获他会得出一个合理判断这个团队不讲究这些我照做就行。反过来如果仓库里每一段代码都干净、命名精准、异常处理清晰新人提交垃圾代码时自己都会心虚。所以破窗传染的第一层机制是社会认同或者说环境即规范。代码库本身就是团队文化最诚实的一份文档。这也是为什么我觉得与其反复强调我们要注重代码质量不如真的把每一块玻璃擦干净——环境会替你教育人。3.2 自我合理化反正这模块早晚要重写第二层机制是自我合理化。程序员是很擅长给自己找借口的物种我自己也不例外。最常见的借口是这模块迟早要重写这是历史代码不在本次需求范围内先保证上线后面再补。这些话成立吗在单个决策点上可能成立。但问题在于几乎每一次破窗产生时都有着看起来完全合理的理由。而当十个人都用合理的理由各砸一块玻璃之后这个模块就真的到了必须重写的境地——这时大家又会说你看我早就说要重写了。这是一种自我实现的预言。沉没成本在这里扮演了帮凶模块越烂我们越不愿意为它投入一点维护成本于是它继续变烂于是更找不到投入的理由。要打破这个循环唯一的方法就是在它还只是一扇窗的时候动手。3.3 认知负荷的雪崩效应第三层机制是认知负荷的雪崩。每一处破窗都在增加读者理解代码时的摩擦成本变量名要猜、死代码要跳过、重复逻辑要对比差异。当摩擦积累到一定程度程序员会本能地选择绕开而不是理解选择新写一个而不是修改现有。于是你看到的现象就是代码库里出现越来越多的平行实现——同一个功能这里有实现那里有实现两个都能跑但行为略有差异。到这一步任何一次改动都需要同时修改多处回归风险骤增大家就更不敢动于是更倾向于绕开。这是一个正反馈循环摩擦越大绕开越多绕开越多代码越碎代码越碎摩擦越大。理解这三层机制之后你就会明白为什么修复破窗这件事不能等。它不是审美洁癖而是在对抗一个会自我强化的衰退过程。你每修一块玻璃不只是修复了局部代码还在向所有路过的人重申这个代码库是有主人的。4. 童子军军规的正确打开方式一次一分半钟的顺手改良4.1 原始定义与常见误解童子军军规出自同一本经典著作原话是离开营地时要比你来的时候更干净。放到编程里就是每次提交代码时让它比你接手时好一点点。这句话听起来简单但特别容易被误解成两种极端。一种人觉得这不就是让我免费做重构吗另一种人觉得这太虚了我每天改自己的功能就好别人的破窗关我什么事。两种理解都偏离了原意。军规的核心不是奉献而是顺手——它要求的是你在本来就不得不碰的代码上做一次最低成本的改善而不是额外开一个大工程。4.2 一次标准的童子军式操作长什么样举个例子。我要修复一个用户名单查询的bug走进一个函数发现它长这样# 原代码逻辑能跑但命名和结构很糟糕 def get_data(u): if u and u.get(type) 1: r db.query(u[id]) return [item[name] for item in r if item[active]] return []我本可以只改中间一行就提交。但按童子军军规我顺手做三件事把函数名从get_data改成get_active_item_names_for_user含义一目了然。把item[active]这个过滤条件命名出来用局部变量表达意图。加一个最小化的测试锁定当前行为。改完是这样# 童子军式改良命名清晰意图明确且有了测试保护 def get_active_item_names_for_user(user): if user is None or user.get(type) ! 1: return [] active_items [item for item in db.query(user[id]) if item[active]] return [item[name] for item in active_items]整个操作大概几分钟。它没有改变函数行为没有引入新的架构没有动别人的代码但下一次有人读到这段代码时的理解成本比之前低了一大截。这就是军规的威力不是华丽的重构而是持续的、微小的、正向的复利。4.3 军规与大重构的分界线那军规和大规模重构的分界线到底在哪我的判断标准是三个问题这个改动能否在当前的需求上下文里被评审者理解改动的风险是否能被已有测试覆盖或者我能否顺手补上测试我是否在改被这个需求碰到的代码而不是漫无目的地扫荡仓库如果三个回答都是肯定的那这就是一次合格的童子军行为。如果其中有一个是否定的你大概率是在借着军规的名义夹带私货——这一点在后面的踩坑部分我会展开讲。简单说就是军规讲究的是小步、就地、即时而不是大动干戈。它是修窗户不是重新盖楼。5. 落地童子军军规时我踩过的四个坑5.1 坑一把顺手做成重写最典型的翻车方式是一个同事在修bug时顺手重构了半个模块。动机是好的他觉得既然要动这里的逻辑不如顺便把混乱的结构理清楚。结果是一次原本半小时能完成的修复变成了一场为期三天的评审拉锯上线之后还引入了两个本不该出现的回归。原因在于大规模重构需要的不是顺手而是独立的上下文充分理解当前行为、完整测试覆盖率、明确的回归策略、专门的时间窗口。把这些塞进一个紧急修复里等于在高速上边开车边换轮胎。后来我们定了条规矩凡是一次改动里超过一定量的结构变更就必须拆成独立提交并单独过评审。童子军军规允许你修窗户但禁止你在修窗户时顺便把承重墙敲了。5.2 坑二只修表面伤不管病灶另一个坑是表面洁癖。有段时间团队里刮起一股格式化风大家热衷于把缩进统一、把引号改成规范格式、给每个函数加上类型注解。这当然好但问题在于大家只处理那些看起来不顺眼的部分真正要命的破窗——错误被吞、边界不清、重复逻辑——却没人碰。为什么因为表面问题修起来快、有成就感、不容易出错而深层问题需要理解业务、需要测试、需要承担风险。人天然会逃避高认知负荷的工作。所以后来我心里有一杆秤修复破窗的优先级和它对系统的危害成正比而不是和它的修理难度成反比。空catch块永远比一行乱了缩进的代码更值得你停下脚步。5.3 坑三边界不清引发指责与摩擦童子军军规有一个隐性的社交成本你动的是别人的代码。在协作紧密的团队里这容易引发两类矛盾。一类是新人不敢动老代码。他们怕改坏了担责于是老模块里的破窗永远没人修。另一类是评审冲突A觉得某个命名是破窗B觉得那是自己的风格双方在评论里来回拉扯最后变成情绪消耗。我见过不止一次因为顺手改了一段逻辑而被原作者在评审里追问你为什么要动我这里解法不是在团队里搞道德绑架而是建立明确的规则。比如凡是修复行为必须满足行为等价不改变既有输入输出并附测试评审只在等价性和必要性上把关不讨论风格偏好。有了这条底线顺手修就从个人侵入变成了被规则保护的行为。5.4 坑四清理和需求混在同一个提交里最后一个坑是我自己反复犯过的一次提交里既改了需求逻辑又清理了死代码还重命名了三个变量。看起来高效实际上给后人挖了个大坑。最直接的问题是git bisect。当线上出现回归二分定位时这种混合提交会直接告诉你这次提交可能有嫌疑但你翻进去看根本分不清是哪个改动引入了问题。想要 revert 其中一个改动也成了不可能完成的任务。现在我的习惯是清理归清理功能归功能拆成两个提交。清理提交的信息就写chore: rename get_data to get_active_item_names_for_user, no behavior change。这样评审的人可以快速放行后续回溯也有清晰的锚点。童子军军规从来不是说让你把所有事混在一起干而是让你在留下脚印的时候顺手把营地擦干净——擦的动作和走路的动作是可以分开计的。6. 一块破窗的完整扩散复盘从被吞掉的异常到模块重写6.1 第一块碎玻璃一个被吞掉的异常某跨平台系统的订单模块里有一段对账逻辑。某天一位同事为了确保主流程不中断在一个数据转换步骤外面包了try...except捕获到任何异常后只写一行日志然后返回一个默认值继续往下走。他在注释里写了这只是一个临时处理方案后续会做告警。这块玻璃碎了。没有任何人立刻修它。6.2 扩散路径三周内的五次顺手绕开接下来的三周这个模块经历了一系列连锁事件每一次单独看都很有道理第一周另一个同事在这个异常路径外加了新逻辑因为他发现反正异常会被兜住那我在这里做点补偿处理也不会影响主流程。于是异常路径不再只是吞掉而是变成了半套业务逻辑。第二周产品提了一个需要快速上线的需求为了绕开某个数据校验开发新增了一个skip_check参数默认False只有在内部调用时传True。这个参数没有文档没有注释说明为什么存在。第三周一次联调中有人把skip_check误传成了True一批本应被拦截的数据进入了下游。因为异常被吞、校验被绕过整个链路没有任何报错直到隔天的数据对账才发现异常。从第一块玻璃到真正的生产事故只用了三周。而那第一块玻璃的修复成本当初只要十分钟。6.3 童子军干预的三个关键动作后来这个模块由一位新来的同事接手。他没有做大重构而是做了三件很朴素的事第一在处理一个工单时他先把那处try...except的行为从吞掉改成了记录并显式抛出由上层统一处理。行为变了但他顺手补了一个测试断言异常情况下会走失败分支评审顺利通过。第二他给那个skip_check参数加上了注释说明它存在的历史原因和适用场景并在调用方补了一个断言——生产环境禁止传True。第三他没有一次修完所有问题而是每次路过这个模块都修一小块并在提交信息里注明cleanup: no behavior change。七次提交之后这个模块的破窗基本清零。结果是之后一次线上异常排查定位时间从半天缩短到十分钟。不是因为有人做了多壮烈的重构而是因为每块玻璃都有人修每条路径都有测试兜底系统重新变得可被理解了。6.4 复盘真正有效的是什么复盘这个案例我觉得有效的不是任何单一动作而是三个原则的叠加修复破窗要就地解决而不是绕过绕过的每一处都必须显式记账每次改动都必须让代码比来时更干净。这里没有一条是石破天惊的洞见但组合在一起就能把一个正在腐烂的模块重新拉回正轨。我也要诚实地补充一点这块模块能救回来是因为它还没有烂到根子。如果破窗积累的时间足够长到了没有人敢动、也没有测试敢跑的程度那唯一正确的选择就是重写。但重写是最后的选项它的代价是整个团队的信心和几周乃至几个月的时间。童子军军规的意义就在于让你大概率永远不需要走到那一步。7. 把两条原则落进团队日常的三个抓手7.1 代码评审加一条顺路修理条款要把破窗理论和军规变成团队行为第一个抓手是代码评审规则。我待过的团队里效果最好的一条规则是评审者有权要求提交者把它碰过的区域内最明显的破窗一起修掉前提是有测试保护、且改动范围小。这条规则听起来有点强硬但它很有效因为它把修窗户从额外的负担变成了提交的一部分。提交者本来就动了这块代码他对这里有一定的上下文顺手修理的成本是最低的。同时为了不让人反感我们坚决反对评审者借机提出把整个文件风格都改一遍这类要求——那已经不是顺路修理而是工程事故。7.2 给团队制定一份破窗清单第二个抓手是建立属于自己团队的破窗清单。不同项目、不同语言、不同业务阶段破窗的表现形式完全不一样。前端项目里可能是组件里混着各种临时样式后端项目里可能是绕过事务的裸操作数据项目里可能是到处拼接的 SQL。我建议的做法是找一次团队会议用二十分钟让大家各自写下最近三个月里你见过最烦人的小问题然后投票排序取前十名整理成一份带修复成本预估的清单。这份清单不是摆设它要进入代码评审的检查项也要在迭代复盘时过一遍哪些破窗被修了哪些还在扩散扩散的那几个是否已经升级成了大债。有了这份清单破窗从模糊的感觉很乱变成了具体的、可讨论、可排期的对象。7.3 用技术债看板给破窗定价最后一个抓手是给破窗一个正式的位置。破窗修不掉很多时候不是大家不想修而是永远排不上期。需求永远比维护更重要这是人的本性。那我们就靠制度对抗本性。我们在迭代里固定留出一块维护容量比如每两周留出半天到一天专门处理看板上积压的破窗。每一条破窗都写清楚问题描述、影响范围、预估修复时间、是否有测试保护。然后按影响程度除以修复成本来排优先级——影响大且成本低的先修影响小但成本高的先放着直到它影响变大。这套做法还有一个隐藏收益当你把破窗放在看板上让所有人可见大家对技术债的感知就从一句抱怨变成了具体的数字化决策。这个模块有十七块破窗和这模块有点乱完全不是一个信息量。我自己在几个项目里实践下来最大的感受是破窗理论和童子军军规其实不是两套东西它们是一套动作的两面——前者让你警惕第一块玻璃后者让你成为那个顺手补上玻璃的人。它们不是道德说教而是一套降低团队认知负担的操作系统。这个操作系统不需要谁喊口号只需要每次提交前多问自己一句这段代码我走的时候是不是比我来的时候干净一点。答案可以只是干净一点但一定要是一点。
我印象很深的一次代码评审我指着一行刚提交的逻辑问这个getData到底是什么的简称写代码的同事挺坦然就是拿数据这段本来就是历史遗留能跑就行。旁边另一位同事补了一句别纠结了这文件里还有三处一模一样的重复逻辑先上线再说。结果那个模块后来变成了整个系统里最让人头疼的地方。三个月后被迫重写重写成本是最初顺手改名成本的几十倍。那时候我还没系统地想过破窗和童子军军规这两件事但那次经历让我记住了代码里的小问题从来不是小问题。这篇文章我想把这两条来自《程序员修炼之道》的原则掰开揉碎讲清楚包括它们背后的心理机制、我在代码库里见过的典型破窗长什么样、童子军军规到底怎么落地以及落地时最容易踩的坑。适合刚入行的程序员也适合正在为代码质量头疼的技术负责人。1. 破窗理论从犯罪学到代码腐化为什么小问题杀伤力最大1.1 原始理论是怎么来的上世纪80年代初两位犯罪学者在一篇研究城市治安的文章里提出了一个后来广为人知的观察如果一栋楼有几扇窗户破了而没人及时修很快就会有更多窗户被砸碎甚至引发更严重的破坏。原因不是窗户本身有多重要而是破损本身传递了一个信号——这里没人管这里的秩序已经失守。一个街区只要出现这种失守感轻微的失序就会像滚雪球一样放大。这套逻辑被引入软件工程之后成了讨论代码质量时绕不开的理论基石。我第一次读到的时候脑子里马上浮现出自己刚入行那年维护的一段老代码一个函数里有十几处被注释掉的历史逻辑缩进混乱中间还夹着一行这里先临时处理回头再改。那个回头到现在已经过了好几年。1.2 软件世界里的第一扇破窗是什么在代码库里破窗不一定是多大的技术债。它可能只是一个含义不明的变量名、一个空着的catch块、一行被注释掉的测试、一次用来绕过校验的临时开关。这些单独拎出来看都极其不起眼修复成本往往只要几分钟。但它们存在的意义不在自身而在它们向每个路过这段代码的人传递的信息这段代码不重要这段代码没人维护随便改改没关系。一旦读者接收到这个信号他接下来的行为就会跟着改变——不再追求这段代码的质量不再遵守团队约定只求能跑。1.3 能跑就行是最危险的一句话我后来总结过绝大多数代码腐化起点都不是一场糟糕的架构设计而是某个人在某次排期压力下说出了那句能跑就行。这句话本身不可怕可怕的是它形成了一种局部共识在这一小片区域里标准是可以降低的。下一次有人路过这里会参照这个更低的标准继续往下写然后标准再降低一档。这就是破窗的传染机制。开篇提到的那个getData最终没被改。后来我回溯那段历史发现这个模块里几乎每个关键决策都被能跑就行筛选过一遍异常被吞掉、校验被跳过、重复代码被复制三份。每一处单独看都能找到当时的理由合在一起就是一座没有人敢碰的屎山。2. 代码仓库里的破窗全景六类高频破损点与修复成本对照2.1 我归纳的六类破窗这些年我在不同团队、不同项目里做代码评审发现破窗其实是有固定款式的。我归纳了六类最高频的每一类都有清晰的信号特征和扩散后果。破损类型典型信号单次修复成本如果不修的后果命名混乱temp、data、getXxx、a1/a22-5分钟阅读成本持续叠加误解引发新bug死代码注释掉的逻辑、无人调用的函数5-10分钟新人误读为重要逻辑不敢删错误处理缺失空catch、打印异常后继续跑10-30分钟故障被吞掉线上问题无法定位重复代码复制粘贴的相似片段30分钟-2小时改一处漏一处回归风险成倍上升临时开关硬编码参数、绕过校验的开关5-30分钟生产事故隐患且没人记得为什么加测试缺失关键路径零断言30分钟以上重构失去安全网越改越慌2.2 命名破窗的扩散路径以命名举例。一个叫做getData的函数第一次出现时也许只是偷懒五秒钟。但下一个接手的同事看到它需要花十秒猜参数含义再花十秒猜返回结构。如果他猜错了他会在调用处写一个.get(name)来防御而这个防御本身又成了新的破窗。更麻烦的是命名破窗通常会传染。当代码库里充满了data、info、flag这样的名字新来的同事会误以为这就是团队风格于是他提交的新代码也会出现result2、tmpList。我在一个模拟项目里见过最夸张的情况同一个业务实体在三个模块里有三种叫法分别是user、account、member导致跨模块沟通时反复确认你说的用户到底是哪个表。2.3 错误处理破窗是最贵的破窗在所有破窗里我最担心的是错误处理。空catch块和打印异常后继续这两类问题在开发环境几乎无感但到线上就是定时炸弹。它真正的危险在于错误被吞掉之后系统的表现是数据静默出错而不是崩溃这会让排查成本呈指数级上升。我看过一个支付相关模块的教训一段对账逻辑捕获异常后只记了一条日志就返回了成功结果。第一次出现时加代码的同事理由很充分——不能让对账流程因为单条数据异常而整体中断。但他没有做的事是把这个异常单独标记出来后续集中重试和告警。结果是在一场模拟演练里一批异常数据静默流过没有任何人察觉。这就是典型的破窗扩散第一块玻璃碎了没有修后面所有人都默认这个区域可以容忍异常。2.4 破窗清单的价值在于发现即修复要对抗破窗第一步不是制定宏大的重构计划而是让问题可见。很多团队不做这件事是因为觉得这些问题太琐碎、太小不值得写进规范。但恰恰相反破窗理论的核心就是小问题必须被当作真问题处理因为它的杀伤力不在于自身而在于它开启的传染链。我建议每个团队都拉一份属于自己的破窗清单——不用长十项以内写清楚看到什么算破窗、默认怎么修、修不动怎么上报。这份清单放在代码评审的检查项里也放在新人入职文档里。这个动作本身就能把顺手修窗户从个人美德变成团队共识。3. 破窗为什么会传染三个心理机制的拆解3.1 社会认同别人都这么写那我也可以人是社会性动物在不确定的场景下我们会下意识参照身边人的行为来做决策。写代码这件事尤其如此。当一个新人第一次提交代码时他一定会先看周围已有的代码长什么样。如果仓库里到处是TODO、注释掉的死代码、空异常捕获他会得出一个合理判断这个团队不讲究这些我照做就行。反过来如果仓库里每一段代码都干净、命名精准、异常处理清晰新人提交垃圾代码时自己都会心虚。所以破窗传染的第一层机制是社会认同或者说环境即规范。代码库本身就是团队文化最诚实的一份文档。这也是为什么我觉得与其反复强调我们要注重代码质量不如真的把每一块玻璃擦干净——环境会替你教育人。3.2 自我合理化反正这模块早晚要重写第二层机制是自我合理化。程序员是很擅长给自己找借口的物种我自己也不例外。最常见的借口是这模块迟早要重写这是历史代码不在本次需求范围内先保证上线后面再补。这些话成立吗在单个决策点上可能成立。但问题在于几乎每一次破窗产生时都有着看起来完全合理的理由。而当十个人都用合理的理由各砸一块玻璃之后这个模块就真的到了必须重写的境地——这时大家又会说你看我早就说要重写了。这是一种自我实现的预言。沉没成本在这里扮演了帮凶模块越烂我们越不愿意为它投入一点维护成本于是它继续变烂于是更找不到投入的理由。要打破这个循环唯一的方法就是在它还只是一扇窗的时候动手。3.3 认知负荷的雪崩效应第三层机制是认知负荷的雪崩。每一处破窗都在增加读者理解代码时的摩擦成本变量名要猜、死代码要跳过、重复逻辑要对比差异。当摩擦积累到一定程度程序员会本能地选择绕开而不是理解选择新写一个而不是修改现有。于是你看到的现象就是代码库里出现越来越多的平行实现——同一个功能这里有实现那里有实现两个都能跑但行为略有差异。到这一步任何一次改动都需要同时修改多处回归风险骤增大家就更不敢动于是更倾向于绕开。这是一个正反馈循环摩擦越大绕开越多绕开越多代码越碎代码越碎摩擦越大。理解这三层机制之后你就会明白为什么修复破窗这件事不能等。它不是审美洁癖而是在对抗一个会自我强化的衰退过程。你每修一块玻璃不只是修复了局部代码还在向所有路过的人重申这个代码库是有主人的。4. 童子军军规的正确打开方式一次一分半钟的顺手改良4.1 原始定义与常见误解童子军军规出自同一本经典著作原话是离开营地时要比你来的时候更干净。放到编程里就是每次提交代码时让它比你接手时好一点点。这句话听起来简单但特别容易被误解成两种极端。一种人觉得这不就是让我免费做重构吗另一种人觉得这太虚了我每天改自己的功能就好别人的破窗关我什么事。两种理解都偏离了原意。军规的核心不是奉献而是顺手——它要求的是你在本来就不得不碰的代码上做一次最低成本的改善而不是额外开一个大工程。4.2 一次标准的童子军式操作长什么样举个例子。我要修复一个用户名单查询的bug走进一个函数发现它长这样# 原代码逻辑能跑但命名和结构很糟糕 def get_data(u): if u and u.get(type) 1: r db.query(u[id]) return [item[name] for item in r if item[active]] return []我本可以只改中间一行就提交。但按童子军军规我顺手做三件事把函数名从get_data改成get_active_item_names_for_user含义一目了然。把item[active]这个过滤条件命名出来用局部变量表达意图。加一个最小化的测试锁定当前行为。改完是这样# 童子军式改良命名清晰意图明确且有了测试保护 def get_active_item_names_for_user(user): if user is None or user.get(type) ! 1: return [] active_items [item for item in db.query(user[id]) if item[active]] return [item[name] for item in active_items]整个操作大概几分钟。它没有改变函数行为没有引入新的架构没有动别人的代码但下一次有人读到这段代码时的理解成本比之前低了一大截。这就是军规的威力不是华丽的重构而是持续的、微小的、正向的复利。4.3 军规与大重构的分界线那军规和大规模重构的分界线到底在哪我的判断标准是三个问题这个改动能否在当前的需求上下文里被评审者理解改动的风险是否能被已有测试覆盖或者我能否顺手补上测试我是否在改被这个需求碰到的代码而不是漫无目的地扫荡仓库如果三个回答都是肯定的那这就是一次合格的童子军行为。如果其中有一个是否定的你大概率是在借着军规的名义夹带私货——这一点在后面的踩坑部分我会展开讲。简单说就是军规讲究的是小步、就地、即时而不是大动干戈。它是修窗户不是重新盖楼。5. 落地童子军军规时我踩过的四个坑5.1 坑一把顺手做成重写最典型的翻车方式是一个同事在修bug时顺手重构了半个模块。动机是好的他觉得既然要动这里的逻辑不如顺便把混乱的结构理清楚。结果是一次原本半小时能完成的修复变成了一场为期三天的评审拉锯上线之后还引入了两个本不该出现的回归。原因在于大规模重构需要的不是顺手而是独立的上下文充分理解当前行为、完整测试覆盖率、明确的回归策略、专门的时间窗口。把这些塞进一个紧急修复里等于在高速上边开车边换轮胎。后来我们定了条规矩凡是一次改动里超过一定量的结构变更就必须拆成独立提交并单独过评审。童子军军规允许你修窗户但禁止你在修窗户时顺便把承重墙敲了。5.2 坑二只修表面伤不管病灶另一个坑是表面洁癖。有段时间团队里刮起一股格式化风大家热衷于把缩进统一、把引号改成规范格式、给每个函数加上类型注解。这当然好但问题在于大家只处理那些看起来不顺眼的部分真正要命的破窗——错误被吞、边界不清、重复逻辑——却没人碰。为什么因为表面问题修起来快、有成就感、不容易出错而深层问题需要理解业务、需要测试、需要承担风险。人天然会逃避高认知负荷的工作。所以后来我心里有一杆秤修复破窗的优先级和它对系统的危害成正比而不是和它的修理难度成反比。空catch块永远比一行乱了缩进的代码更值得你停下脚步。5.3 坑三边界不清引发指责与摩擦童子军军规有一个隐性的社交成本你动的是别人的代码。在协作紧密的团队里这容易引发两类矛盾。一类是新人不敢动老代码。他们怕改坏了担责于是老模块里的破窗永远没人修。另一类是评审冲突A觉得某个命名是破窗B觉得那是自己的风格双方在评论里来回拉扯最后变成情绪消耗。我见过不止一次因为顺手改了一段逻辑而被原作者在评审里追问你为什么要动我这里解法不是在团队里搞道德绑架而是建立明确的规则。比如凡是修复行为必须满足行为等价不改变既有输入输出并附测试评审只在等价性和必要性上把关不讨论风格偏好。有了这条底线顺手修就从个人侵入变成了被规则保护的行为。5.4 坑四清理和需求混在同一个提交里最后一个坑是我自己反复犯过的一次提交里既改了需求逻辑又清理了死代码还重命名了三个变量。看起来高效实际上给后人挖了个大坑。最直接的问题是git bisect。当线上出现回归二分定位时这种混合提交会直接告诉你这次提交可能有嫌疑但你翻进去看根本分不清是哪个改动引入了问题。想要 revert 其中一个改动也成了不可能完成的任务。现在我的习惯是清理归清理功能归功能拆成两个提交。清理提交的信息就写chore: rename get_data to get_active_item_names_for_user, no behavior change。这样评审的人可以快速放行后续回溯也有清晰的锚点。童子军军规从来不是说让你把所有事混在一起干而是让你在留下脚印的时候顺手把营地擦干净——擦的动作和走路的动作是可以分开计的。6. 一块破窗的完整扩散复盘从被吞掉的异常到模块重写6.1 第一块碎玻璃一个被吞掉的异常某跨平台系统的订单模块里有一段对账逻辑。某天一位同事为了确保主流程不中断在一个数据转换步骤外面包了try...except捕获到任何异常后只写一行日志然后返回一个默认值继续往下走。他在注释里写了这只是一个临时处理方案后续会做告警。这块玻璃碎了。没有任何人立刻修它。6.2 扩散路径三周内的五次顺手绕开接下来的三周这个模块经历了一系列连锁事件每一次单独看都很有道理第一周另一个同事在这个异常路径外加了新逻辑因为他发现反正异常会被兜住那我在这里做点补偿处理也不会影响主流程。于是异常路径不再只是吞掉而是变成了半套业务逻辑。第二周产品提了一个需要快速上线的需求为了绕开某个数据校验开发新增了一个skip_check参数默认False只有在内部调用时传True。这个参数没有文档没有注释说明为什么存在。第三周一次联调中有人把skip_check误传成了True一批本应被拦截的数据进入了下游。因为异常被吞、校验被绕过整个链路没有任何报错直到隔天的数据对账才发现异常。从第一块玻璃到真正的生产事故只用了三周。而那第一块玻璃的修复成本当初只要十分钟。6.3 童子军干预的三个关键动作后来这个模块由一位新来的同事接手。他没有做大重构而是做了三件很朴素的事第一在处理一个工单时他先把那处try...except的行为从吞掉改成了记录并显式抛出由上层统一处理。行为变了但他顺手补了一个测试断言异常情况下会走失败分支评审顺利通过。第二他给那个skip_check参数加上了注释说明它存在的历史原因和适用场景并在调用方补了一个断言——生产环境禁止传True。第三他没有一次修完所有问题而是每次路过这个模块都修一小块并在提交信息里注明cleanup: no behavior change。七次提交之后这个模块的破窗基本清零。结果是之后一次线上异常排查定位时间从半天缩短到十分钟。不是因为有人做了多壮烈的重构而是因为每块玻璃都有人修每条路径都有测试兜底系统重新变得可被理解了。6.4 复盘真正有效的是什么复盘这个案例我觉得有效的不是任何单一动作而是三个原则的叠加修复破窗要就地解决而不是绕过绕过的每一处都必须显式记账每次改动都必须让代码比来时更干净。这里没有一条是石破天惊的洞见但组合在一起就能把一个正在腐烂的模块重新拉回正轨。我也要诚实地补充一点这块模块能救回来是因为它还没有烂到根子。如果破窗积累的时间足够长到了没有人敢动、也没有测试敢跑的程度那唯一正确的选择就是重写。但重写是最后的选项它的代价是整个团队的信心和几周乃至几个月的时间。童子军军规的意义就在于让你大概率永远不需要走到那一步。7. 把两条原则落进团队日常的三个抓手7.1 代码评审加一条顺路修理条款要把破窗理论和军规变成团队行为第一个抓手是代码评审规则。我待过的团队里效果最好的一条规则是评审者有权要求提交者把它碰过的区域内最明显的破窗一起修掉前提是有测试保护、且改动范围小。这条规则听起来有点强硬但它很有效因为它把修窗户从额外的负担变成了提交的一部分。提交者本来就动了这块代码他对这里有一定的上下文顺手修理的成本是最低的。同时为了不让人反感我们坚决反对评审者借机提出把整个文件风格都改一遍这类要求——那已经不是顺路修理而是工程事故。7.2 给团队制定一份破窗清单第二个抓手是建立属于自己团队的破窗清单。不同项目、不同语言、不同业务阶段破窗的表现形式完全不一样。前端项目里可能是组件里混着各种临时样式后端项目里可能是绕过事务的裸操作数据项目里可能是到处拼接的 SQL。我建议的做法是找一次团队会议用二十分钟让大家各自写下最近三个月里你见过最烦人的小问题然后投票排序取前十名整理成一份带修复成本预估的清单。这份清单不是摆设它要进入代码评审的检查项也要在迭代复盘时过一遍哪些破窗被修了哪些还在扩散扩散的那几个是否已经升级成了大债。有了这份清单破窗从模糊的感觉很乱变成了具体的、可讨论、可排期的对象。7.3 用技术债看板给破窗定价最后一个抓手是给破窗一个正式的位置。破窗修不掉很多时候不是大家不想修而是永远排不上期。需求永远比维护更重要这是人的本性。那我们就靠制度对抗本性。我们在迭代里固定留出一块维护容量比如每两周留出半天到一天专门处理看板上积压的破窗。每一条破窗都写清楚问题描述、影响范围、预估修复时间、是否有测试保护。然后按影响程度除以修复成本来排优先级——影响大且成本低的先修影响小但成本高的先放着直到它影响变大。这套做法还有一个隐藏收益当你把破窗放在看板上让所有人可见大家对技术债的感知就从一句抱怨变成了具体的数字化决策。这个模块有十七块破窗和这模块有点乱完全不是一个信息量。我自己在几个项目里实践下来最大的感受是破窗理论和童子军军规其实不是两套东西它们是一套动作的两面——前者让你警惕第一块玻璃后者让你成为那个顺手补上玻璃的人。它们不是道德说教而是一套降低团队认知负担的操作系统。这个操作系统不需要谁喊口号只需要每次提交前多问自己一句这段代码我走的时候是不是比我来的时候干净一点。答案可以只是干净一点但一定要是一点。
到O(n)的思维转换)
