程序员成长 on 方糖猫Blog

知止有定，能择其要

Wed, 08 Jul 2026 12:40:00 +0800

知止有定，能择其要

知止有定，能择其要。

内功篇《此心不息，万物常新》把心转起来——看见、提问、理解、行动、反馈、沉淀，让认知与行动连成正反馈。但"能更新自己"只是前半场，后半场是：把更新能力投向哪里，怎么把能力变成资产。

还有一个在这两者之前的问题——往哪走：方向怎么选，是选择篇《见几而作，知时而动》的事。

外功篇管这个。把力气变成被市场承认的资产要过五关：选资产（练什么）→ 看定价（这张地图今天值多少钱）→ 选环境（在哪练）→ 加杠杆（怎么让积累利滚利）→ 对账（怎么证明真的变强了）。本文前五节一关一节。五关不是并列清单，是一条因果链：不选定资产，定价无从谈起；不看定价，力气可能投在正在贬值的东西上；环境错了，练得再狠增值也慢；不加输出杠杆，资产只有你自己知道；不对账，前面全是自我感觉。后三节不回答新问题：第六节管落地，第七节管边界，第八节管次第。

读这篇不需要先读内功篇，只需要承认一个事实：市场为结果定价，不为感觉定价。 一个人可以越来越会思考、越来越会复盘，同时依然是一个"更会思考的初级程序员"——会思考的初级和有竞争力的高级之间，隔的不是心智，是资产。

读过内功篇的人，这里该起一个疑问：内功教你无所住，不执著于任何结论；这篇却教你拼命积累资产、一环扣一环给自己定价——不矛盾吗？不矛盾。答案是一个二分法，本篇从头用到尾：把任何结果拆成"力"（可控）与"命"（不可控），只为前者消耗能量。地图、路线、输出、仪表盘，全是力；市场怎么出价、周期怎么转动、年龄偏见怎么来，是命。修力的目的不是把价格推高，是把命的边界往外推——资产越厚，周期、裁员、偏见能伤到你的地方越少。记住这个二分法再往下读：所有仪表盘测的都是力；命的那一半，第七节还给你。

先把全文的结论摆在前面：能力要变成市场承认的资产，得依次过五关——选资产、看定价、选环境、加杠杆、对账；五环都走完还推不动的那部分，是"命"的那一半，不是失败。 下面逐关展开。

先划一条边界：这篇只讨论职业竞争力——可积累、可复用、可交换的现实资产，不讨论人的全部价值。 好奇心、诚实、内在稳定，市场定价很慢，甚至定不了价，那是内功篇的辖区。

一、选资产：职业资本地图，先盘点再修炼

修炼之前先有一张地图：职业能力不是一块铁板，是一层一层的资产——能积累、会折旧、能被别人复用、能在市场上换钱。没有地图，只能凭感觉补课；有了地图，才知道差距在哪一层。图上画的是骨架（定价逻辑），各行业往里填的东西不同，骨架不动：

flowchart TD
    L1["L1 门票资产<br/>行当基本功，能进场"] --> L2["L2 工程资产<br/>把活干成可靠交付"]
    L2 --> L3["L3 系统资产<br/>独立扛住一个复杂系统"]
    L3 --> L4["L4 业务资产<br/>知道手上的活值多少钱"]
    L3 --> L5["L5 组织资产<br/>让别人也会"]
    L4 --> L6["L6 创造资产<br/>定义什么值得做"]
    L5 --> L7["L7 网络资产<br/>市场定价前先听说过你"]
    AI["AI 放大器（横切）<br/>乘以哪一层，哪一层产出翻倍"] -.-> L1
    AI -.-> L2
    AI -.-> L3
    AI -.-> L6
    L0["L0 地基<br/>睡眠·运动·精力——所有层的乘数"] -.-> L1
    L0 -.-> L3
    L0 -.-> L5

先界定一个概念：这是职业资本地图，不是能力依赖树。层与层之间没有严格先后——创始人可以 L6、L7 很强而 L3 很弱，资深工程师可以 L3、L7 很强而 L4、L6 一般。层号标的不是升级顺序，是定价逻辑的差异：每一层被市场定价的方式不一样。

把能力叫"资产"不是我的发明。Cal Newport 在《优秀到不能被忽视》（So Good They Can’t Ignore You）里就叫它职业资本（career capital）：稀缺、宝贵、能拿来换自主权和好工作的技能。书名本身就是提醒——别拿"追随激情"当策略，资本攒够了，选择权才来。

再限定一个范围：骨架通用，但本文的填充物以后端/AI 时代技术人为原型。程序员版和其他行业的对照如下——换行时要换的是填充物，骨架不动：

层	程序员版填充	换个行业填什么
L0 地基	睡眠·运动·精力	不用换，所有职业的乘数
L1 门票	语言·数据结构·Debug·测试	医生的临床、律师的条文、销售的陌拜
L2 工程	Linux·网络·数据库·并发·CI/CD·云·可观测性	流程、工具、质量控制：把活干成可靠交付
L3 系统	架构·性能·稳定性·容灾·成本·安全·技术债	一台大手术、一个案子、一个区域的业绩
L4 业务	用户·指标·商业模式·ROI·业务约束	不用换：知道手上的活值多少钱、为什么值
L5 组织	沟通·技术决策·带人·项目推进·影响力	不用换：让别人也会
L6 创造	找机会·定义问题·产品·商业化	不用换：定义什么值得做
L7 网络	Mentor·同行网络·公共声誉	不用换：市场定价之前，先听说过你

所以换行时要重画的只有 L1-L3 的填充，L4 以上连内容都不用换——越往上，层越和具体手艺无关。 这也解释了为什么高手换行比新手快：他搬走的是 L4 以上，要补的只是门票和工程层。

L0 是乘数，不是层。 睡眠、运动、精力，是这张地图里证据最强、回报率最高的变量。乘数不做加法做乘法：长期睡不好，L1 到 L7 全体打七折。L0 不排日课，只立一条负面清单——不许用牺牲睡眠换打卡，这种"修行"是负复利——越坚持，亏得越多。
L1、L2 是门票。 不达标，后面全免谈；达标之后边际收益骤降——没人因为 Git 用得比别人好 30% 而升职。门票层的正确策略是够用即止。在门票层无限刷经验——面试八股再背一遍、源码再啃一遍——是程序员最普遍的负复利：它有确定感，而攻关没有。
L3 是分水岭。 能不能独立扛住一个核心系统的稳定性，是"执行者"和"负责人"的界线。这一层主要靠真实故障喂出来——读书、源码、事故复盘能搭骨架，承担过后果的故障才长肉。工作年限不是经验，承担过什么责任才是：L1/L2 乘以五年，还是 L1/L2。
L4 是天花板抬升器。 同样的方案，懂业务的人知道它值多少钱、该在哪个季度做。初级程序员解决问题，高级程序员判断什么问题值得解决，再往上，定义什么问题该被整个团队解决——后两层全靠 L4。
AI 不是单独一层，而是横切——横着穿过——所有层的放大器。 L1 层它是 AI Coding，L2 层它是辅助调试与运维，L3 层它是辅助架构与故障分析，L6 层它是 AI-native 产品。“会用 AI"六个月就过时；它乘以哪一层，哪一层产出翻几倍。下一节专门给它重新定价。
L5、L6 是杠杆。 你自己会，不值钱；你能让别人会，才开始值钱。L6 的"产品"值得单独点名：AI 时代正在长出一条新路线——发现问题、定义需求、AI 实现、验证、收费——走完这一圈的人不是"更高级的程序员”，是 Builder。这条路可以不经过 L5，从 L3/L4 直接跳进 L6，地图允许这种跳法。
L7 是定价市场。 L5 是组织内的影响力，L7 是组织外的职业资本。它不是升值的果，是升值的领先指标：市场给你定价之前，先听说过你。

先盘点：每层只记三行

地图有了，先对账——拿地图和自己的真实现状核对一遍。自评是最易自欺的环节，所以用最死板的方式记，每层三行：

当前证据：不是"我觉得我懂分布式"，而是"我在生产环境独立处理过 X 类一致性故障，最近一次是几月"。没有证据的自评，一律按低一档记。
目标档位：明年这个时候这层要到哪一级？用行为写，不用形容词写。
差距动作：从当前到目标，最短路径上的下一个具体动作。“上一门课"不算动作，“用 Raft 手写一个玩具 KV，并让它在断网实验里活下来"才算。

这盘账，每季度对一次。

地图负责战略定位，不负责精确诊断。L3 的"架构、性能、稳定性、容灾、成本、安全、技术债”，每项都是独立能力域——你完全可能稳定性 9 分、安全 3 分。需要诊断时，就把这一层拆细：拆成一个个能力项，逐项套同一套三行——证据、档位、下一个动作。格式不变，只是看得更细。

下一步练哪一层：一个粗算公式

地图上这么多层，下一步练哪一层？别凭焦虑选，用一笔粗账：

能力投资回报 ≈ 市场价值 × 稀缺度 × 个人优势 × 复利性 ÷ 学习成本

市场价值看第二节的定价；稀缺度看身边多少人已经会；个人优势看账本上的证据集中在哪；复利性看能不能被输出环放大；学习成本算的不是学费，是你要为它砍掉什么。公式给不出精确数字，能拦住的是最坏的那种决策——因为"大家都在学"而学。用它过一遍就知道，为什么今年该练 AI 工程化而不是把八股再背一遍：前者五项全胜，后者输在稀缺度和复利性。

三条路线：地图有层，还得有路

下面三条示例路线，动手前先算一笔时间账：这里说的"预算"不是钱，是你每周能拿出的小时数。路线上的验收物按攻关档计——攻关档是集中突破的节奏，每周 6-8 小时整块时间，实际跑完约 180-270 天。别被阶段标签的"周"骗了，那是先后顺序，不是日历承诺。日历装不下攻关档，只有两个诚实选项：退回保底档——日常维持的节奏，详见第六节——慢慢磨，或者砍验收物数量——不砍质量。宁可只交出一个通过压测的手写 HTTP server，不要三个半成品。这一节先立两条规矩：第一条是上面的"先算时间账”；第二条：路径可替换，验收物不可替换——书可以换、项目可以换、方向可以换，验收物缺了就是没达标。

