当前位置：首页 > news >正文

ABAP设计模式之---“童子军法则(The Boy Scout Rule)”

news 2025/6/10 9:34:08

法则介绍

The Boy Scout Rule，中文一般翻译为“童子军法则”，是一个简单却非常有意义的软件开发原则，它最早由软件开发大师 Robert C. Martin (Uncle Bob) 在他的《Clean Code》一书中提出。

这条法则的核心思想非常简单： “确保你离开代码的时候比你发现它时更干净。”

在这里插入图片描述

这条规则借鉴了童子军的一种行为习惯：在露营时，童子军团员会遵循一种纪律: 收拾营地时必须比他们到达时更干净整洁，再离开。我们在编写和改动代码时，也可以应用类似的理念。

这并不要求你每次改动代码时都去对整个代码库进行改造或重构，而是尽力让你涉及的那部分代码变得更好，比如更易读、更清晰、更少问题、更优雅。

简单概括就是：通过日积月累的小改进，逐步提升代码质量。

举个例子

场景

假设你是一位开发人员，正在修复一个在上市产品中的bug。你定位问题时，发现这个bug所在的代码片段是一个结构非常混乱的函数，看起来充满了臃肿的逻辑、重复代码和混乱的命名，比如：

CLASS lcl_calculator DEFINITION.PUBLIC SECTION.METHODS calcIMPORTINGp TYPE fy TYPE it TYPE iRETURNINGVALUE(result) TYPE f.
ENDCLASS.CLASS lcl_calculator IMPLEMENTATION.METHOD calc.CASE t.WHEN 0.result = p + p * 0.03 * y.WHEN 1.result = p + p * 0.05 * y.WHEN OTHERS.result = 0.ENDCASE.ENDMETHOD.
ENDCLASS.

从代码上你能看出来，这个函数的目标是根据用户选择的投资类型 (t) 来计算利息。但阅读这段代码时，你可能感到困惑，因为变量命名模糊，且写法欠优雅。

应用

按照这个法则，你在修复 bug 的同时可以顺手将你看到的代码稍作优化改进！比如，你可以：

改进命名：把模糊的变量命名替换为易理解的名称，提高代码可读性。
去掉魔法数字：把0和1这些数字抽取为具有含义的枚举值或常量。
提取重复逻辑：简化代码分支。

经过一个简单的重构，不额外引入新的逻辑，你的代码可能会变成下面这样：

TYPES: BEGIN OF ENUM investment_type.
TYPES low_risk VALUE '#LOW_RISK',high_risk VALUE '#HIGH_RISK'.
TYPES END OF ENUM investment_type.CLASS lcl_interest_calculator DEFINITION.PUBLIC SECTION.METHODS calculate_interestIMPORTINGprincipal TYPE fyears TYPE iinvestment_type TYPE investment_typeRETURNINGVALUE(result) TYPE f.
ENDCLASS.CLASS lcl_interest_calculator IMPLEMENTATION.METHOD calculate_interest.DATA: interest_rate TYPE f.CASE investment_type.WHEN investment_type-low_risk.interest_rate = 0.03.WHEN investment_type-high_risk.interest_rate = 0.05.WHEN OTHERS.RAISE EXCEPTION TYPE cx_sy_illegal_argumentEXPORTINGtextid = 'Unknown investment type'.ENDCASE.result = principal + (principal * interest_rate * years).ENDMETHOD.
ENDCLASS.

优化后的好处：

更好的可读性和维护性：变量名和常量的引入让代码一目了然，其他开发者将来再看这段代码时理解起来更轻松。
捕获潜在问题：通过改进代码，你可能发现原代码中的隐含错误（例如未处理未知投资类型的情况）。
逐步改善代码库质量：这种点滴的改进积累起来，整个系统的代码质量就会越来越好。

为什么它重要？

技术债务的治理 : 代码往往随着时间的推移越来越混乱，甚至积累大量“技术债务”。The Boy Scout Rule 就像是日常的清洁和整理，能让技术债务得到缓慢但持续的处理，避免问题堆积成“无法维护的大山”。
提升团队效率 : 每个人在修改代码时稍微做点力所能及的改进，整个团队的代码质量就会发生质变。未来在调试或扩展功能时，大家能够更高效地完成工作。
防止“破窗效应” : 如果代码长时间得不到维护，每次有新开发人员碰到一段糟糕的代码时都会想“反正没人改正，我也懒得管”，久而久之问题会更严重。The Boy Scout Rule 提倡每次改进一点点，从而避免这种情况。