1. 屎山代码到底是什么1.1 屎山不是骂人是一种客观现象先把这个词说清楚。我在这个行业待了十多年接手过的项目没有二十个也有十五个几乎每个项目里都有那么一段代码打开文件之后第一反应是“这谁写的”git blame 查完之后发现是自己三个月前写的。所谓“屎山代码”指的就是那种结构混乱、命名随意、耦合严重、没有测试、改动一处就崩三处最终累积到谁都不敢碰的代码库。它不是某个人的能力问题而是软件工程里一种几乎必然出现的客观现象像房间里堆了太久没收拾的杂物今天放一件明天放一件等你想找一件衣服的时候整个衣柜已经塌了。这个说法最早来自程序员圈子里的自嘲原话大概是“每个屎山代码都是一个程序员用脚写出来的堆砌体”后来演化成一种行业黑话。它听起来很冒犯实际上大家心里都有数这东西不是一天形成的也不是一个人造成的它是时间、业务压力、人员流动、需求变更共同作用的结果。真正可怕的地方在于代码一旦开始“发臭”修改成本会呈指数级上升新功能没人敢加旧 bug 没人敢动最后整个项目变成一座巨大的“玻璃城堡”你看着它光鲜亮丽实际上水平方向轻轻一碰就碎。我不是在这里讲一个纯吐槽的话题。恰恰相反我想说的是屎山代码存在的意义不是让你骂它、躲它、抱怨它而是逼着你去理解一个核心问题——代码为什么变烂变烂之后有没有救怎么救这才是程序员从“能写代码”走向“会写代码”的分水岭也是标题里所说的“最高修养”的真正含义。1.2 屎山是怎么堆起来的要说清楚怎么治理先得说清楚怎么形成的。我见过太多团队一边骂屎山一边亲手往山上添砖加瓦。形成路径无非下面几种第一需求永远在变代码永远在补。业务方今天说“这里加一个开关”明天说“这个开关改成三态”后天说“还是两态但要兼容老数据”。每改一次都是打补丁补丁上面叠加补丁时间一久没人分得清哪层补丁是干嘛的。我印象很深的一个案例一个用户登录模块前后经过六七个人接手每个人都在入口处加了自己的判断逻辑最后那个方法有四百多行光是 if 嵌套就嵌了八层里面还有三处被注释掉的旧代码注释的话是“这段先别删可能还有用”。你看连“可能有用的垃圾”都舍不得扔这就是屎山的建材。第二性能优化和临时方案长期驻留。线上出了紧急故障先加个缓存、加个开关、加个重试机制先顶上说“后面再优化”。这个“后面”通常永远不会来或者来了的时候已经没人敢动它了因为大家都忘了这个临时方案到底在兜什么底。这种代码最坑人它有着“看起来在干活”的合法身份一旦乱动线上立刻告警。第三交付压力挤压了重构空间。版本排期排得死死的测试时间压缩到极限产品经理在背后盯着你你不可能在迭代中停下来对老模块做一次彻底的重构。每次评审技术负责人心里都清楚这块已经烂透了但嘴上只能说“这次先不动等有专门排期再说”。专门排期在这个行业里专门给技术债排期的团队少之又少。第四团队没有统一的代码规范和评审机制。有人喜欢用缩写变量名有人喜欢写超大函数有人习惯在 Controller 里堆业务逻辑有人把工具类写得到处都是静态方法。每个人的代码单独看都说得过去合在一起就是一座巴别塔读别人的代码比读外语还难。这几条叠加在一起屎山就算正式落成了。落成之后它还会自己生长因为每个新来的程序员都会遵循“在屎山旁边新增而不是改动”的生存法则山头越堆越高直到高到某天连 root 权限都挖不动为止。有一点必须承认屎山是系统性问题的产物不是某个人的道德问题。我们讨论治理的时候不能抱着“我要当英雄拯救这个破烂项目”的心态而要像一个医生面对一个长期患病的人——先检查再诊断然后制定疗程最后调整生活习惯防止复发。这才是一个成熟程序员该有的视角。2. 重构之前先想清楚这些事2.1 先判断这座山值不值得挖面对屎山第一个决策不是“怎么重构”而是“该不该重构”。这不是废话这是很多人付了学费才学到的教训。我见过一个团队花了两周时间对一套老旧的报表系统做重构重构到一半发现这套系统下个月就要被新的 SaaS 产品替换掉两周的投入直接打了水漂。重构是成本很高的操作你得先确认这座山下面埋的是真金还是烂泥。怎么判断我的经验是看三点第一这个模块还有没有被频繁迭代。如果业务方每个月都要在上面加需求那说明它是核心资产值得投入资源清理。如果它已经进入“冻结期”只修 bug 不新增那最好的策略是“维持现状 写好边界文档”别去动它。第二代码里有没有可以复用的业务逻辑。有时候模块虽然烂但里面的规则、校验、算法是多年沉淀下来的这些信息比代码本身值钱。重构的真正价值在于把这些业务逻辑从混乱的代码里提取出来变成清晰、可测试的模块。第三团队有没有足够的余量去消化重构带来的风险。重构期间不会少功能但测试压力、回归压力、联调压力会明显增加如果团队本身已经处于高压状态强行重构等于给自己埋雷。这里还要提醒一个常见的误区认为重写比重构容易。很多程序员一看到屎山代码第一反应是“推倒重来”觉得用新的框架、新的设计写一套干净系统比在老代码里挣扎痛快多了。这个想法对所有老项目都是危险的。为什么因为老系统里每一行看似愚蠢的代码背后可能都对应着一个线上 bug 的教训、一个你根本不知道的业务规则。你重写的时候以为自己写得很干净实际上把多年积累的边界情况全部丢光了。重写的项目大概率会在上线半年后再次变成一座新的屎山而且连旧人都不一定能帮你填坑。所以我的建议是先给这个模块做个“业务价值和维护成本”的评估再决定是“重构”“重写”还是“冷冻”。评估的方式很简单拉出这个模块近三个月的 commit 记录、issue 数量、线上故障记录数一数它占你维护时间的百分比跟它的业务价值做个对比。高价值高熵的部分优先重构低价值高熵的部分冷冻甚至删除高价值低熵的部分别碰低价值低熵的部分随缘。2.2 重构策略选择绞杀者 vs 修缮者确认值得干之后第二个问题来了用哪种方式干。行业里有两套主流思路一种叫“绞杀者模式”Strangler Pattern一种可以叫“渐进式修缮”。绞杀者模式很适合那种“模块边界相对清晰但内部已经烂穿”的系统。思路特别像老城区改造在老楼旁边先建一栋新楼把功能一个一个搬进去每搬完一个就在老楼上砌一堵封死的墙最后老楼变成一座空壳拆除即可。好处是每一步都有明确的功能对齐风险可控而且搬过去之后老代码还在可以随时回滚。代价是要额外维护一长段时间的双轨运行数据同步和双写逻辑本身会带来新复杂度。渐进式修缮则更适合那种“模块之间纠缠不清没法独立抽走”的系统。做法不是替换而是在原地做大扫除先画清楚调用关系再把重复逻辑抽取出来逐步消除全局状态和隐式依赖每次改动只保持系统可编译、可测试、可部署。节奏慢但是每一步的震动面小比较适合团队人手不足、业务不能停的场景。我个人的倾向是对于大多数中大型业务系统混合策略是最现实的。先找出那些“看起来可以独立成接口”的部分用绞杀者的思路逐步迁移出去对内部实在纠缠不清的公用地带则用修缮者的方式做局部清理。这两套打法不是单选题真正的难点在于判断哪些模块“看起来可以独立”和哪些“实际纠缠不清”判断的标准还是前面说的调用关系、数据依赖和变更频率。顺带一说很多团队在重构之前喜欢先升级框架版本比如从 Spring 4 升到 Spring Boot 3。我见过的成功案例里这个顺序通常是反的先把代码结构理清楚了再考虑换框架。框架只是承载业务的地基地基之上的钢筋水泥如果已经锈朽换地基也救不了整栋楼。反过来结构理顺之后你发现很多框架升级的阻力自然消失了——因为耦合点变少替换面变窄升级风险更低。2.3 没有测试的重构等于高空走钢丝这是整个重构行动里最重要的一条我必须单独拿出来讲。任何重构无论你用绞杀者还是修缮者都需要一张安全网。没有测试保护的重构本质上不是重构是赌博。很多老项目的痛苦正是在此代码烂到没人愿意补测试但没有测试又没人敢改代码于是形成了“先有鸡还是先有蛋”的死循环。我当年在接手一个支付对账模块的时候就撞上过这道墙那段代码里有一处汇率换算的逻辑异常分支就有十几种我打开后完全不敢动因为没有一条测试告诉我动了之后什么会坏。破局的思路有两条。第一条先给“痛点区域”补特征测试。特征测试不是验证代码逻辑对不对而是把当前代码的行为“固化”下来——输入什么、输出什么、异常路径怎么走全部变成断言。它的价值不在于保证正确性而在于保证“你改完之后行为和改之前一样”。如果行为本来就有 bug没关系先固化它重构完成后再单独讨论要不要修正。这样你就获得了一张安全网网里可能有个洞原来的 bug但至少你知道自己不会一脚踩空掉下去。第二条给关键路径写集成测试。单元测试在重构期间会因为类被拆分、方法被移动而频繁失效这是正常的别慌。集成测试的粒度大一点针对的是“走通一个重要业务场景”而不是某个具体实现比如“用户下单后库存扣减成功”“对账文件解析后生成差异记录”。这些场景集成测试在重构期间能够持续稳定运行给你的每次改动提供即时反馈。我见过不少团队跳过这一步直接开干结果就是中途爆出一堆回归缺陷然后停下来花两倍时间去修最后总结陈词“重构失败了”。这根本不是重构失败而是出击之前没系安全带。写测试确实枯燥、耗时、吃力但它是整个工程里性价比最高的投入。没有一个有经验的人会告诉你“测试可以后面再补”说这种话的基本都是还没被线上事故教育过的新手。3. 实操从定位坏味道到拆解重构路径3.1 第一步读代码画那张没人画过的地图有人可能觉得很奇怪程序员每天都在读代码怎么“读代码”还需要单独拿出来说但现实就是这么讽刺大多数人在老代码里干活的方式是搜一个关键词定位到方法改完保存提交完事。至于这个方法被谁调用、调用了哪些外部服务、异常怎么传播、数据怎么流转一概不知道。要真正治理屎山第一件正事不是改代码而是把这个区域的“地图”画出来。我自己的习惯是用思维导图工具从入口方法开始一层层往下展开Controller 的哪个接口、调用了哪个 Service、Service 里调了哪些 DAO 和第三方 API、每个方法里有哪些分支和异常处理。画的过程中你会直觉地发现一些问题比如某个 Service 里塞了三层业务逻辑某个工具类被十几个模块共用某个接口同时身兼数据和视图两类职责。还有一件事顺带做掉把“断头路”找出来。所谓断头路就是没人再调用的堆砌代码。这种代码在屎山里特别多旧版本留下的兼容逻辑某个需求上线后已经废弃的调用链它们不仅增加阅读负担还会给重构误判“依赖关系”制造干扰。你看到很多地方都在引用某个方法以为它很重要仔细追查后才发现所有引用点都已经死了。断头路直接在重构时删掉它们就是屎山里毒性最大的腐肉。地图画完之后你至少应该能回答三个问题这套代码到底分几层哪些层是稳定核心、哪些层是临时拼凑如果要抽掉某一个模块它会牵扯到多大的范围有了这些答案重构策略才能从概念变成一张具体的施工图。3.2 第二步把你看到的坏味道分门别类画完地图之后接下来的工作不是立刻动手改而是把你要处理的“坏味道”整理成清单。这里我借用经典软件工程书里的坏味道分类框架但结合我自己在屎山里的实操经验做了点取舍第一类是命名与结构问题。变量命名是a、temp、data2这种函数取名doSomething、handleData类名直接叫Util1、Manager2。这类问题最好修也最不影响运行时行为改命名的风险极低适合作为新手练习重构的第一步。第二类是重复代码。同一个业务规则在三四个地方各写一遍只是变量名略不一样。遇到这种问题别急着合并先看清楚这几处是不是真的逻辑一致。我踩过坑两段看起来一样的代码实际处理边界天差地别强行合并不是减少重复而是把多个异常分支捏成了一个没法覆盖的整体。正确的合并姿势是先把各处的行为测试都补上再提取公共方法。第三类是过长函数和过深嵌套。判断的标准很简单一个函数超过四十行就值得警惕超过一百行基本上是病态的。嵌套超过三层的 if 再加上 for 循环基本上就是在考验读者的脑容量了。处理方式不是无脑拆而是看有没有“被注释分隔出来的段落”——那种段落往往就是可以抽出来变成独立方法的功能块。第四类是数据泥团和依恋情结。数据泥团指的是三个字段永远是打包在一起传递的比如userId userType userLevel那就应该把它们封装成UserContext。依恋情结指的是一段逻辑主要访问别的类的数据而不是自己类的数据那说明这段逻辑放错位置了。这两类属于结构性坏味道处理的回报最大但改动范围也大要放到测试完善之后再做。把坏味道分好类之后排一个优先级命名和重复代码这些“表层问题”先处理因为它们容易、安全、能增强团队信心数据泥团和过深嵌套这些“深层问题”再逐层推进每一步都要有测试兜底。3.3 第三步用“编织替换法”逐层拆解关键模块我在这里分享一个我自己反复使用的重构手法我叫它“编织替换法”业界也有类似说法叫 branch by abstraction。核心思想是不直接改动旧代码的实现细节而是先在旧的调用链条旁边织入一层新的抽象让调用方不再直接依赖旧的实现而是依赖这层新抽象然后在新抽象的后面偷偷替换实现最后把旧的实现整个摘除。拿我之前重构过一个用户积分模块来举例。旧的代码里积分计算逻辑散落在五六个地方有的在 Service 里算有的在 MQ 消费端里算还有一处直接在 SQL 里用 case when 算。这种结构下你想改积分规则根本不敢动因为你不知道改哪一处才算数。传统重构思路会想“先把这五六处合并成一个服务”这个目标本身没错但它涉及面太大改起来会让人心慌。编织替换法会把这件事拆成三个步骤第一步写一个PointsCalculator接口定义清楚“输入什么、输出什么”然后在旧代码每个计算点旁边都插一句调用让新旧逻辑并行跑但对外仍然返回旧逻辑的结果。这一步不改任何业务行为只加日志和埋点上线观察几天让新逻辑在暗处“见习”一段时间。第二步通过对比日志里新旧逻辑的输出差异把不一致的分支理清楚。有些差异是旧逻辑本身有 bug有些差异是新逻辑理解错了规则。每修正一个分支灰度放量一部分流量直到新逻辑输出和旧逻辑在正常场景下完全对齐。第三步切换开关对外直接返回新逻辑的结果老逻辑代码下线删掉。此时老代码中那五六处散落的计算逻辑已经被新接口收拢成了一个点以后改规则只需要维护PointsCalculator这一个实现类。这个方法的精妙之处在于每一步都是可回滚、可灰度、可观察的。你不必在某一天夜里通宵上线一个大重构版本而是通过一次次的迭代把重构的“大片”切成“小片”每片都在生产环境实测验证过。它比“改完本地自测 OK 然后一把梭上线”的做法稳得多也是我在多年重构实践中觉得最值得推广的思路。3.4 暗藏的大坑全局状态、隐式依赖和老框架即使策略、测试、拆解路径都到位屎山重构中还是会遇到三个特别容易翻车的暗坑。第一个是全局状态。老代码里经常会看到静态类持有各种缓存、配置、连接池看起来像是共享数据实际上它们是队友之间“暗通款曲”的通道。你重构一个方法时发现它没有任何参数来源行为却天差地别那多半就是读了某个静态字段而且这个字段在别的地方被偷偷改过。处理的方式是把静态状态改为实例化注入并先给每个写入点加上日志找到到底是谁在什么时机改了它。第二个是隐式依赖。现代框架的依赖注入看起来把耦合降得很低但大家在重构时经常会忽略那些隐式依赖ApplicationContext 里按类型取 Bean 的、AOP 切面上拦截某个方法名的、注解驱动的动态代理的。这些逻辑不看配置根本发现不了等你在代码里把一个类改名、把方法参数挪动位置测试全绿一上线却发现某些切面不在生效这时候再排查就要花掉大量时间。我的建议是重构之前扫一遍项目里的Aspect类、BeanPostProcessor实现以及自定义注解把这些“钩子”先列出来改代码时随时回头检查影响面。第三个是老框架的隐性约定。老项目往往还在用多年以前的技术栈很多“约定”写在了框架版本的行为里。比如一个旧版 ORM 会自动把下划线字段名映射成驼峰属性但新版不会一个旧版 JSON 库默认包含 null 字段新版默认排除。这些差异平时不触发重构期间代码一动、调用链一变就冒出来了。应对的办法很土但有效保持老框架版本不动直到代码结构层面重构完成再单独开一个“框架升级”的专项任务分步升级、逐步验证。4. 重构之后怎么防止它再次变成屎山4.1 把“代码规范”从文档变成机制很多团队都有代码规范文档但它通常躺在 wiki 的某个角落起到的最大作用是“评审时被拿出来甩在对方脸上”。单纯靠文档约束行为效果几乎为零。真正能防止代码重新变烂的是让规范内嵌进工具链和流程里。第一步用格式化工具消除无谓的风格之争。统一的代码格式化、自动导入整理、统一的目录结构和命名前缀规则这些全部交给工具去执行。没有工具强制的地方可以说是“自由”但只要有五个人以上的团队自由度越高、烂得越快。第二步把核心约束写进 CI 检查。圈复杂度超过阈值的提交直接 failed方法长度超过限制直接 failed新代码没有对应测试直接 failed。这些规则听起来有点教条但它们是防止后人悄悄往山上添砖加瓦的护栏。不一定需要复杂到引入专门的质量平台GitLab CI 加一个 lint 脚本加一个测试覆盖率报告就能起到效果。第三步代码评审要从“能不能合”——改成“这样改会不会让后人骂娘”。评审时多问三个问题这段逻辑有没有测试命名是不是即使明天忘掉上下文也能看懂它有没有把不该耦合的东西耦合在一起我一直觉得代码评审最重要的价值不是抓 bug而是作为一种“污染防线”让每一坨新进来的代码都得经过人工的质量门禁哪怕只是形式化的走一遍也会在潜意识上提醒每个人“这里是有标准的”。4.2 用技术债看板让债务不再裸奔技术债这个概念讲了太多年但真正把它当作债务来管理的团队不多。现实里最常见的状态是知道有债但不记账、不付利息、不规划还款等爆雷了再救火。我一直提倡团队建一个“技术债看板”把每一笔债记录成一张卡片写清楚四件事这个债在哪个模块、代价是什么每次改动多花多少时间、触发条件是什么什么情况下会恶化、建议的还款方案是什么重构成什么样算还清。看板不需要很重一张轻量级的在线表格就够了。关键是它的运转机制每次迭代排期时从看板上拿出两三个技术债条目塞进这个迭代里作为常规任务处理。不需要专门砍掉业务需求来做纯重构只需要在需求迭代中“顺路”逐步消化。比如你这次要改用户列表接口那就顺手把这个接口对应模块里的一条债还掉这叫“碰过的代码就把它变得更干净”原则也被称为“营地法则”——你离开营地的时候至少要比来的时候干净一点。我个人特别认同这个原则由这个原则引申出一个可落地的团队动作每一段你改动过的代码区域都必须比动手前整洁一点。可以是一次重命名、一段抽取、一个多余参数删除、一处死代码清理。它不需要立竿见影地消除整个屎山但它保证山体不会继续向上增长。很多人问“每天这么忙哪有时间重构”我的回答是不是让你抽时间做专项重构而是要你顺手把碰过的地方弄干净这本质上是不同的事情。4.3 测试覆盖率卡住回归文档只写规律不留流水账代码维护里有一对经典矛盾不写文档后人看不懂写了文档很快就过期。我的经验是文档的核心作用不是记录“今天做了什么”而是记录“为什么这么做”和“规则是什么”。流水账式的更新记录没有意义过期之后还会给后人挖坑。真正值得留在文档里的内容只有两类域模型和业务术语的解释、以及那些“看起来不该这么做但必须这么做”的约束说明。然后说测试。重构完成的标准不只是功能回归通过还包括测试覆盖到位。不过我要泼一盆冷水覆盖率数字不是越高越好盲目追求数字往往会让团队产出大量垃圾测试这些测试测的是实现细节一旦重构它们反而变成最碍事的僵尸代码。好的测试应该测行为而非实现测公开的接口契约而非内部的私有方法。如果你重构之后发现自己大量测试需要跟着改那不是重构速度太快而是当时把测试跟实现绑得太紧了。补测试要优先补哪些三块核心业务规则、复杂分支逻辑、曾经发生过线上故障的场景。这三块补上之后你至少可以保证后续维护不会“旧病复发”而无人察觉。至于搜索引擎能搜到答案的工具类、框架封装方法之类的东西测试优先级可以放得很低因为它们变化少、风险小、价值也不高。5. 所谓程序员修养具体体现在哪些地方5.1 面对历史代码时的心态管理我在前面已经说了一堆方法论的东西现在想聊一点方向性的、关于人的东西。刚开始工作的那几年我一度认为自己是个“完美主义程序员”眼里揉不得沙子看到谁的代码写得不好心里会立刻给对方打个标签。后来我认真想一想这种态度其实很廉价——它只会在团队里制造对立让人际关系变得紧张而代码该烂还是继续烂。真正的修养首先是承认历史代码的合理性。它之所以长成这个样子是因为它经历了无数个需求变更、无数个紧急提交、无数个前人带着不同的理解在上面做出不同的取舍。你拿着今天的视野去批判昨天的决策本质上是不公平的。你不能要求那些在三年前、五年前、八年前的夜晚为了上线而写出这段代码的人预见到今天你要重构它的所有可能性。他们只是在当时的信息和条件下做出了最合适的选择。我经常跟团队里的小朋友说代码是别人写的时候留下的“签名”也是他们认知的化石。你阅读它的时候不要急着否定先试着理解作者当时的处境。为什么要这里加一个判断为什么这个参数要设计成这样大概率背后都有一段你现在看不到的故事。理解了之后你再来决定是保留、修正还是推翻。带着同理心去读历史代码跟带着猎巫心态去读历史代码解读出来的内容完全不是同一个东西。5.2 不留屎山的人把“后来者”放在心里那么修养的正面是什么我的理解是它本质上是一种“为后来者考虑”的自觉。在这个行业里项目是流动的团队是变化的代码的生命周期远远长于任何一个人的任期。你今天写的每一行代码明天就可能被另一个你根本不认识的人阅读、修改、维护。你留下的是清晰还是混乱是完整还是残破直接决定了那个人的效率、情绪、以及他是否也会继续往屎山上添砖。所以“最高修养”并不玄妙它落实到操作层面其实就是几个朴素的动作命名时多想几秒钟想想一个不认识上下文的人看到这个名字能不能猜到意图写函数时多问自己一句这个逻辑能不能短一点、纯粹一点提交代码时回头看一眼有没有把调试日志、死代码、临时的硬编码留在里面评审别人的 PR 时不只是说“LGTM”而是真的为他把边界情况考虑一下发现异常时补一个注释说明为什么会有这段异常逻辑别用“此处必有妖”这种话留悬念。这些都是小事但它们加起来就构成了一种专业气质就像医生做手术前后要洗手换衣、厨师上灶前后要清点刀具一样。别人不一定看得见但它决定了你的作品最终是值得被后人尊重还是变成一个让后人痛苦的负担。我在实际工作里见过一些“代码洁癖”很重的人他们会被同事吐槽“改个东西怎么这么慢”“这个变量名纠结半天”。说实话我年轻的时候也被人这么吐槽过。但多年以后回头看那些“纠结”的时间并没有浪费它们兑换成了之后几周、几个月甚至几年的低维护成本。那个因为一时图快、随便命名、把逻辑塞一团乱麻的人当下看起来是快手半年后他自己打开这段代码也要骂一句“这写的什么玩意”。写得干净不是为了讨好谁是为了给未来的自己和未来的同事降低认知负担。5.3 从清理一座山到建立一套生态这篇文章从屎山代码讲起最后我想把它落在一个更高的层面上。一个程序员如果只在意自己手头写得干净那他最多算一个优秀的“写作个体”但如果他能够意识到代码质量是一项需要从个人习惯、团队机制、工程工具多维度同时发力的生态问题他才真正拥有了“架构思维”和“工程素养”。清理一座屎山一次重构救不了一个团队。你重构完支付模块下个季度又会有人在新的订单模块堆出新屎山。靠谱的做法是把这次重构当成一个建立“生态”的契机借此建立测试规范、引入质量检查、定义技术债看板、培养团队的代码审美、形成敬畏历史代码的团队文化。一旦这套生态运转起来新引入的脏代码会自我抑制已有屎山会被慢慢消化代码库才会真正走向“越改越好”的正向循环。这也是我认为程序员这份工作最有意思的地方它不只是跟编译器对话不只是在跟需求方讨价还价它还在跟时间对话、跟后来者对话、跟行业的专业标准对话。你今天做的每一个微小的干净动作都会通过代码这个介质流传下去影响一个陌生人几周后的工作体验。这种影响看不见摸不着但它真实存在。无论你正在维护一个年久失修的旧系统还是在新建一个从零起步的绿地项目我都建议你把“别让后人骂娘”当成一条隐性职业守则。你不需要成为一个感动自己式的浪漫主义者只要在每天写代码的时候偶尔想一想那个三个月后会接手你的代码、半夜被线上告警吵醒的人——他值得一份清晰、体面、能看懂的东西。他的修养其实就是你的修养。