这套路线的骨架来自刻意练习（Anders Ericsson《刻意练习》）：明确目标、走出舒适区、即时反馈、针对弱项。验收物管"明确目标"，攻关档管"走出舒适区"，评审和故障管"即时反馈"，盘点三行管"针对弱项"——四样凑齐才叫刻意练习，缺一样就是重复劳动。

L1 → 扎实（给基础虚的人）

第 1-4 周：精读一本语言级的 effective 书（Effective Python / Effective Java），每天一条，标注"我的旧代码哪儿犯过这条"
第 5-8 周：把每条标注对应的旧代码翻出来重写，补上测试
第 9-12 周：写一个带 CLI、带完整测试、跑在 CI 上的小工具
验收物：30 条标注，每条对应一个真实的改进 commit；一个测试覆盖率 80% 以上、CI 常绿的小工具

L2 → 打通（给"会用但不懂"的人）

第 1-4 周：网络——不用框架手写一个 HTTP server，逼自己搞懂 TCP 握手、TLS、keep-alive、超时
第 5-8 周：数据库——在真实库里制造慢查询，用 explain 一路优化到毫秒级；再手写一个玩具 B+ 树，看懂页分裂
第 9-12 周：Linux 与可观测性——把自己写的服务完整部署一遍，配好日志、指标、告警（自建 Prometheus + Grafana 即可）
验收物：一个通过并发压测的手写 HTTP server；一份有 before/after 数据的慢查询优化报告；一个告警真的在半夜响过、而你爬起来处理了的自部署服务

L3 → 入场（给没独立扛过系统的人）

第 1-4 周：挑一个你参与的核心服务，画出完整依赖图与数据流图。画的时候问四个问题（出自系统思维）：存量——系统里积累着什么东西（数据、队列、欠下的技术债）？流量——什么在流进流出，速度多快？回路——哪些输出会反过来影响输入（比如用户越多、服务越慢、用户流失）？时延——一个动作要过多久才能看到结果？
第 5-8 周：自造故障实验——人为制造故障：网络分区（让两台机器互相连不上）、磁盘打满、下游超时，记录系统真实行为与你想象行为的每一处偏差
第 9-12 周：为这个服务写一份容灾/降级预案，提交评审，被 challenge 到底
验收物：一张被故障实验验证过的依赖图；一份故障注入记录，必须包含"我原来想错了的地方"；一份过了评审的容灾预案

L4 往上不给示例路线——业务、组织、创造三层的路径高度依赖行业与角色，给通用路线就是造假。而且自己定义路线这件事，本身就是 L4 的训练。

二、看定价：AI 时代的重新定价

资产会折旧，地图有"汇率"——每一层能力换算成市场价格的比率，而且这个比率随时在变。写代码正从稀缺品变成像水和电一样便宜的基础设施，定价随之迁移。

正在贬值的：

纯实现能力——“把明确的需求翻译成代码”，AI 做得越来越便宜
记忆型知识——API 细节、语法糖、框架黑话，检索成本趋近于零
局部优化技巧——AI 生成的第一版往往已经够好，靠人手工微调的溢价在消失

正在升值的：

问题定义：AI 能写代码，但不知道为什么做。动笔前那三句话——现在到底发生了什么、什么才算解决、什么情况下必然失败——如今是人机分工的分界线。
系统理解：复杂系统里的边界、历史债务、隐性依赖、组织约束，AI 拼不出全貌。这是庖丁的"天理"——牛身体的天然纹理，借指事物本身的结构；纹理只在摸过牛的人手上。
判断：AI 给你十个方案，哪个值得做、哪个的保质期多长。
验证：AI 最大的问题是会自信地给出看起来合理的答案。你的核心身份越来越接近验证机器——设计实验、构造反例、让现实投票。
业务与创造：客户愿意付多少钱、什么问题值得做——AI 不替你承担后果，所以也不替你分享定价权。

人机协作的形态也随之改写。过去是"需求 → 程序员 → 代码 → 产品"，一条直线；现在是"问题 → 人定义与约束 → AI 实现与生成 → 人验证与负责 → 现实结果"，一个回路。程序员的价值坐标，从"我能写多少代码"移向"我能定义多复杂的问题，并可靠地让机器把它变成结果"。

一条分工纪律：AI 做便宜的事，人做贵的事

与其争论"AI 会不会取代程序员"，不如立一条可执行的规矩：

让 AI 做便宜的事，人做贵的事；每次交接都留证据。

这条纪律落到每天的活上，是三个动作：

提示词即三句话：给 AI 的每个任务先写清输入、成功标准、必然失败的情形。写不出来，说明你自己没想清，这时让 AI 开工等于把含糊放大十倍。
验证前置：接受 AI 产出前，先写下"我要检查哪三处最可能出错"，再去看代码。顺序不能反——先看了代码再找问题，你就被它的自信传染了。
纠错即沉淀：第二次纠正 AI 同一个问题，就固化成规则写进配置文件（Claude Code 工程实践）。你的规则文件，就是你对 AI 的工程化程度。

练兵场正在消失：自己动手造回来

“L3 主要靠真实故障喂出来”，加上"AI 正在接管纯实现"，两句话拼在一起，结论很残酷：初级程序员的练兵场正在被 AI 拆掉。

过去新人被 L1/L2 的脏活喂大，而脏活恰恰是通往 L3 的学徒期：写够 CRUD 才懂数据库的坑，值够夜班才懂稳定性的贵，改够烂代码才懂架构为什么长这样。现在脏活交给 AI，梯子被从入场者脚下抽走——代码写得比以前快，系统理解却没有同步长出来。

梯子抽走了，就自己造。四个办法，按成本从低到高：

自造故障实验：把自己写的（或克隆的开源）服务部署到云上，人为制造故障——网络分区、时钟偏移、磁盘打满、下游超时、OOM（内存耗尽被杀）。每次记录"系统真实行为"与"我以为的行为"的偏差，偏差清单就是 L3 的教材。全部成本是一点云账单。
复现经典事故：找公开的 postmortem（事故复盘报告）——GitLab 2017 删库、AWS S3 2017 配置错误、Cloudflare 一个正则拖垮全网——读懂因果链，在自己的环境里用最小规模复现核心机制。复现一次别人的事故，等于让别人替你交了一次学费。
给开源项目修带真实约束的 issue：不修 typo，专挑带性能、并发、兼容性、平台差异标签的 issue。真实代码库、真实 maintainer、真实评审——“反馈质量"在开源社区是免费的。
Shadow 值班：公司允许的，申请跟随值班，不当正职当影子；公司不允许的，给自己的项目配告警，自造值班——告警响了 15 分钟内必须响应，处理后写三行复盘。告警是假的，应激反应和复盘是真的。

这四条也给带新人的人用：把练兵场一并交给新人——你造梯子的动作，本身就是 L5 和 L7 的资产。

三、选环境：选择大于努力

能力在环境里长出来。代码能力是被代码评审喂大的，不是被静坐喂大的。一个没有评审、没有故障、没有难题的团队，环转一万圈，L3 依然是零——原料不存在。选择环境的权重，高于修炼本身。 芒格有个反复讲的钓鱼规则：第一条，去有鱼的地方钓；第二条，别忘了第一条。选环境就是这条规则的职业版。

但这不是跳槽许可证。环境是增长率的乘数，不是万能解——底数是零，乘数再大也是零。而且环境经常不是当下可控的变量：签证、家庭、城市、行业周期，都能把人钉在原地。判断自己缺的是环境还是能力，有个诚实的测试：当前环境给过你的难题，你接住了几个？ 一个都没接住过，先别怪环境——你缺的可能不是好环境，是承担困难的能力。

先选赛道，再选团队

选择分粗细两层，别搞混。

赛道是 beta——借投资圈的说法，指整个行业的大势——决定你能力的单价。 同样的 L3 资产，放在扩张赛道是稀缺品，放在收缩赛道是库存。判断赛道不用玄学，用一手数据：抓连续两期 HN 招聘帖做词频和薪资分布（9 月观察），看哪些方向的公司真的在花钱招人、哪些职级的薪资在逆势分化——还在真金白银招人，本身就是赛道还健康的证据。此法适用于英语区市场；国内看替代信号——目标赛道的社招 JD 数量变化、猎头主动接触频率。同时记住：赛道判断也是决策，也带保质期，两年前正确的押注今天可能是主要矛盾本身。

团队是 alpha——同样借投资圈的说法，指你超出大势的那部分收益——决定你能力的增速。 评估一个团队值不值得投入几年，看四样东西，按权重排序：

难题密度：这里的问题，是我已会做的重复，还是逼我长新资产的增量？判据很简单——回想最近三个月，有几件事是"做完之后我变强了”，而不是"做完之后我只是做完了"。
反馈质量：有没有比你强的人认真看你的产出？强评审、强 mentor、强故障复盘，是能力增长的外部引擎。没有反馈的练习不是刻意练习，是重复劳动。
所有权空间：你能不能端到端地拥有一个东西——从设计、实现、上线到对它负责？所有权是 L3 和 L4 最可靠的来源。只能碰系统一角的环境，天花板肉眼可见。
诚实程度：这个环境奖励说真话的人吗？一个逼你自欺的环境，会把你的环从地基上拆掉。

flowchart LR
    Q{"四个判据打分"} -->|"难题密度高 + 反馈强"| S1["留下，把环全速转起来<br/>修炼收益最大"]
    Q -->|"能力已溢出，无难题"| S2["主动要难题/换项目<br/>先内部迁移，再考虑外部"]
    Q -->|"无反馈无所有权"| S3["环照转，但把它当成<br/>离场的准备动作"]
    Q -->|"逼你自欺"| S4["走。不讨论，不优化<br/>诚意高于一切"]

注意：即使决定要走，内功环也不能停。 在烂环境里坚持日课和复盘，不是感化环境，是为了离场时账本上有资产。选择决定修炼的汇率，修炼决定选择时的筹码。

