软件开发中的三次法则

文章主旨：作者主张“事不过三”原则，将第三次重复视为量变到质变的临界节点，强调当同一问题或操作第三次出现时，应主动进行优化、固化或自动化，以从根本上解决问题并预防技术债务积累。

关键要点：

1. 第三次出现代码修改、修复失败、相似代码或同类错误时，应分别进行重构、更换方法、封装复用或优化工作流程。
2. 第三次发现评审同类问题、会议无结论、性能瓶颈或环境配置问题，应更新检查清单、明确决策机制、开展专项优化或编写自动化脚本。
3. 第三次手动执行发布、向他人解释代码、代码审查发现同类问题，应接入CI/CD、补充文档、纳入编码规范或静态分析规则。
4. 第三次手动回归测试、绕过流程执行热修复、重复编写提示词，应补充自动化测试、优化应急流程、封装提示词模板。
5. 第三次手动校验同类AI输出，应搭建自动化校验规则与巡检脚本。

内容结构：

第一部分：提出“事不过三”原则，定义第三次为主动优化的临界点。

第二部分：列举15个具体应用场景（涵盖代码、流程、测试、AI工程等），均为“当第三次…则…”的条件与行动建议，例如对代码重构、缺陷更换方法、重复功能封装、工作流程优化、环境配置自动化等。

第三部分：总结强调，无论是传统软件开发还是AI工程落地，在第三次重复时主动干预，可提前消解技术债务、规范流程、降低重复劳动，使团队从被动救火转向主动治理。

文章总结：本文鼓励开发者和团队以“第三次”为行动触发点，通过系统化改进将重复劳动转化为治理机制，持续提升研发质量与效率。

DevOps已死？2024年的DevOps将如何发展

了解更多

麦哲思科技任甲林

查看原文：软件开发中的三次法则

文章来源：

麦哲思科技任甲林

扫码关注公众号