引言：工程信条的演变与重新评估
在软件工程领域，许多 "最佳实践" 随着时间的推移变成了不容置疑的信条。从 "每个 PR 都必须审查" 到 "微服务粒度越小越好"，这些信条往往基于特定时期的经验总结，但在快速变化的技术环境中，它们需要基于实证数据进行重新评估。
2025 年的研究表明，许多传统工程实践已经不再适应当前的技术环境和业务需求。本文基于最新的实证研究，系统分析五个需要淘汰的过时工程信条，并为每个信条提供基于数据的现代替代方案。
微服务粒度：从 "越小越好" 到基于能耗和性能的实证决策
过时信条：微服务粒度越小越好，每个服务应该只做一件事。
实证数据：2025 年 11 月发表在 arXiv 的研究《How Does Microservice Granularity Impact Energy Consumption and Performance?》通过控制实验揭示了令人惊讶的结果。在大型系统中，细粒度微服务相比粗粒度服务：
- 能耗增加 13%：平均多消耗 461 焦耳能量
- 响应时间增加 14%：平均增加 5.2 毫秒延迟
- 请求负载影响显著：从 40 请求 / 秒增加到 400 请求 / 秒时，能耗增加 23%，响应时间增加 98%
现代替代方案：
- 基于业务能力而非技术边界：服务粒度应该与业务能力对齐，而不是追求技术上的最小化
- 能耗作为设计约束：将能耗指标纳入架构决策框架，特别是在大规模部署时
- 动态粒度管理：采用如 Granulify 这样的连续粒度管理方法，根据系统演化动态调整服务边界
可落地参数：
- 单个微服务的代码行数建议在 5000-15000 行之间（根据业务复杂度调整）
- 服务间调用延迟不应超过业务可接受的 SLA 的 20%
- 监控每个服务的能耗指标，设置阈值告警
代码审查：从强制审查到基于风险的自主合并
过时信条：每个 Pull Request 都必须经过至少 1-2 名同事的审查才能合并。
实证问题：强制性的代码审查流程虽然能提高代码质量，但显著降低了开发速度。在需要快速迭代的环境中，这种延迟可能成为瓶颈。
现代替代方案：Pylon 公司的实践提供了有价值的参考 —— 工程师自主合并代码，仅在以下情况下请求审查：
- 高风险变更：涉及核心业务逻辑、安全敏感操作或大规模重构
- 需要专业知识输入：涉及不熟悉的领域或技术栈
- 新人入职期：前 3-6 个月的新工程师需要更多指导
实证支持的平衡点：
- 审查效率指标：测量 Inspection Rate（审查发现的问题数 / 审查时间）和 Defect Density（缺陷密度）
- 自动化先行：使用工具自动化代码风格检查、基础安全扫描和测试覆盖率验证
- 结对编程替代：对于复杂功能，结对编程可能比异步审查更有效
可落地参数：
- 高风险变更定义：涉及超过 50 个文件的修改、影响超过 10% 用户的功能、安全权限变更
- 审查响应时间 SLA：高风险变更 24 小时内，普通变更 48 小时内
- 自主合并权限：工程师入职 6 个月后，通过代码质量考核可获得自主合并权限
开发流程：从冲刺到可持续的工作节奏
过时信条：2-4 周的冲刺是现代敏捷团队的标准工作方式。
问题分析：传统的冲刺模式往往导致：
- 计划与执行的脱节：冲刺计划会上的承诺与实际完成情况存在差距
- 创造力消耗：持续的冲刺节奏消耗工程师的创造力和长期思考能力
- 技术债务积累：为了完成冲刺目标，技术债务被不断推迟
现代替代方案：Basecamp 的 Shape Up 方法提供了不同的视角：
- 6 周工作周期：每个周期专注于一个完整的项目或功能集
- 周期间休息期：每个周期结束后有 1-2 周的 "冷却期"，用于修复问题、探索性工作和技术债务清理
- 可持续节奏：强调 "平静工作，明智决策"，而非 "全力冲刺"
实证调整框架：
- 周期长度：根据项目复杂度调整，复杂项目 6-8 周，简单项目 3-4 周
- 休息期比例：工作周期与休息期的比例建议为 4:1 或 5:1
- 并行项目数：团队同时进行的项目不超过 2 个，避免上下文切换开销
可落地参数：
- 周期成功率目标：85% 的周期按时交付核心功能
- 技术债务预算：每个周期分配 15-20% 的时间用于技术债务清理
- 团队满意度指标：定期测量工程师的工作满意度和倦怠水平
工具与实践的平衡使用
功能标志：从 "每个变更都需要" 到选择性使用
过时信条：每个代码变更都应该放在功能标志后面，以便随时回滚。
实证问题：功能标志的滥用导致：
- 代码复杂度增加：数百个活跃标志使代码难以理解和测试
- 虚假安全感：开发者可能错误配置标志，导致隐藏的代码在生产环境运行
- 测试负担加重：需要测试所有标志组合，组合爆炸问题严重
现代实践：
- 分层标志策略：
- Level 1：高风险变更（新功能、架构变更）必须使用标志
- Level 2：中等风险变更（UI 改进、性能优化）建议使用标志
- Level 3：低风险变更（bug 修复、文案更新）可直接发布
- 标志生命周期管理：
- 新标志必须在 3 个月内评估是否移除
- 超过 6 个月未移除的标志需要架构委员会审批
- 定期（每季度）清理过期标志
第三方依赖：从 "不要重复造轮子" 到风险感知的依赖管理
过时信条：永远不要重复造轮子，优先使用现有包。
风险案例：left-pad 事件（2016 年）和 is-even 包（每周 16 万次下载）揭示了过度依赖的风险。
现代依赖管理框架：
-
依赖分类：
- A 类：核心基础设施（数据库驱动、框架核心）
- B 类：业务逻辑辅助（日期处理、字符串操作）
- C 类：便利工具（小功能、UI 组件）
-
决策矩阵：
依赖必要性评估： - 功能复杂度：高 → 考虑使用现有包 - 安全敏感性：高 → 倾向自行实现 - 维护负担：高 → 倾向使用成熟包 - 团队熟悉度：低 → 倾向自行实现 -
LLM 时代的新考量：
- 使用 LLM 快速实现简单功能可能比引入依赖更安全
- 但需要建立代码质量检查流程
代码注释：从 "自解释代码" 到战略注释
过时信条：如果需要注释，代码就太复杂了，应该重写。
现代理解：代码应该尽可能自解释，但战略性的注释可以：
- 解释 "为什么" 而不是 "什么"（业务决策、历史背景）
- 记录已知限制和边界条件
- 提供性能优化或复杂算法的解释
注释指南：
- 必须注释：业务规则、安全考虑、性能关键路径
- 建议注释：复杂算法、非直观实现、外部依赖假设
- 避免注释：重复代码意图、琐碎的实现细节
基于实证数据的工程决策框架
决策流程重构
传统的工程决策往往基于经验或 "行业最佳实践"，现代工程团队需要建立基于实证数据的决策框架：
-
问题定义阶段：
- 明确决策的影响维度：性能、可维护性、开发速度、运营成本
- 收集相关实证数据：学术研究、行业报告、内部历史数据
-
方案评估阶段：
- 建立评估矩阵，量化各方案的优缺点
- 进行小规模实验或 A/B 测试收集数据
- 考虑长期影响而不仅是短期收益
-
决策执行阶段：
- 制定明确的实施计划和回滚策略
- 建立监控指标，持续跟踪决策效果
- 定期回顾和调整决策
监控与反馈循环
每个工程实践都应该有对应的监控指标：
-
微服务粒度监控：
- 服务间调用延迟和错误率
- 单个服务的资源利用率（CPU、内存、网络）
- 部署频率和成功率
-
代码审查效果监控：
- 平均审查时间
- 审查发现的问题类型分布
- 审查后引入的缺陷率
-
开发流程健康度监控：
- 周期交付成功率
- 工程师满意度调查结果
- 技术债务趋势
文化转变：从信条到实证
淘汰过时工程信条的最大挑战往往是文化层面的：
- 建立心理安全：工程师应该能够质疑现有实践而不担心被指责
- 鼓励实验文化：允许团队尝试新的工作方式，即使可能失败
- 数据驱动对话：用数据而非观点支持决策建议
- 持续学习机制：定期分享新的研究成果和行业趋势
结论：走向实证驱动的软件工程
软件工程正在从基于经验和信条的实践，转向基于实证数据和系统思考的现代方法。2025 年的研究为我们提供了重新评估传统信条的机会：
- 微服务粒度需要平衡模块化与性能 / 能耗成本
- 代码审查应该基于风险而非一刀切的强制要求
- 开发流程需要支持可持续的工作节奏而非无休止的冲刺
- 工程工具应该选择性使用，避免过度工程化
最重要的是，每个工程决策都应该基于具体上下文 —— 团队规模、业务领域、风险承受能力和可用资源。没有放之四海而皆准的 "最佳实践"，只有最适合当前环境的 "恰当实践"。
通过建立实证驱动的决策框架，持续监控实践效果，并保持对新技术和研究的开放态度，工程团队可以摆脱过时信条的束缚，构建更高效、可持续和创新的软件交付能力。
资料来源：
- "5 engineering dogmas it's time to retire" (Manager.dev, 2025-12-16)
- "How Does Microservice Granularity Impact Energy Consumption and Performance? A Controlled Experiment" (arXiv, 2025-11-26)
- "Continuously Managing Microservice Granularity: An Evidence-Based Industrial Approach" (SBES, 2025-09-22)
- "Top 7 Code Review Best Practices For Developers in 2025" (Qodo.ai, 2025-03-14)