3.3 编码实现：车间装配与走查

3.3 编码实现：车间装配与走查

图纸齐了，装配车间开工。编码是多数读者的主场，本节不教语法，讲三件让代码"可被团队接住"的事：规范为什么值得守、单元测试怎么才算到位、代码走查怎么开才不是走过场。本节往上承接设计图纸的约束，往下为测试站提供可试跑的零件。

装配车间的三条纪律

**纪律一：守规范，但知道规范为什么存在。**命名、缩进、注释风格这类表面规范，价值不在好看，而在降低阅读成本——代码被读的次数远多于被写的次数。更值钱的是结构规范：一个函数只做一件事、嵌套不超过几层、魔法数字命名成常量。现代开发环境（IDE 与格式化插件）已经把表面规范自动化了，人的注意力应该留给结构。

**纪律二：自己先验货。**单元测试是开发者交件前的自检：每个函数在提交前有测试覆盖它的正常路径与边界。边界是最常漏的——金额零、空列表、临界上限。看一段云梯运费分摊的真实例子：

分摊函数：按各仓货量把整笔优惠摊到仓库，金额保留两位。
  输入：总额 discount = 100.00 元
        各仓货量 shares = [1, 1, 1]（三个仓库均摊）

朴素实现：每仓得 100.00 / 3 = 33.33 元，合计 99.99 元
  ——凭空少了 0.01 元，对账必然出错。

修正实现：逐仓累计法
  仓1：round(100.00 × 1/3) = 33.33
  仓2：round(100.00 × 2/3) - 33.33 = 66.67 - 33.33 = 33.34
  仓3：100.00 - 33.33 - 33.34 = 33.33
  合计恰好 100.00 元。

教训：单元测试只要写了"均摊三仓合计守恒"这一条，
朴素实现的缺陷当场暴露。边界与守恒类断言，
是自检里性价比最高的投资。
​

**纪律三：合入前过走查。**代码走查（评审）是他检，目的排序很明确：先看对不对（逻辑、边界、并发），再看可维护性（命名、结构、重复），最后才是风格——风格问题应该交给工具，不值得消耗人的注意力。

一次真实的走查

走查要有清单、有记录、有结论，三样缺一就容易沦为刷通过率。云梯的走查清单核心项：

走查记录 · 请求 RE-1187 · 运费分摊修正
  走查人：架构师 · 后端同事乙
  发现：
    1）[必须修] 仓3 采用余额法，与图纸的逐仓累计法不一致，
       极端数据下与仓2 结果对不上。（逻辑）
    2）[必须修] shares 为空列表时函数返回 NaN。（边界）
    3）[建议]   精度常量 0.01 重复出现三次，提为常量。（可维护）
  结论：修改后复走，仅复查前两条。
  复走结果：两条已修，合入主干。
​

注意记录里的分级：必须修拦住合入，建议不拦。走查的通行标准是"问题分级清楚、复走范围收敛"——没有分级的走查会滑向两个深渊：全部放行，或者为一条注释吵一个下午。

别把走查开成批斗会

走查文化决定它的生死。三条经验值得带走：评审对代码不对人，结论写"这段逻辑"不写"你的问题"；一次走查请求控制在可承受的规模——几百行的变更，评审质量随行数上升而骤降，大变更宁可拆成几批；发现过重要缺陷后，全组值得花十分钟把这类缺陷写进清单，让一次教训变成所有人的检查项。

⚠️ 走查最大的暗坑是形式化：走查人一天被派二十个请求，只能点"同意"。与其如此，不如明确告诉团队——今天只有三个请求能被认真看，其余明天来；积压的诚实，好过放行的虚假。

走查的账：拦截率与成本

走查值不值，也用数字说话。云梯统计过一个季度的走查台账：走查提出的发现共一百三十条，其中判定为"必须修"的四十一条——事后复盘，这四十一条若流入测试或线上，平均每条修复成本至少是走查阶段的三到五倍（安全类更高）。换算下来，团队在走查上投入的每一个人时，回收约两个人时以上，还没算线上事故的品牌与信任损耗。另一组数字同样有意思：新入职成员参与的走查，其"必须修"发现率反而更高——不是新人眼光更毒，而是老成员对"作者风格"的容忍在悄悄抬高阈值。走查配对时新老搭配，拦截率与知识传递两头的账都赚。

从个人技艺到团队底盘

编码这一站的终极目标，是让代码质量不再依赖某个人的状态。三件小事性价比极高：其一，统一格式化配置进版本库，编辑器加载即生效，风格争论永久退场；其二，把"本仓库高频缺陷类型"贴成走查清单置顶——云梯的前三名长期是边界值、并发时序、异常吞没，清单每季度按缺陷榜刷新；其三，建立"复杂度预算"——新函数超过一屏、嵌套超过三层要写理由，理由写不出就拆。预算制比"代码要优雅"这类口号有用，因为它给了一个可判定的线。

两个高频疑问

问：结对编程要不要推？ 它本质是实时走查：缺陷当场拦、知识实时传，成本是双倍工时。适用的场景很具体——核心模块初建、新人上手、疑难缺陷攻坚；日常普通变更，异步走查的性价比更高。按任务性质选用，不必全员全时推行。

问：走查发现的问题该不该当场改？ 小改（命名、一行逻辑）当场改完复验，减少往返；大改（结构、接口）进变更记录排期。当场改的诱惑在于省事，风险在于评审者看不到修复后的完整上下文——修复也应有自己的"提交与复验"，哪怕只多两分钟。

本节要点回顾

• 编码纪律三件套：守规范懂缘由、自测先验货、合入过走查。
• 单元测试优先覆盖边界与守恒类断言，均摊守恒一例胜过十行注释。
• 走查先看对错再看可维护性，风格交给工具；发现必须分级，复走只看必改项。
• 走查记录是过程资产：编号、发现、结论、复走结果缺一不可。
• 文化决定走查生死：对代码不对人、控制请求规模、教训进清单。

零件装配完毕，下一站把它们挂上整车，拉去联调试跑。