把四个判据提前到面试：反问清单

四个判据有个致命弱点——全部只能入职后验证。“回想最近三个月"对还没有这三个月的人毫无用处。真正需要判据的时刻是面试，所以把判据前移成四个反问，在"你有什么想问的"环节照着打：

探难题密度：“团队最近半年解决的最难的技术问题是什么？"——听对方能不能在 30 秒内说清技术难点具体卡在哪一层（网络、存储、并发、算法……）。说不出具体的"难”，说明"最难的问题"是宣传话术。
探反馈质量：“最近一次 P1 级故障是什么时候？复盘报告方便看看吗？"——给不出复盘、或复盘全是"加强意识"的团队，一票否决；愿意把复盘给候选人看的团队，通常值得去。
探所有权空间：“如果我入职，前六个月端到端负责什么？"——回答是"先熟悉熟悉"的，套用一句老话：没看过现场的承诺，权重打五折。
探诚实程度：“团队里有没有人公开反对过上级主导的技术方案？后来怎么样了？”

什么时候不该马上走：先算切换成本

“逼你自欺的环境——走，不讨论”，这句话不能说得太轻。现实里"走"从来不是零成本动作：房贷、签证、行业周期、家庭、年龄，每一项都是真实的约束。把"走"写成无参数的指令，是另一种鸡汤。补三条：

诚意红线例外：环境要求你伪造数据、隐瞒事故、欺骗用户时，任何切换成本都不构成留下的理由——这不是修炼问题，是法律问题和人品负债，负债的利息按复利计。
其余情形：先算账，再设期限。 写下最坏结果（再留一年，L3 资产依然为零），心理上接受它，然后给自己一个明确的准备期（比如两个季度）。准备期里环照转、验收物照攒、输出照发，把"走"从逃跑改造成有计划的发射。止损线要硬。
决定进决策日志：当时基于什么信息、预期什么结果、什么信号出现就该推翻，一样不少。半年后回看，离职判断和技术判断同权。

四、加杠杆：补上输出这一环

内功篇解决了"持续更新自己”，但积累要变成资产，还得补上"输出"这一环。这里说的杠杆，就是让一份投入产生成倍产出的东西。

内功篇的环是六个动作——看见、提问、理解、行动、反馈、沉淀，转完一圈重新看见。但这个循环丢了一步：沉淀是把经验存进自己脑子，输出是把经验变成别人能用的资产，两者的杠杆差着一个数量级。

补上输出，环变成七环：

flowchart LR
    S1["看见"] --> S2["提问"] --> S3["理解"] --> S4["行动"] --> S5["反馈"] --> S6["沉淀"] --> S7["输出<br/>把私有认知变成可复用资产"]
    S7 -->|"输出引来新的现实反馈"| S1
    S7 -->|"复利：资产生资产"| S7

输出为什么要算独立一环，而不是沉淀的附属品？因为输出是唯一接受外部检验的沉淀。写在自己日志里的复盘，错了没人知道；写成文章、做成分享、变成团队规范，错了会被当场指出。

再纠一个容易跑偏的理解：输出不等于公开发表。 输出的完整阶梯是——个人笔记 → 团队资产（你的模板被同组采用）→ 组织资产（跨团队复用）→ 公共资产（文章、开源、分享）→ 市场资产（带来机会与报价）。对多数程序员，输出的第一市场是你所在的团队：你设计的迁移规范被全团队执行，你带出三个能独立扛事的 Senior——这种组织内复利，杠杆常常大于一篇十万阅读的文章。

还要把强度说准：输出只是资产化的起点，不是资产本身。 写了一百篇文章，不等于攒了一百个资产；走完复用、影响、经济价值这几级，才算。

这套打法也不是新发明：费曼学习法说"教是最好的学”；swyx 的 Learn in Public 和 Austin Kleon 的《Show Your Work》说的是同一件事——把学习过程公开，反馈和机会会自己找上门。

写、讲、教、建：四级做法，杠杆从小到大

按杠杆从小到大：

写：把解决过的问题写成文章/内部文档。复述给外行听是练习，写下来公开是资产。
讲：团队分享、会议发言。结论先行、理由不超三个，在这里从"表达技巧"升格为"影响力工具”。
教：带新人、做 mentor、把你的复盘模板变成团队规范。教不动的地方，就是你没懂的地方。
建：开源项目、工具、产品。把能力固化成不需要你在场也能运转的东西——失败项目变成教程、模板、产品，就是这条路的走法（idoubi 复盘）。

输出的三道护栏：冷启动豁免、质量门槛、保密红线

输出环要装三道护栏，否则它会以三种方式坏掉：

冷启动期豁免：刚开始写、还没有读者的阶段，前 20 篇文章没人看是常态，不是异常。所以前 90 天只看产出数，不看消费数；90 天后再切换到"有没有第二个人消费过"的判据。先让环转起来，再要求环有回声。
质量门槛，防凑数：最大的风险是滑向内容农场化——为了流量批量生产低质内容。补一条定义：资产要有验收物——代码、数据、可复现的步骤、能被别人直接使用的模板。只有观点没有验收物的，是朋友圈，不是资产。消费数是滞后指标——它只反映过去——记录它，但永远不为它优化——流量不等于能力，十万阅读的"十个 AI 技巧"和三百阅读的 Raft 边界条件实验，哪个是资产，一目了然。
保密红线：把工作中的复盘写成公开物，边界在哪？方法论可以公开，现场不可以——写"我怎么定位一类缓存击穿问题"，不写公司代码、故障细节、真实数据、客户名。拿不准就按最严标准执行。写之前加一问：这篇东西如果被对方公司的法务读到，我安全吗？

五、对账：双仪表盘

对账需要两块仪表盘，内功篇只给了第一块——复位时间：从被事件牵着走，到重新拿回选择权要多久。它测引擎健康度，测不了车走了多远。一个情绪三秒复位、依然修不动生产故障的人，是内功意义上的高手，市场意义上的初级。

所以这一节加第二块仪表盘：现实改变量。四根针，全部用行为定义，全部有基线：

指标	志学（基线）	不惑	知天命	从心所欲（趋向）
同等级故障定位时间	建立基线（多数人从没测过）	减半	分钟级，且能带人定位	故障在发生前被结构消灭
方案评审一次通过率	建立基线	明显上升，被 challenge 不失控	争议方案一句话定位主要矛盾并给出保质期	评审别人比被人评审多
端到端交付周期	建立基线	同类需求周期缩短一半	能独立扛一个核心系统端到端	周期由你定义的结构决定
输出阶梯：产出→复用→影响→经济价值	稳定产出，团队外有人读	复用：团队在用你的模板/工具	影响：组织外有人引用，做法因你改变	经济价值：省时省钱可计量，机会找上门

复位时间测心，现实改变量测物。第四根针刻意不按阅读量分级——原因见第四节的"质量门槛"。

先排除环境干扰：四根针都不是纯个人指标

这四根针都受环境影响：换一个更烂的系统，故障定位时间会变长；换一个更严的评审文化，一次通过率会先跌；接一个更重的需求，交付周期会变长。所以看读数之前，先把环境因素的影响剔掉，三条做法：

只在同一环境里比：基线和读数要取自同一团队、同一系统、同一评审文化。换环境后的第一个季度，只记录，不下结论。
把环境变化记在曲线旁边：哪个月换了系统、哪个月来了新规范、哪个月团队扩编，都标出来。复盘时才能分清是练得不够，还是环境变了。
指标是证据，不是目标：通过率上升，可能是方案变好了，也可能是你不再提有争议的方案；交付周期缩短，可能是效率高了，也可能是你开始挑简单的活。把指标当目标，它就会失真——这就是古德哈特定律（Goodhart’s law）：一项测量一旦成为目标，它就不再是一个好的测量。

六、落地：一条戒律、最小配置、两档预算

戒律：每次内省，必须改一个现实动作

落地先立一条硬约束：

每一次内省的产出，必须是一个改变了的现实动作。只有感受没有动作的内省，按空转记。

为什么要立这条？内功练的是向内看，但向内看有一个隐蔽的风险：元认知（对思考的思考）叠元认知，最后练成一种新型拖延——“我非常理解为什么我没有行动”，然后继续没有行动。

三个例子说明什么叫"改了动作"：

发现自己总在方案上过度设计 → 下一个需求强制用最小方案上线，事后对比返工率。
发现自己总逃避不确定的任务 → 本周主动认领一个没做过的任务，写进周报。
发现学习太碎片化 → 删掉 80% 的收藏夹，只选一个主题做 30 天，30 天后用输出环验收。

“写下来"让推理不能自欺，“改动作"让内省不能空转。一个防骗，一个防瘫。

这条戒律有人早就执行过严厉版：达利欧在《原则》里的公式是"痛苦 + 反思 = 进步”——每次痛苦之后，必须写下一条以后能执行的原则，几十年攒成一家公司和一本书。内省不落成一个动作，按他的标准就不算反思。

最小配置：三件内功日课，四件外功功课

内功篇只留了两个习惯——写下来，和看复位时间。这里给外功开出处方，砍到骨头——三内四外，也就是三件内功日课、四件外功功课，每天碎片时间加起来不超过 30 分钟：

内（约 15 分钟，承接内功篇）：

静坐或听息，5-10 分钟——引擎怠速保养
三行日省（搞懂了什么、悔什么、明天改什么；与内功篇的睡前三行是两套，别混），新增一个强制字段：今天哪个现实动作被内省改变了？ 填不出来的日子，按空转记
动笔前三句话——同时是防返工手段和人机分工界面，一件日课两份收益

外（每天约 15 分钟 + 每周若干整块）：

