软件开发中的三次法则
发布于 2026-06-13
192
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章主旨:作者主张“事不过三”原则,将第三次重复视为量变到质变的临界节点,强调当同一问题或操作第三次出现时,应主动进行优化、固化或自动化,以从根本上解决问题并预防技术债务积累。
关键要点:
- 第三次出现代码修改、修复失败、相似代码或同类错误时,应分别进行重构、更换方法、封装复用或优化工作流程。
- 第三次发现评审同类问题、会议无结论、性能瓶颈或环境配置问题,应更新检查清单、明确决策机制、开展专项优化或编写自动化脚本。
- 第三次手动执行发布、向他人解释代码、代码审查发现同类问题,应接入CI/CD、补充文档、纳入编码规范或静态分析规则。
- 第三次手动回归测试、绕过流程执行热修复、重复编写提示词,应补充自动化测试、优化应急流程、封装提示词模板。
- 第三次手动校验同类AI输出,应搭建自动化校验规则与巡检脚本。
内容结构:
第一部分:提出“事不过三”原则,定义第三次为主动优化的临界点。
第二部分:列举15个具体应用场景(涵盖代码、流程、测试、AI工程等),均为“当第三次…则…”的条件与行动建议,例如对代码重构、缺陷更换方法、重复功能封装、工作流程优化、环境配置自动化等。
第三部分:总结强调,无论是传统软件开发还是AI工程落地,在第三次重复时主动干预,可提前消解技术债务、规范流程、降低重复劳动,使团队从被动救火转向主动治理。
文章总结:本文鼓励开发者和团队以“第三次”为行动触发点,通过系统化改进将重复劳动转化为治理机制,持续提升研发质量与效率。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 937.1K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
我说CMMI之一:CMMI是什么
我说CMMI之一:CMMI是什么有些朋友没有接触过CMMI,正在学习CMMI,CMMI本身的描述比较抽象,所以,读起来有些费劲。有些朋友实施过CMMI,但是可能存在对CMMI的一些误解,因此我想说说我理解的CMMI,供各位参考。在写这些材料时,我假想我对面坐着一位初学者或者是受错误思想洗过脑的实施过CMMI的受害者,也参考了历史的培训录像。首先我们来讲讲CMMI是什么。CMMI是一个过程框架,给出了一组管理企业的最佳实践。何谓框架?比如我们走在马路上看到一幢正在建设中的高楼,建筑者浇灌了水泥,搭筑了整个大
CMMI2级难点的对策
难点对策(1) 做一个切实可行的项目计划。(1)建立WBS分解的指南与样例(2)对项目经理培训如何做WBS分解(3)培训如何使用project 2007做一个合理的计划(4)加强对项目计划的同行评审(5)定义规模、工作量估算的方法并培训PM(2) 实时掌握项目动态,发现问题,解决问题。(1)建立周例会制度(2)当前阶段的任务分解的颗粒
需求变更对软件质量的影响
根据我们的经验,需求变更越多,造成的软件修改越多,bug也就会越多,事实是否如此呢?需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数,参见下表,基于这些历史数据我们分析一下,看看我们的经验结论是否成立。表一:需求变更的历史数据 ID 需求变更数 代码规模LOC 总缺陷数 测试缺陷密度bugs/KLOC
数据中存在的假象
在一些实施CMMI高成熟度的软件公司中对于过程的性能数据进行分析时,常常发现应该具有相关性的2个变量根据历史的数据不能证明这种相关性,或者是应该正相关的数据却分析出了负相关的结论,原因何在呢?例如: 我们的经验与常识: 假设或常识1:高水平的测试人员找出的BUG多, 低水平的测试人员找出的BUG少。 假设或常识2:高水平的开发人员犯的错误应该少,低水平的开
同行评审培训练习点评结果
2008年3月3日做同行评审的培训,讲解同行评审方法花费了3小时,练习时间为1小时,点评时间为45分钟。参加培训的人员为20人,19人参与了练习,划分成了3个小组练习。3个小组对同一个需求进行了同行评审,该需求为一个实际项目需求的一部分,仅有1页纸,但是质量比较差。 这3个小组的练习结果如下表所示: 第1组 第2组 第3组
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线