编程解决”把功能写出来”，软件工程解决”写出来之后还能不能长期活下去”。本文从工程与编程的区别谈起，依次讨论代码审查的价值、技术债的管理视角、文档与注释的边界，以及简单性优先的两条原则。

核心概念：工程与编程的区别

1968 年 NATO 会议提出”软件危机”一词，背景是硬件能力暴涨而软件交付大面积失控——超期、超支、质量堪忧，”软件工程”由此诞生。IEEE 对它的定义强调系统化、规范化、可量化；用大白话说，就是把工程方法应用于软件开发，在更少的资源消耗下产出更好、更易维护的软件。

编程关注算法与实现，是点状问题；工程则引入了时间维度：代码会被几十人改动、在线上跑五年、需求翻几十倍。工程思维的核心是把”可维护性”当成一等需求——写下每一行代码时，都在为六个月后的修改者（通常就是自己）投资。瀑布、迭代、敏捷只是组织反馈的不同节奏，复用、分治、逐步演进、权衡折中才是跨模型通用的基本策略。

实践要点

代码审查的价值

Code Review 常被误解为”挑错”，它的真实收益有三层：一是质量，缺陷在进入测试之前被拦截，修复成本最低；二是知识扩散，评审让系统知识不只存在于作者脑中，降低单点离职风险；三是标准对齐，命名、分层、异常处理的团队约定靠评审一代代传承。做好评审的前提是变更足够小——几百行以内的提交才可能被认真读完；评审意见对事不对人，讨论”这段代码”而不是”你这个人”。

技术债的管理视角

技术债（Technical Debt）是 Ward Cunningham 提出的隐喻：为赶进度牺牲内部质量，换来短期速度，代价是后续开发被持续收取”利息”。负债本身不是错，错的是不记账。健康的做法是：显式登记债务（记在 issue 里，而不是脑子里）；区分”审慎的债”（为快速验证市场主动借）与”鲁莽的债”（图省事欠下）；每个迭代留出固定比例时间偿还利息最高的部分。只借不还会让团队速度越来越慢，一律不借则可能错失市场窗口，两者都是缺乏管理。

文档与注释的边界

注释解释”为什么”，代码表达”做什么”。i++ // 递增 i 是纯噪声；而”这里不用浮点是为避免汇率计算的精度丢失”属于无法从代码推断的决策背景，值得留下。文档同理：架构决策用 ADR（Architecture Decision Record）记录背景、候选方案与结论，一次写清长期受益；而”如何调用这个接口”这类易变信息，应交给 OpenAPI 契约与测试自动生成，手写版本只会快速过期。判断标准很简单：这份文档三个月后还有人维护吗？没有，就换更轻的载体。

简单性优先：KISS 与 YAGNI

KISS（Keep It Simple, Stupid）提醒我们：简单不是简陋，而是没有多余的复杂度。YAGNI（You Aren’t Gonna Need It）对抗的是预防性设计——为假想需求预留的扩展点，九成永远不会被用到，却从第一天起就收取理解成本。落地方式：先让当前需求下的测试通过，抽象留到第三次重复出现时再提炼（Rule of Three）；框架级的灵活性只服务于真实存在的变化点。

常见误区

  • 把流程当工程：堆模板、填表格，却没人对验收与复盘负责——形式主义不等于工程化。
  • 用忙碌程度或代码行数衡量产出，忽视交付周期、缺陷逃逸率、故障恢复时间这些真正反映工程能力的指标。
  • 文档崇拜与零文档两个极端：前者维护不起，后者交接即灾难。
  • 把技术债当羞耻藏而不报，任其在暗处复利。

小结

  • 工程的核心命题是时间维度下的可维护性，一切实践都在为未来的修改降本。
  • 评审既拦截缺陷也扩散知识；技术债要记账、分类、定期偿还。
  • 注释写”为什么”、文档抓稳定的决策；KISS 与 YAGNI 是对抗复杂度的日常武器。