每天一个刻意练习动作：不是"学分布式”，是"今天读懂 etcd 的 lease 续期路径并画出时序图"——具体到有验收物。15 分钟只够点火，火去整块时间里烧
每周不可打断整块时间：写进日历，当作与自己开的会，手机离场。啃源码、手写玩具 Raft、跑故障注入实验——L2/L3 资产只在这里长出来。它不与任何日课互换：日课是保养，整块是施工；缺日课伤引擎，缺整块直接停工
每周一个超出舒适区的难题：认领一个你没把握的任务（可并入整块时间执行）
每周一件可复用资产：文章/分享/PR/模板/设计文档——公开只是其中一种形式，受第四节三道护栏管辖。这是节奏建议，不是硬纪律：忙季降成双周一件，也比没有强

另有一件不占日课额度、但不可省略的：每季度一次能力账本对账——每层三行字，证据、档位、下一个动作。

其余全是可选插件，最小配置转稳了再加。碎片日课要小到不可能失败，整块时间要狠到不可谈判。

两档时间预算：保底档与攻关档

整块时间给多少，分两档，别混。先把名字说清：保底档是日常维持的节奏，攻关档是集中突破的节奏。

保底档（常年默认）：每周 2 × 2 小时。目标只有一个——环不停、账本在涨。两小时是一块不能再砍的最小施工面。
攻关档（跑第一节的能力路线时）：整块上调到每周 6-8 小时，碎片日课不变。一条路线跑完、验收物交齐，退回保底档。

两档切换的信号写在能力账本上：开始攻关，记一笔"进入攻关档，目标验收物 X"；验收或放弃，记一笔"退回保底档"。预算的变化要留痕，不然"最近太忙"会成为所有档位的通用借口。

七、边界：这套体系什么时候不适用

这套体系不是万能的，这一节给它划四条适用边界。一个什么都能解释的体系，什么都没能预测——成长慢是拆解不对，不开心是觉知不够，失败是验证不足。漂亮不等于有效。所以这套东西得说清楚自己什么时候不适用：

L1/L2 门票层不达标时，修炼让位于补课。 连基本盘都不稳的人，日课做得再漂亮也是给危房刷漆。此时唯一正确的动作：砍掉大部分内向日课，把时间整块投给刻意练习。碎片时间练心性，整块时间才能练技术。
生存压力下，先解决生存。 房租、健康、关系出了大问题的时候，成长体系是奢侈品。此刻的诚实是承认自己在求生存期，环暂停不是失败。
环境逼你自欺时，选择高于修炼。 在诚实被惩罚的地方练诚实，是用最贵的功夫对抗最错的战场。
已到局部最优时，环解决不了相变——物理学里水烧成蒸汽那样的突变，这里借指不连续的跳跃。环擅长连续改进——同一类问题下次处理得更好。但从"执行者"到"负责人"、从"打工"到"创业"是相变，不连续，靠的是选择、时机和下注，不是把日课做得更精。

在这四条边界之外，再立一条证伪标准——事先说清楚，出现什么结果就承认方法无效——用这套方法自己的规矩审判它自己：

证伪窗口按指标分层：心性类（复位时间、情绪响应）——两个季度；资产类（故障定位时间、评审一次通过率、交付周期）——四个季度；复利类（输出阶梯上的复用与影响）——六个季度起，市场反馈天然滞后。窗口到期、且已完成归因修正（确认不是环境因素）、针依然没动——结论不是"你不够诚实"，而是这套体系对你无效，或者你选错了环境。把结果写下来，公开认错，然后换方法。预测错了不丢人，悄悄删掉才丢人——对人如此，对法也如此。

仪表盘不动的另一种解释：力不足，还是命暂不出价

证伪标准处理的是"力"的失败。但针到期不动、归因修正做完之后，还剩两种可能：力不足，或者命暂不出价。 力不足，如前所说，换方法、换环境。命不出价——行业在收缩、市场暂时不认这类资产、周期走到下行段——这里的"命"不是宿命，是当前模型与行动无法控制的外部约束；它不是失败，是力与命的二分法里，属于命的那一半到账了。

这条二分线也不是我画的。爱比克泰德在《手册》开篇就划了它：“有些事取决于我们，有些事不取决于我们。“这一节只是把这条线画到了能力账本上。

这时候的正确动作，不是加倍自责地刷日课、把仪表盘盯出洞来——那是用命的结果审判自己，和用愿望代替现象一样，都是不诚实，只是一个向左一个向右。正确的动作是：把力继续用足（环照转、账本照记），然后接受命的出价——要么带着资产换一个出价的市场（第三节），要么把账本合上，等下一个周期。资产是力，攒它的目的是把命的边界往外推；推不动的地方，就是"止"字落笔的地方。知止的"止”，最终不止于目标，也止于这条力与命的边界——在力的尽头，心安。

八、次第（外功版）

四级名字借自孔子——志学、不惑、知天命、从心所欲。内功篇的进度条是复位时间，测的是心；这里给外功配上测物的标准：

志学（外功）：能力账本建立，每层有证据；故障定位和评审通过率有了基线数字——多数人从没测过自己，这一步就超过一半同行。
不惑（外功）：门票层达标，L3 开始有真实故障喂出来的证据；同类需求交付周期肉眼可见地缩短；每周有一件可复用资产离开私人笔记。
知天命（外功）：独立扛住一个核心系统端到端——on-call 你值、P1 故障你定位、复盘你主持、容量与成本的账你算；你的模板和规范开始被别人用；能在会前判断"这个问题值不值得团队解决”。
从心所欲（外功）：判断本身成为资产——你知道什么值得做、什么不值得做，并且不需要通过"团队听我的"来证明它。此时环、地图、仪表盘都可以烧掉，因为选择已经长在手上。

大成不看事件，看日常。它的另一个名字，是你的名字出现在别人能力账本的"反馈质量"那一栏里。

最后把镜头拉远一步：这张地图的终点，其实不是"更高级的程序员"。AI 时代，编程正在从一种职业身份，变成一种基础杠杆——技术、AI、写作、团队、产品、资本，都是杠杆，编程只是其中之一。地图的尽头是高杠杆创造者：能借助所有这些杠杆，把自己的判断放大成现实结果。“程序员"只是你身上若干杠杆之一的名字，Junior → Senior → Staff 也只是若干条路线里的一条，不是天命。

《大学》说：知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能得。 内功篇讲怎么虑、怎么得；外功篇只补最前面的两个字——知止：知道该停在哪个目标上，知道什么不做。知道该停在哪座山上，再谈登山的心法。

两篇合起来，压缩到最后只剩三样东西：

一颗心，一张地图，一本账。

心不息：保持看见、提问、行动、更新。地图：知道把更新投向哪里。账本：用现实证明自己有没有变强。

此心不息，是引擎不熄火；能择其要，是方向盘在手上。万物常新的前提，是你的环转在值得转的地方。

现在，打开你的能力账本，写下第一行证据。

附：出处与延伸阅读

本文的方法多是把别人的成熟零件装到自己这台机器上，出处如下，想深入的读者可以从这些地方继续：

“职业资本"这个概念：Cal Newport, So Good They Can’t Ignore You（《优秀到不能被忽视》）——career capital 一词的出处，第一节的地图是它的展开。
路线设计的四要素：Anders Ericsson & Robert Pool,《刻意练习》（Peak）——明确目标、走出舒适区、即时反馈、针对弱项。
“去有鱼的地方钓鱼”：查理·芒格在多次演讲中讲的钓鱼规则（笔记见《穷查理宝典》），第三节用它讲选赛道。
输出这一环：费曼学习法（以教促学）；swyx, “Learn in Public”（2018）；Austin Kleon, Show Your Work!——三件不同年代的作品，说的是同一件事。
“把指标当目标，它就会失真”：古德哈特定律（Goodhart’s law）。
“内省必须落成动作”：瑞·达利欧《原则》（Principles）——痛苦 + 反思 = 进步。
力与命的二分：爱比克泰德《手册》（Enchiridion）——“有些事取决于我们，有些事不取决于我们。“斯多葛的实践读法，站内见《像哲学家一样生活》笔记。
四级的名字：《论语·为政》——“吾十有五而志于学……七十而从心所欲，不逾矩。”

这些出处标的是"零件从哪来”；至于这个装法对不对，终审权在现实，不在文献。

《重构》学习总结：改善既有代码的设计，把日课做成习惯

Tue, 08 Aug 2023 10:40:00 +0800

《重构》学习总结：改善既有代码的设计，把日课做成习惯

目标读者：写过一两年业务代码、经常被祖传代码折磨、想搞清楚“重构到底怎么落地”的程序员。
参考书籍：Martin Fowler《重构：改善既有代码的设计（第 2 版）》（Refactoring, 2nd Edition）
阅读目标：建立“重构是刷牙不是大扫除”的日常习惯，把坏味道清单变成自己的启发法清单，学会在安全网保护下小步快走。

0. 写在前面：重构不是大扫除，是刷牙

很多人对重构的想象是这样的：找一个安静的下午，拉上需求方开个会，申请两周“专项重构时间”，然后把某个模块推倒重来。这种理解恰恰是 Fowler 最反对的。

这本书最核心的一个比喻，可以用我自己的话总结为：

重构不是年底大扫除，是每天刷牙。大扫除轰轰烈烈、一年一次、中间家里一直脏；刷牙小额、频繁、不痛不痒，但牙齿几十年不出大问题。

这个比喻对应到工程上有三个推论：

小额：一次重构就改一点点，编译能过、测试能绿，马上提交。不是攒一个月再交一个巨型 PR。
频繁：每次加功能、改 bug、做 code review 的时候顺手做，融进日常工作流，不需要“立项”。
不改变外在行为：这是定义，不是建议。下面马上展开。

为什么这本书值得每个程序员精读？因为坏味道清单就是启发法清单的代码版。算法书教你遇到问题时用什么启发法求解，Fowler 教你看到代码时用什么启发法判断“这里不对劲”以及“该用哪招”。读熟之后，你看代码的眼光会永久改变——这是少数几本读一遍就能立刻涨功力的书。

1. 一句话理解重构：不改变可观察行为的结构调整

Fowler 给出的定义（第 2 版，第 2 章）：

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

拆开看有三个关键词：

结构调整：动的是代码的组织方式——函数怎么拆、类怎么分、数据放哪里。不是改它“做什么”，是改它“怎么摆”。
不改变可观察行为：用户看到的、API 返回的、数据库写入的，统统不能变。你改了行为，那叫“改功能”或“修 bug”，不叫重构。
可理解性 / 修改成本：重构的目标从来不是“代码更好看”这种审美追求，而是让下一次修改更便宜。这是经济学决策，不是艺术决策。

1.1 两顶帽子：加功能和重构不同时戴

Fowler 引用了 Kent Beck 的“两顶帽子”比喻，这是全书我最常拿来讲给同事听的概念：

戴上“加功能”的帽子：你只添加新代码、新测试，绝不修改已有代码的结构。
戴上“重构”的帽子：你只调整结构、保证测试全绿，绝不添加新功能。

写代码的每一刻，你头上只能戴一顶帽子。发现“要加这个功能，得先把这段代码理顺”，正确动作是：摘下加功能的帽子 → 戴上重构帽子 → 重构到方便加功能为止 → 换回加功能帽子 → 加功能。

flowchart TD
    A["接到需求：要加新功能"] --> B{"现有代码结构<br/>方便加这个功能吗？"}
    B -- "方便" --> C["戴加功能的帽子<br/>写新代码 + 新测试"]
    B -- "不方便" --> D["戴重构的帽子<br/>只做结构调整，测试保持全绿"]
    D --> E{"结构理顺了吗？"}
    E -- "还没有" --> D
    E -- "理顺了" --> C
    C --> F["提交，帽子归位"]

为什么这么严格？因为同时做两件事，出了 bug 你分不清是谁引入的。重构的每一步都要求测试全绿，如果中途改了行为，红灯亮起时你就失去了判断依据。两顶帽子是重构能保持“小步”的心理学保障：它把一件模糊的、容易失控的事，拆成了两个界限分明的状态。

2. 坏味道清单：程序员的启发法清单

第 3 章是全书的“字典”——24 种坏味道（Bad Smells）。注意 Fowler 的用词是“味道”不是“罪状”：闻到味道不代表必须立刻处理，它只是提示你“这里值得看一眼”。极端的教条主义本身就是一种味道。

24 种味道完整清单如下，后面挑最重要的 10 个深入讲：

神秘命名、重复代码、过长函数、过长参数列表、全局数据、可变数据、发散式变化、霰弹式修改、依恋情结、数据泥团、基本类型偏执、重复的 switch、循环、冗赘的元素、夸夸其谈未来性、临时字段、过长的消息链、中间人、内幕交易、过大的类、异曲同工的类、纯数据类、被拒绝的遗赠、注释。

2.1 神秘命名（Mysterious Name）

味道：变量叫 data、函数叫 process、类叫 Manager，看完名字不知道它是干嘛的。

为什么排第一？因为命名是程序里密度最高的文档。一段代码你可能读十次改一次，名字起得好，十次阅读每次都省时间。Fowler 说得直白：如果想不到好名字，往往意味着你对这段逻辑的职责还没想清楚——命名困难本身就是设计问题的信号。

对应手法：改变函数声明（改名）、变量改名、字段改名。现代 IDE 的重命名重构是安全的，改名字没有借口留到下辈子。

2.2 重复代码（Duplicated Code）

味道：同一段逻辑出现在两个以上的地方。改一处忘另一处，bug 就是这么来的。

这是所有味道里危害最确定、修复手法最成熟的一个。双胞胎函数用提炼函数收拢；兄弟子类里重复的用函数上移；类似但不完全相同的，先拆出相同的部分再收拢。

一个工程界的经典注脚：NASA 的航天飞机软件团队以极低缺陷率著称，他们的经验之一就是极端重视消除重复——任何相似代码都必须解释为什么存在。日常项目虽然不必如此严苛，但“重复三次就提炼”的底线值得守住。

2.3 过长函数（Long Function）

味道：一个函数几十上百行，得靠注释分段才能读懂。

Fowler 的态度非常激进：函数就该短。短函数的好处是通过名字传递意图——calcOutstanding() 比一坨内联计算强得多，因为读者看名字就知道意图，需要细节时才钻进去。

判断标准：不是行数，而是“如果你需要写注释解释一段代码在干嘛，这段代码就该被提炼成函数，函数名用注释里的词”。这个标准极其好用，直接把“注释”这个味道变成了提炼函数的路标。

对应手法：提炼函数（Extract Function）——全书使用频率最高的手法，没有之一。第 2 版里 Fowler 把提炼后的函数长度做到五六行甚至两三行，就是要打破“函数太短不值得”的心理障碍。

2.4 过长参数列表（Long Parameter List）

味道：函数签名里七八个参数，调用处像咒语。

危害有两个：一是调用方每次都要记参数顺序，极易传错（尤其是同类型相邻参数）；二是参数多往往说明函数在做不止一件事，或者这些参数本该是一个整体。

对应手法：以查询取代参数（能从参数 A 算出参数 B，就别传 B）、保持对象完整（别从对象里掏三个字段传进去，直接传对象）、引入参数对象（见 2.7 数据泥团）、移除标记参数（布尔 flag 参数往往意味着函数里有个 if 分叉，拆成两个函数更干净）。

2.5 全局数据（Global Data）与可变数据（Mutable Data）

全局数据的味道：任何地方都能读到、改到它，出了问题你找不到是谁改的。单例本质上也是全局数据。

可变数据的味道：一个变量在很大作用域内被反复赋值，你在第 500 行看到的值，无法信任它声明时的样子。

这对兄弟是并发 bug 和“灵异 bug”的头号来源。函数式编程这些年崛起的核心卖点之一就是消灭可变状态，和 Fowler 的判断完全同频。

对应手法：封装变量（把全局变量关进函数里，访问必须经过函数）、拆分变量（一个变量被赋两次值干两件事，就拆成两个）、将引用对象改为值对象（值对象不可变，天然免疫一大类 bug）。

2.6 发散式变化与霰弹式修改（Divergent Change / Shotgun Surgery）

发散式变化：一个类因为不同原因被反复修改。“数据库变了改它，报表格式变了也改它，业务规则变了还改它”——这个类承担了太多职责。

霰弹式修改：一个变化要改很多个类。加一个字段类型，DAO 改、Service 改、DTO 改、前端 mock 改，漏一个就炸。

这俩是同一枚硬币的两面：前者是“多个原因指向一个类”，后者是“一个原因散到多个类”。修复方向相反——发散式变化用拆分阶段、搬移函数把一个类拆开；霰弹式修改用搬移函数、提炼类把散落的逻辑聚到一处。

判断技巧：想象需求来了，你心里默念“要改哪几个文件”。如果答案是“又是这个巨无霸类”，是发散式变化；如果答案是“天哪又是七八个文件”，是霰弹式修改。

2.7 依恋情结与数据泥团（Feature Envy / Data Clumps）

依恋情结：一个函数对另一个类的数据兴趣远大于自己所在类的——函数里 order.getCustomer().getAddress().getCity() 一长串，全是别人家的 getter。治疗方式很直白：搬移函数，让函数搬到它依恋的数据旁边去。“策略”“访问者”模式是例外，它们故意把行为和数据分开。

数据泥团：总是一起出现的三四个字段——startDate/endDate、street/city/zip。它们像连体婴儿一样在各个方法签名和类字段里成群结队。对应手法：提炼类，给这团数据一个家（比如 DateRange、Address）。提炼完常常有惊喜：散落各处的校验、格式化逻辑（依恋情结）会自然地搬进新类。

2.8 基本类型偏执与重复的 switch（Primitive Obsession / Repeated Switches）

基本类型偏执：用字符串存电话号码、用裸 double 存钱、用 int 编码状态。小钱变大钱、状态码幻数满天飞，都是这么来的。对应手法：以对象取代基本类型——一个 Money 类、PhoneNumber 类，把校验和格式化的知识收拢进类型系统。业界血案：金额用 float/double 导致的分分钱对不上账，几乎每个支付团队都踩过，标准做法就是专门的 Money 类型或以最小货币单位为单位的整数。

重复的 switch：同一个类型码的 switch/if-else 链散落多处。每加一种新类型，得把所有 switch 都找出来改一遍——这是霰弹式修改的特化版。对应手法：以多态取代条件表达式（见 3.6 节）。注意 Fowler 的克制：switch 本身不是罪，重复的 switch 才是；如果只有一个 switch 且类型稳定，留着无妨。

2.9 中间人与消息链（Middle Man / Message Chains）

中间人：一个类一半以上的方法都在委托给别的类，自己什么也不干。封装是好事，但封装到这个程度就是纯粹的过路费。对应手法：移除中间人，让调用方直接和被委托对象说话。

消息链：a.getB().getC().getD() 一路要下去，调用方对整条链的结构产生了依赖，链中间任何一环变动都会传导过来。这就是“得墨忒耳定律”（Law of Demeter）说的“只和直接朋友说话”。对应手法：隐藏委托关系。

这一对味道放在一起看很有意思：过犹不及。委托太多是中间人，穿透太多是消息链， Fowler 的词典里没有银弹，只有“闻味道、看剂量”。

2.10 注释（Comments）

注释也上榜了，很多人第一次读会惊讶。Fowler 的逻辑是：

注释本身不是坏味道，它常常是“ deodorant（除臭剂）”——用来遮盖代码本身的臭。

当你觉得“这里得写段注释解释一下”，先问：能不能提炼函数用函数名说清楚？能不能改变量名说清楚？ 能，就别写注释。注释该写的是“为什么这么做”（业务背景、历史坑、外部约束），而不是“这段代码在干嘛”——后者是代码没写清楚的忏悔。

2.11 其余味道速查表

味道	一句话识别	首选手法
循环（Loops）	for 循环里干的事能用管道表达	以管道取代循环（filter/map/reduce）
冗赘的元素（Lazy Element）	这个函数/类就只有一层转发，毫无增量	内联函数、内联类
夸夸其谈未来性（Speculative Generality）	“为将来预留”的抽象，现在只有一个实现	折叠继承体系、内联
临时字段（Temporary Field）	某个字段只在特定算法运行时才有值	提炼类 + 搬移函数，给它一个家
内幕交易（Insider Trading）	两个模块私下大量交换数据，耦合紧密	搬移函数/字段，减少私聊
过大的类（Large Class）	一个类字段太多、职责太多	提炼类、提炼超类
异曲同工的类（Alternative Classes）	两个类接口不同干的事一样	改变函数声明 + 搬移函数统一接口
纯数据类（Data Class）	只有字段和 getter/setter，没有行为	把操作它的行为搬进来（封装记录）
被拒绝的遗赠（Refused Bequest）	子类继承了一堆用不上的东西	函数/字段下移，或以委托取代继承

“夸夸其谈未来性”值得单独敲一下黑板：YAGNI（You Aren’t Gonna Need It）。每个“将来可能用得上”的抽象，都是要付利息的技术债——它现在就开始收阅读成本，而兑现的那一天往往永远不会来。

3. 核心重构手法：七招走天下

第 6 章起的重构名录有 60 多个手法，但日常高频使用的集中在少数几招。下面七招是我个人使用频率最高、也最能体现“小步安全”思想的。

3.1 提炼函数（Extract Function）

场景：一段代码需要注释才能看懂；或者一个函数太长。

口诀：意图与实现分离——“这段代码做什么”（意图）交给函数名，“怎么做”（实现）交给函数体。

小步版本（Fowler 的名录里每个手法都有这种机械化步骤，这是本书最容易被低估的价值）：

创建新函数，按意图命名（想不到好名字就先叫临时名，回头再改）。
把要提炼的代码复制过去（是复制，不是剪切——先留着原件，错了好回退）。
检查局部变量：被新函数读到的 → 传参；被修改的 → 尽量变成返回值，一次只返回一个。
编译。在源位置替换为对新函数的调用。
测试。全绿则提交。

避坑：一次提炼只处理“只读变量多、被改变量少”的块；被改变量超过一个时，先用“拆分变量”或调整结构再提炼。

3.2 内联函数（Inline Function）

提炼的反操作。场景：函数体已经和函数名一样清楚（getRating() { return moreThanFiveLateDeliveries ? 2 : 1; } 改名后可能直接内联掉），或者一堆小函数间接层太深、改名/重组前需要先“摊平”。

重构名录里的手法大多成对出现（提炼/内联、搬入/搬出、封装/暴露），这不是凑数——可逆性是小步快走的前提：这步走错了，反手一步就能退回来。

3.3 搬移函数（Move Function）

场景：函数引用别的上下文的元素多于自己所在的上下文（依恋情结的特效药）；或者模块化需要重新划分边界。

口诀：逻辑和它操作的数据住在一起。搬移时先检查函数引用的所有东西——它们要么一起搬，要么变成参数。搬完旧位置可以留一个委托函数过渡，等调用方都改完再删。

3.4 提炼变量（Extract Variable）

场景：表达式又长又复杂，比如：

return order.quantity * order.itemPrice -
  Math.max(0, order.quantity - 500) * order.itemPrice * 0.05 +
  Math.min(order.quantity * order.itemPrice * 0.1, 100);

逐个起名字：

const basePrice = order.quantity * order.itemPrice;
const quantityDiscount = Math.max(0, order.quantity - 500) * order.itemPrice * 0.05;
const shipping = Math.min(basePrice * 0.1, 100);
return basePrice - quantityDiscount + shipping;

零风险、几秒钟、可读性立刻翻倍。这是性价比最高的重构手法，新人最值得先养成这个习惯。变量命名还能顺带自我解释业务规则：原来那 0.05 是批量折扣，0.1 是运费比例。

3.5 封装记录（Encapsulate Record）

场景：代码里到处传裸的 object/map/dict（纯数据类的输入版），字段名靠口口相传。

把记录变成类，访问走方法：字段名写错编译期就炸，而不是线上拿到 undefined；还能给计算字段提供方法（total 不必存，用 get total() 算）。这是 TypeScript 兴起后整个行业都在做的事——让类型系统替你站岗。

3.6 以多态取代条件表达式（Replace Conditional with Polymorphism）

场景：同一个类型码的 switch 散落多处（重复的 switch 味道）；或者一个函数内部按类型分叉，分支逻辑还会持续增加。

步骤：为每种类型建子类 → 把条件分支的逻辑搬成子类的覆写方法 → 原函数变抽象。书里的经典例子是“鸟类评级”：按鸟的种类（欧洲燕子、非洲燕子、挪威蓝鹦鹉）分支计算飞行速度和评级，重构后每种鸟一个子类，新增鸟种只需新增一个类——修改从“找到所有 switch”变成“新建一个文件”，这正是开闭原则。

避坑：类型码稳定且数量少时不要硬上多态。switch 只有一处、类型十年不变，多态带来的类爆炸是另一种过度设计。再强调一次：闻味道，看剂量。

3.7 拆分阶段（Split Phase）

场景：一段代码同时干两件性质不同的事——典型的如“解析输入 + 业务计算 + 输出格式”。

把两段拆开，中间用一个明确的数据结构传递：第一阶段产出中间对象，第二阶段消费它。好处是两个阶段的修改互不影响——换输出格式不动计算逻辑，换输入来源不动下游。书中 statement 案例（下节）的核心一步就是拆分阶段。命令行工具、编译器（解析→语义分析→代码生成）、数据管道，全是这个手法的工业级应用。

4. 全书导读案例：statement 计费重构走查

第 2 版第 1 章用 JavaScript 完整走查了一个案例，非常值得复现一遍，因为它是“小步快走”的教科书级演示。

原始代码：一个剧团的账单系统，statement(invoice, plays) 输出客户看戏的账单文本。一个约 40 行的函数，里面一个 switch 按戏剧类型（悲剧/喜剧）算钱，外加积分计算和字符串拼接，全部揉在一起。

需求来了（这就是重构的触发器）：① 账单要支持 HTML 输出；② 剧团打算演更多类型的戏（比如“历史剧”“田园剧”），算钱和积分规则要可扩展。

Fowler 没有直接动手写 HTML 版本，而是先重构。整个过程的关键步骤：

先补测试：原代码没有任何测试。第一步不是改代码，是给现有行为写一批测试，把输出钉死。
提炼函数：把 switch 算钱的部分提炼成 amountFor(aPerformance)，把积分计算提炼成 volumeCreditsFor()。每提炼一个，跑一次测试。
提炼变量 + 改名：thisAmount 这种模糊名改成 result，消除不必要的中间变量。
拆分阶段：把“计算账单数据”和“渲染文本账单”拆成两个阶段，中间用一个数据结构传递。此时 statement() 变成：const data = createStatementData(invoice, plays); return renderPlainText(data);。
加功能：此时写 renderHtml(data) 只消费中间数据，计算逻辑一行不碰——HTML 版本轻松加上。
以多态取代条件表达式：为“悲剧计算器”“喜剧计算器”建子类，switch 消失。加新戏种 = 加一个新子类。

flowchart LR
    A["原始代码<br/>一个 40 行大函数<br/>无测试"] --> B["补测试<br/>钉死现有行为"]
    B --> C["提炼函数<br/>amountFor / volumeCreditsFor"]
    C --> D["拆分阶段<br/>计算数据 vs 渲染文本"]
    D --> E["中间数据结构<br/>statementData"]
    E --> F["加功能：renderHtml<br/>复用同一份数据"]
    C --> G["以多态取代条件表达式<br/>TragedyCalculator<br/>ComedyCalculator"]
    G --> H["加功能：新戏种<br/>只需新增子类"]
    F --> I["最终结构<br/>好改、好测、好扩展"]
    H --> I

这个案例的精髓不在于手法本身（都不难），而在于节奏：40 行的小函数，Fowler 也花了几十个小步、每步跑测试。他要演示的是：重构的安全性不来自你的技术，来自你的步幅。步幅足够小，每一步都可以验证，出错最多浪费一步。

5. 重构与测试：先补测试，再动刀

第 2 版相对第 1 版（1999 年）最大的时代变化，就是自动化测试从“推荐”变成了“前提”。Fowler 的态度很明确：

没有测试保护的重构不叫重构，叫“改代码并祈祷”。

逻辑链条是这样的：

重构的定义是“不改变可观察行为”——那你怎么知道行为没变？只能靠测试。
重构要求小步快走——每一步都要验证，人工验证一遍要十分钟，自动化只要十秒。没有自动化，小步走不起来。
面对祖传代码没有测试怎么办？先补测试再动刀。补测试本身常常需要先轻量重构（比如提炼函数让依赖可以 mock），这就回到了两顶帽子：戴着测试帽做最小限度的结构调整，只为让测试能跑起来。

Michael Feathers 在《修改代码的艺术》（Working Effectively with Legacy Code）里把“没有测试的代码”直接定义为遗留代码，和 Fowler 互为犄角。两本可以搭配读：Fowler 教你“怎么改”，Feathers 教你“改不动时怎么办”。

flowchart TD
    A["要动一段代码"] --> B{"有测试覆盖吗？"}
    B -- "有" --> C["跑一遍，确认全绿"]
    B -- "没有" --> D["最小限度补测试<br/>（为可测性做的微调也算）"]
    D --> C
    C --> E["做一小步重构"]
    E --> F{"测试全绿？"}
    F -- "绿了" --> G["立即提交<br/>（小步提交 = 免费回滚点）"]
    F -- "红了" --> H["撤销这一步<br/>或立刻修复，不要带着红灯继续"]
    G --> E
    H --> E
    E --> I{"目标达成？"}
    I -- "没有，继续小步" --> E
    I -- "达成" --> J["收工：行为没变，结构更好"]

这张“安全网流程图”里最反直觉也最重要的一条是：测试红了，默认动作是撤销这一步，而不是往前调。小步走意味着你刚刚那一步的范围是已知的、可控的，退回上一步的代价几乎为零；带着红灯继续走，错误范围就不可控了。配合小步提交（每步都 commit），你就拥有了一条随时可以回滚的时间线。

6. 重构的时机与节奏：融进日常，而不是立项

6.1 三次法则与“顺手重构”

Fowler 给的实用规则：

事不过三，三则重构（Rule of Three，源自 Don Roberts）：第一次写就写，第二次重复捏着鼻子忍，第三次必须提炼。
加功能前重构：代码结构碍事，先重构到“加这个功能很容易”，再加功能（两顶帽子）。
修 bug 时重构：bug 之所以藏得深，往往因为代码难懂。把 bug 修掉的同时，把“让 bug 藏不住”的结构改出来。
code review 时重构：看到别人的坏味道，当面演示一次提炼函数，比留十句评论有用。

6.2 破窗效应与童子军军规

犯罪学里的“破窗效应”：一栋楼有几扇破窗没人修，很快所有窗户都会被砸——混乱会邀请更多混乱。代码库一模一样：第一处“先这样吧，回头再改”开了头，后面所有人都会照着最烂的那段代码的标准来写。

对策是 Bob Martin 普及的童子军军规（Boy Scout Rule）：

离开营地时，要让它比你来时更干净。

落到代码上：每次提交，都顺手改进一点点——改一个烂名字、提炼一个长函数、删掉一段死代码。不需要翻天覆地，只要持续为正。一个团队做到这点，代码质量会随时间收敛而不是发散。这是对付“祖传代码”唯一被验证过可持续的策略：不是一次性手术，是持续的免疫反应。

6.3 什么时候不重构

书里同样重要的克制：

代码又烂又永远不用改——让它烂着，重构它没有回报。
重写比重构便宜——偶尔成立，但门槛极高，见下节的 Netscape 教训。
离截止日期太近且重构不能帮上眼前的忙——重构的回报在下一次修改，先交付，记技术债，回头还。

记住：重构是经济学决策。每一步都应该能回答“这能让接下来的修改更便宜吗？”答不上来的重构是自我感动。

7. 大规模重写的教训：Netscape 之死

聊到重构，绕不开软件工程史上最著名的一次“我们不重构了，我们重写”的惨案。

背景：Netscape Navigator 曾统治浏览器市场，但代码库在快速迭代中积重难返。1997 年前后，Netscape 决定抛弃旧代码，从头重写浏览器引擎（即后来的 Gecko / Mozilla 项目）。

结果：重写花了将近三年。这三年里 Netscape 几乎没有发布有竞争力的新版本——6.0 版本直到 2000 年底才问世。与此同时，微软的 IE 持续迭代、免费捆绑 Windows，市场份额被彻底翻盘。等 Mozilla 成品出来时，浏览器战争已经结束了。

Joel Spolsky 在 2000 年那篇著名文章《Things You Should Never Do, Part I》里拿 Netscape 当反面教材，结论斩钉截铁：

重写是你能对软件做的最糟糕的战略性错误，没有之一。

他的论证值得背下来：

旧代码不是垃圾，是知识的化石。那些丑陋的补丁，每一个都对应一个真实用户踩过的坑、一个边界情况。重写时你看不见这些知识，于是用户会在新版本里重新踩一遍所有的坑。
重写期间你无法交付。老代码烂归烂，它在生产环境里跑着、赚着钱；新代码在成型之前一文不值。竞争对手不会等你。
重写通常伴随着“这次一定要设计完美”的野心——这正是“夸夸其谈未来性”的企业级版本，工期必然失控。

Fowler 在第 1 版就引用过这个故事来论证：重构的价值恰恰在于它是重写的替代品。用持续的小步重构，让烂代码在“一直保持可交付”的状态下逐步变好，是风险唯一可控的路径。

当然要有公允的注脚：后来 Mozilla 代码确实成了 Firefox 的底子，长期看那次重写并非全无产出。但作为商业决策，Netscape 公司没活到收获的那天——这正是 Joel 论点最残酷的部分。

8. 带走的清单

8.1 核心心智模型（五句话）

重构 = 不改变可观察行为的结构调整；目标不是美，是让下次修改更便宜。
两顶帽子：加功能和重构永不同时戴。
坏味道清单 = 启发法清单：闻到味道 → 查名录 → 用对应手法。味道是提示，不是罪状。
刷牙，不大扫除：小步、频繁、顺手；童子军军规，每次提交留代码更干净一点。
先补测试，再动刀；测试红了先撤销，不带着红灯往前走。

8.2 新人避坑指南

坑一：把重构当借口拖延交付。 重构是加功能的加速器不是挡箭牌。每次重构前问自己：这步能让手头这个需求更快落地吗？
坑二：没有测试就动祖传代码。 先补测试。补测试时发现代码不可测，先做最小限度的可测性重构（提炼函数、依赖注入），别一步到位。
坑三：PR 里混着“重构 + 新功能 + 修 bug”。 reviewer 无法区分行为变化来自哪里。拆 PR，或者至少拆 commit。
坑四：看到 switch 就上多态，看到简单类就套设计模式。 夸夸其谈未来性也是坏味道。YAGNI。
坑五：迷信“等我有整块时间再重构”。 那一天永远不会来。能融进日常的小重构才有复利，立项式重构大概率变成 Netscape 式豪赌。
坑六：改名字嫌麻烦。 IDE 的安全重命名几秒钟一次，这是全软件业性价比最高的操作，没有之一。

8.3 一页速查：味道 → 手法

mindmap
  root((坏味道<br/>→<br/>重构手法))
    代码冗余
      重复代码 → 提炼函数
      过长函数 → 提炼函数
      过长参数列表 → 引入参数对象
      数据泥团 → 提炼类
      冗赘元素 → 内联函数
    职责错配
      依恋情结 → 搬移函数
      发散式变化 → 拆分阶段
      霰弹式修改 → 搬移函数聚拢
      内幕交易 → 搬移函数减少私聊
      过大的类 → 提炼类
    类型与状态
      基本类型偏执 → 以对象取代基本类型
      重复的switch → 以多态取代条件表达式
      全局数据 → 封装变量
      可变数据 → 拆分变量/值对象
      临时字段 → 提炼类
    意图不清
      神秘命名 → 改名
      注释 → 提炼函数让代码自解释
      复杂表达式 → 提炼变量
      消息链 → 隐藏委托关系
      中间人 → 移除中间人

9. 写在最后

《重构》这本书最被低估的一点：它表面上是一本“手法名录”，实际上是一套把代码质量从“良心活”变成“机械活”的方法论。坏味道给你嗅觉，名录给你机械步骤，测试给你安全网，两顶帽子给你节奏——四样东西配齐，重构就从“需要勇气和天赋的大工程”变成了“不需要下决心就能做的日常小事”。

而日常小事的复利是惊人的。每天让代码干净 1%，一年后它和自然腐化的代码库就是两个物种。这本书 1999 年出第 1 版、2018 年出第 2 版，横跨二十年依然是软件工程必读，原因无他：代码会腐化是永恒规律，而刷牙永远有效。

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

Sun, 04 Sep 2022 10:00:00 +0800

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

写这篇的动机很直接：「我感觉自己逻辑思维很弱」是我听过最多、也最难回答的自我评价。它太大了，大到无从下手。
这篇的思路：先把「逻辑思维」这个模糊的大词拆成五种具体的、可单独训练的能力，再给每种能力配书、配练习、配检查清单，最后拼成一份 12 周计划。跟着清单做就行，不用自己设计训练方案。

第一篇先诊断：逻辑思维不是一个东西，是五个东西

「逻辑思维弱」是个无法改进的表述——就像说「我身体不好」而不说「我 5 公里跑不下来」。先拆开：

flowchart TD
    L["逻辑思维"] --> A["1 概念清晰<br/>说的每个词都有明确所指<br/>症状: 需求评审说不清<br/>变量命名含糊"]
    L --> B["2 推理链条<br/>从前提一步步走到结论<br/>症状: 排查 bug 靠猜<br/>改 A 坏 B 想不到为什么"]
    L --> C["3 抽象分层<br/>能切换粒度看问题<br/>症状: 代码揉成一团<br/>说不清系统架构"]
    L --> D["4 边界意识<br/>看到输入就想边界与异常<br/>症状: 上线后被空指针/<br/>越界/并发打脸"]
    L --> E["5 因果辨析<br/>区分相关/因果/巧合<br/>症状: 复盘归错因<br/>优化没效果"]

对照一下，你的「弱」大概率集中在其中两三个上。诊断的意义在于：五种能力的训练方法完全不同，混着练等于白练。

能力	最痛的日常场景	对应训练
概念清晰	需求理解偏差、命名糟糕	定义练习、费曼讲解
推理链条	debug 靠蒙、日志看不出因果	假设-验证法、画调用链
抽象分层	代码越写越乱、讲不清架构	分层画图、重构练习
边界意识	边界 bug 反复出现	防御性 checklist、测试先行
因果辨析	复盘甩锅、优化玄学	五问法、对照实验

思考与感悟之一：编程本质是「用精确的语言描述精确的推理」。IDE 不会因为你概念模糊而报错，编译器不会因为你因果搞错而拒绝构建——代码能跑通和逻辑是对的之间，隔着一万个线上事故。这也是为什么逻辑思维的训练必须在代码之外单独进行。

第二篇书单：按能力分级，别从《离散数学》开始

2.1 入门层：先把「讲道理」的基本功补上

书	练什么	怎么读
《简单逻辑学》（D.Q. 麦克伦尼）	概念清晰 + 推理链条	薄，一周读完。重点看「论证的前提与结论」「常见谬误」两章
《学会提问》（尼尔·布朗）	因果辨析	批判性思维入门，重点看「证据的效力」「有没有替代原因」
《金字塔原理》（芭芭拉·明托）	抽象分层（表达侧）	结论先行、以上统下。对写技术方案、汇报、写博客立竿见影

2.2 进阶层：直接长在编程上的思维

书	练什么	怎么读
《怎样解题》（波利亚）	推理链条	数学书的外壳，debug 的内核。「弄清问题→拟定计划→执行→回顾」就是排查 bug 的标准流程
《系统之美》（德内拉·梅多斯）	抽象分层 + 因果辨析	库存、流量、队列都是系统。看完你会用「反馈回路」的眼光看重试风暴、缓存雪崩
《程序员修炼之道》	全部五种	工程场景化的思维训练，DRY、正交性、曳光弹，每一条都在教你怎么把问题切干净

2.3 硬核层：可选，别勉强

《离散数学及其应用》：命题逻辑、集合、图论——编程的数学地基。只建议读前三章，当工具书查。
《思考，快与慢》：知道大脑什么时候在骗你。和编程不直接相关，但和「复盘归错因」直接相关。

选书原则：一次只读一本，读完一本书的每一章都要落到「这周我在代码里用了它哪一点」。 读而不用的思维书，和收藏夹里的技术文章没有区别。

flowchart LR
    A["入门层<br/>讲道理的基本功"] --> B["进阶层<br/>长在编程上的思维"]
    B --> C["硬核层<br/>数学地基 可选"]
    A -.->|"每章落到<br/>一次代码实践"| P["不是读完<br/>是用完"]
    B -.-> P
    style P fill:#e8f4e8

第三篇日常训练法：把练习藏进你每天都在做的事里

刻意练习的关键不是额外抽两小时，而是改造已有的工作动作。五个场景，每个配一个可检查的动作：

3.1 写代码前：先说清，再动手（练概念清晰）

接到需求后，强制自己写三句话再开编辑器：

这个功能的输入是什么？（精确到字段和类型）
输出是什么？什么情况算成功？
有哪三种必然失败的情况？

写不出来，就是概念还没清晰，回去问。这一步能拦掉一半的返工。

3.2 排查 bug：假设-验证法（练推理链条）

禁止「改一下试试」。用 debug 日志模板强制走流程：

写下假设：「我认为是 X 导致 Y，因为 Z」
写下验证方式：看什么日志/加什么断点能证实或证伪
验证结果与假设不符时，先怀疑假设，不要怀疑现象
修复后写下：根因是什么？为什么之前的推理没走到这？

波利亚的「回顾」一步，90% 的人会跳过——而推理能力的增长恰恰只发生在这一步。

3.3 讲清楚一个模块：费曼技巧（练抽象分层）

每月一次，挑你负责的一个模块，画一张三层图讲给同事（或 AI）听：

第一层：一句话说清它是干什么的
第二层：三个以内的子模块 + 它们之间的关系
第三层：被追问时才能展开的细节

讲卡壳的地方，就是你分层的薄弱处。能给 AI 把一个需求描述到它一次生成正确代码，是概念清晰度的绝佳试金石——prompt 写不清楚，多半是自己也没想清楚。

3.4 Code Review：五问清单（练因果辨析）

这个改动解决了什么问题？（还是先有的方案？）
问题和改动之间是因果还是相关？（「上次加了缓存就好了」是相关，不是因果）
有没有替代原因能解释这个现象？
这个改动的副作用边界在哪？
如果它是错的，我们多快能发现？

3.5 复盘：只问「为什么链」（练因果辨析）

线上事故复盘禁用「我疏忽了」「运气不好」这类不可证伪的词。只允许五问法往下钻，直到钻出一个可执行的流程或工具改进为止。「粗心」不是根因，「为什么粗心能穿过所有防线到达线上」才是。

思考与感悟之二：所有训练法的共同点是「把隐式思维变成显式文字」。脑子里的推理可以偷步、可以跳步、可以自我欺骗，落在纸上的推理不能。写作是逻辑思维最便宜的压力测试。

第四篇 12 周刻意练习计划

每周一个主题。规则：周末用 30 分钟对照自检清单打分，三项里两项不达标，下周重复同一主题。宁可 12 周练成 6 项，不要 12 周路过 12 项。

flowchart TD
    subgraph P1["第 1-4 周 概念与推理"]
        W1["W1 定义练习<br/>读《简单逻辑学》<br/>给 10 个日常用词写精确定义"]
        W2["W2 需求拆解<br/>每个需求先写输入/输出/失败<br/>再动手"]
        W3["W3 假设-验证 debug<br/>每个 bug 走完整模板"]
        W4["W4 谬误识别<br/>读《学会提问》<br/>在技术讨论里找出 5 个逻辑谬误"]
    end
    subgraph P2["第 5-8 周 抽象与边界"]
        W5["W5 金字塔表达<br/>读《金字塔原理》<br/>写 2 篇结论先行的技术方案"]
        W6["W6 费曼讲解<br/>画 1 张三层模块图并讲出来"]
        W7["W7 边界清单<br/>给负责的接口建防御性 checklist"]
        W8["W8 测试先行<br/>一个完整功能 TDD 写下来"]
    end
    subgraph P3["第 9-12 周 因果与系统"]
        W9["W9 复盘训练<br/>读《系统之美》<br/>找 1 个旧事事故做五问法复盘"]
        W10["W10 对照实验<br/>一次性能优化用基准数据说话"]
        W11["W11 解题流程<br/>读《怎样解题》<br/>按四步解 5 道算法题并写回顾"]
        W12["W12 综合输出<br/>写 1 篇技术博客<br/>把 12 周里最有体感的一条讲透"]
    end
    P1 --> P2 --> P3

每周自检清单（通用模板）

本周的书读了吗？哪一章的观点我这周真的用了？
本周的练习动作做了几次？（写次数，不写「做了」）
有没有一个具体场景，我能说出「如果没有这周的训练，我会做错」？

两个提醒

不要同时练多项。认知资源有限，一周一个主题已经很难。觉得慢，说明做对了——肌肉记忆的形成从来是慢的。
输出强制闭环。第 12 周的博客不是可选项。能把「我怎么练的」讲清楚，本身就是五种能力的综合考试。

思考与感悟之三：逻辑思维不是天赋，是可分解、可练习、可度量的技能组——和学一门框架没有本质区别。区别在于框架三个月过期，这套东西跟你三十年。投资回报率不在同一个数量级上。

附：一句话总纲

诊断先行：先弄清弱在五种能力的哪几种，再选训练。
书不在多：一本一用，每章落到代码里才算读过。
改造日常：练习藏进写需求、debug、CR、复盘里，不靠额外抽时间。
显式化：把推理写下来，写下来就不能骗自己。
12 周起评：周末自检，不达标就重复，最后以一篇博客闭环。

程序员成长 on 方糖猫Blog

知止有定，能择其要

知止有定，能择其要

一、选资产：职业资本地图，先盘点再修炼

先盘点：每层只记三行

下一步练哪一层：一个粗算公式

三条路线：地图有层，还得有路

二、看定价：AI 时代的重新定价

一条分工纪律：AI 做便宜的事，人做贵的事

练兵场正在消失：自己动手造回来

三、选环境：选择大于努力

先选赛道，再选团队

把四个判据提前到面试：反问清单

什么时候不该马上走：先算切换成本

四、加杠杆：补上输出这一环

写、讲、教、建：四级做法，杠杆从小到大

输出的三道护栏：冷启动豁免、质量门槛、保密红线

五、对账：双仪表盘

先排除环境干扰：四根针都不是纯个人指标

六、落地：一条戒律、最小配置、两档预算

戒律：每次内省，必须改一个现实动作

最小配置：三件内功日课，四件外功功课

两档时间预算：保底档与攻关档

七、边界：这套体系什么时候不适用

仪表盘不动的另一种解释：力不足，还是命暂不出价

八、次第（外功版）

附：出处与延伸阅读

《重构》学习总结：改善既有代码的设计，把日课做成习惯

《重构》学习总结：改善既有代码的设计，把日课做成习惯

0. 写在前面：重构不是大扫除，是刷牙

1. 一句话理解重构：不改变可观察行为的结构调整

1.1 两顶帽子：加功能和重构不同时戴

2. 坏味道清单：程序员的启发法清单

2.1 神秘命名（Mysterious Name）

2.2 重复代码（Duplicated Code）

2.3 过长函数（Long Function）

2.4 过长参数列表（Long Parameter List）

2.5 全局数据（Global Data）与可变数据（Mutable Data）

2.6 发散式变化与霰弹式修改（Divergent Change / Shotgun Surgery）

2.7 依恋情结与数据泥团（Feature Envy / Data Clumps）

2.8 基本类型偏执与重复的 switch（Primitive Obsession / Repeated Switches）

2.9 中间人与消息链（Middle Man / Message Chains）

2.10 注释（Comments）

2.11 其余味道速查表

3. 核心重构手法：七招走天下

3.1 提炼函数（Extract Function）

3.2 内联函数（Inline Function）

3.3 搬移函数（Move Function）

3.4 提炼变量（Extract Variable）

3.5 封装记录（Encapsulate Record）

3.6 以多态取代条件表达式（Replace Conditional with Polymorphism）

3.7 拆分阶段（Split Phase）

4. 全书导读案例：statement 计费重构走查

5. 重构与测试：先补测试，再动刀

6. 重构的时机与节奏：融进日常，而不是立项

6.1 三次法则与“顺手重构”

6.2 破窗效应与童子军军规

6.3 什么时候不重构

7. 大规模重写的教训：Netscape 之死

8. 带走的清单

8.1 核心心智模型（五句话）

8.2 新人避坑指南

8.3 一页速查：味道 → 手法

9. 写在最后

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

程序员逻辑思维训练手册：书单、方法与 12 周刻意练习计划

第一篇 先诊断：逻辑思维不是一个东西，是五个东西

第二篇 书单：按能力分级，别从《离散数学》开始

2.1 入门层：先把「讲道理」的基本功补上

2.2 进阶层：直接长在编程上的思维

2.3 硬核层：可选，别勉强

第三篇 日常训练法：把练习藏进你每天都在做的事里

3.1 写代码前：先说清，再动手（练概念清晰）

3.2 排查 bug：假设-验证法（练推理链条）

3.3 讲清楚一个模块：费曼技巧（练抽象分层）

3.4 Code Review：五问清单（练因果辨析）

3.5 复盘：只问「为什么链」（练因果辨析）

第四篇 12 周刻意练习计划

每周自检清单（通用模板）

两个提醒

第一篇先诊断：逻辑思维不是一个东西，是五个东西

第二篇书单：按能力分级，别从《离散数学》开始

第三篇日常训练法：把练习藏进你每天都在做的事里