12岁小学生重构代码：低龄编程中的代码可读性训练

重构代码这四个字放在12岁小学生身上，天然自带话题感。很多人第一反应是怀疑：一个小学刚毕业的孩子，语法都没完全学明白，谈什么重构？但如果你真的看过少儿编程课上的修改记录，会发现这个说法并不夸张，只是它和职业开发者理解的重构不在同一个层级。12岁小学生的重构代码，大多不是把项目推翻重来，而是把自己或同学写的一段二三十行代码改得更清楚、更好读、更容易讲给别人听。真正值得拆开看的是这些改动里暴露的思维方式：一个孩子怎么理解变量名、函数、重复代码，以及"为什么要把代码改好"。这篇文章不预设某个具体案例，而是基于低龄编程学习的常见场景，把小学生重构代码时的高频改动、典型代码变化、常见误区和可操作的引导流程完整拆一遍。

1. 12岁孩子眼里的"重构代码"，和你想的其实不一样

1.1 先纠正一个普遍误解

一个12岁孩子说"我在重构代码"，大概率不会去考虑依赖注入、设计模式、架构分层这些内容。他更可能做的是：把代码里看不懂的变量名改掉，把重复写了好几遍的同一段逻辑收拢到一起，把绕来绕去的判断条件重新排一下顺序，或者干脆给代码加上空行和注释。这些动作放在职业开发里叫"重构"，放在低龄编程学习里，本质上是"让代码重新变得可读"。

重构在软件工程里有一个相对严格的定义：在不改变代码外部行为的前提下，对内部结构进行调整。对小学生来说，这个定义里的"外部行为不变"恰恰是最难理解也最难做到的。孩子往往会顺手把某个功能也改了，或者把输入输出格式改了，这在外人看来就已经算"功能变更"，不算严格意义上的重构。所以讨论低龄重构，不用把定义锁死，更值得关注的是孩子有没有形成这种意识：改结构比改功能更考验细心程度，所以要先确认原来的功能没被改坏。

1.2 低龄重构通常发生在哪些场景里

从常见的编程学习路径来看，孩子在小学高年级接触到的重构，一般出现在下面几种场景：

• 自己写完一段代码，跑通之后发现太乱，想整理一下再交给老师。
• 老师给出几段"旧代码"，要求在不改变运行结果的前提下改得更好。
• 和同学互相看代码，发现对方的代码难读，提出修改意见。
• 学习项目越来越大，从几十行扩展到两三百行，原来的写法已经撑不住。

这些场景有一个共同点：代码量不大，通常只有十到几十行。也正是因为代码量不大，孩子才有机会完成一次完整的"读代码、发现问题、动手修改、运行验证"循环。在低龄阶段，完成这个循环比修改本身更重要。很多成年人写了好几年代码，都没有真正体验过"通读一段代码之后有计划地动手修改"的完整流程。

1.3 图形化编程和文本编程里的重构差别

还有一个容易被忽视的差异：用图形化编程的孩子，和用Python、C++这类文本语言的孩子，做的"重构"完全不是一回事。

在图形化编程环境里，孩子改的是积木块。他们最常见的重构动作是：把一个巨大的积木堆拆成几个小积木块，然后重复使用；给积木块重新命名；把散落的背景设置、变量初始化整理到同一个位置。这些动作同样是"调整结构、保持结果不变"，只是没有代码文本的观感，家长和老师不容易一眼看出孩子在重构。

在文本编程里，重构动作更接近成年人熟悉的样子：改变量名、提取函数、调整缩进、删除重复代码。文本代码有个好处，就是修改痕迹一目了然，前后对比非常直观。我的经验是：孩子一旦进入文本编程阶段，就可以开始有意识地安排重构练习，因为这个阶段的每一次改动都可以被记录、被比较、被复盘。

2. 翻看这类代码修改记录，最常见的五类改动

如果把低龄学习者提交的重构代码放在一起对比，会发现高频改动非常集中。不是高深的设计模式，而是五类非常基础的结构性调整。

2.1 把a、b、c改成能读懂的名字

这是出现频率最高的一类改动。初学编程的时候，很多孩子为了少打字，喜欢把变量名写成a、b、c、x、y、z。到了重构阶段，第一个改的就是这个。

比如原来写：

a = int(input("请输入第一条边的长度：")) b = int(input("请输入第二条边的长度：")) c = int(input("请输入第三条边的长度："))

重构后可能变成：

side_a = int(input("请输入第一条边的长度：")) side_b = int(input("请输入第二条边的长度：")) side_c = int(input("请输入第三条边的长度："))

这个改动看起来非常基础，但背后对应的是"变量名要表达含义"这条工程原则。对一个12岁孩子来说，能主动把side放进变量名里，说明他已经开始站在代码阅读者的角度思考问题，而不再只是站在电脑的角度思考。

2.2 把重复出现的代码抽成函数

第二个高频改动是把重复的代码块抽成函数。很多初学编程的孩子在写多个类似任务时，会选择复制粘贴，然后稍微改一下数字。比如连续计算几组数据的和，就会写好几遍几乎相同的循环。

total1 = 0 for x in [12, 8, 15]: total1 = total1 + x print(total1) total2 = 0 for x in [7, 9, 6, 10]: total2 = total2 + x print(total2)

重构后，孩子会把这段逻辑提取成一个函数，然后调用两次：

def total_of(numbers): total = 0 for x in numbers: total = total + x return total print(total_of([12, 8, 15])) print(total_of([7, 9, 6, 10]))

这类改动最大的价值在于：孩子第一次亲身体会到"写一次、用多次"这个概念。他不是从书本上背下来"函数可以复用"，而是真的遇到"这段代码我写烦了，写几遍太累"的真实感受之后，才主动去做提取。这个动机比任何教学讲解都有效。

2.3 把多层嵌套条件改平

小学高年级孩子写判断条件的时候，特别容易出现多层嵌套，尤其是那种"如果...那么...否则如果...那么..."的连环条件。嵌套一旦超过两层，代码不仅不好看，缩进层级也容易出错。

score = int(input("分数：")) if score >= 60: if score >= 90: print("优秀") else: print("及格") else: print("不及格")

重构时，常见做法是把嵌套条件拆开，或者用逻辑运算符合并。上面的嵌套版本可以改平成：

if score >= 90: print("优秀") elif score >= 60: print("及格") else: print("不及格")

这个改动的核心不是让代码少几行，而是让判断路径更直观。对孩子来说，"从外到内一层层看缩进"和"从上到下一行行读条件"，后者的理解成本明显更低。

2.4 消灭"魔法数字"

"魔法数字"指的是直接写在代码里、没有任何解释的神秘数字。比如成绩判断里的60、90，又比如游戏里代表移动方向的1、2、3、4。孩子重构时往往不会主动去管这些数字，看得懂的老师才会引导他们发现：如果换一个游戏地图大小，这些数字散落得到处都是，改起来会非常麻烦。

if key == 1: player_x = player_x - 1 elif key == 2: player_x = player_x + 1

重构时可以把方向数字提成有名字的常量：

MOVE_LEFT = 1 MOVE_RIGHT = 2 if key == MOVE_LEFT: player_x = player_x - 1 elif key == MOVE_RIGHT: player_x = player_x + 1

对12岁孩子来说，这一步最大的收获不是"代码变得规范"，而是意识到：代码里出现的每一个数字，都是有原因的，都值得被明确表达出来。

2.5 补注释、拆空行、理顺输出

最后一类改动最不起眼，但对低龄学习者来说非常重要：给代码加上注释、用空行把不同功能模块隔开、把print输出格式统一。这些不是软件工程里的硬性重构动作，却是一个孩子开始把代码当作"给人看的东西"的标志。在少儿编程里，这个标志比代码质量本身更重要。

下面用一个表格把这几类改动汇总一下：

3. 还原一个典型改动：从"能跑"到"能给别人读"

为了说清楚上面五类改动具体长什么样，下面准备一个非常典型的低龄重构示例。这类代码在入门班和学校信息课上很常见：读取一个分数，输出对应的等级。

3.1 重构前：一段典型的初学代码

s = int(input("分数：")) if s >= 90: print("优秀") elif s >= 80: print("良好") elif s >= 70: print("中等") elif s >= 60: print("及格") else: print("不及格")

这段代码能跑，结果也对。但它有几个低龄学习者常见的问题：

• 变量s没有任何含义，别人不知道它代表什么。
• 数字90、80、70、60直接写在条件里，改等级标准时要到每一行去改。
• 输入、计算、输出全堆在一个流程里，没办法单独测"输入分数得到等级"这一部分。
• 没有注释，过几天再看自己也不知道为什么是90不是95。

3.2 重构后：发生了什么变化

经过一次完整的重构练习，代码可能变成这样：

EXCELLENT = 90 GOOD = 80 MEDIUM = 70 PASS = 60 def get_grade(score): if score >= EXCELLENT: return "优秀" if score >= GOOD: return "良好" if score >= MEDIUM: return "中等" if score >= PASS: return "及格" return "不及格" def main(): score = int(input("请输入你的分数：")) grade = get_grade(score) print(f"你的等级是：{grade}") main()

同样一段逻辑，改动前后的差异非常明显。重构后的版本做了四件核心事情：把神秘数字提成常量、把等级判断封装成函数、把主流程放进main函数、把变量名从s改成score。这些动作正好对应前面说的五类常见改动中的四类。

3.3 每处改动背后的判断逻辑

这里要特别说明一件事：让函数返回等级字符串，而不是直接在函数里print，其实已经超出了严格意义的"重构"。因为调用方式变了，输出行为从"函数内部打印"变成了"函数返回结果，由主流程打印"。这在软件工程里通常叫"调整接口设计"，比重构的范畴更大。对小学生来说，这个概念不需要专门讲，但做练习时最好让孩子明白：你在改结构的同时也改了代码的使用方式，因此更要多跑几次确认结果没变。

注意：孩子第一次做这种练习时，最容易犯的错就是把函数从"直接print"改成"return"，然后忘了改调用处的代码。每一处改动后面都要紧跟一次运行验证，先确认原行为没丢，再谈结构变好。

为什么把常量提出来？因为如果及格线改成65分，使用常量版本只需要改PASS=60这一行，而原有版本要改六个地方，还容易漏改。这个"只需要改一行"的体验，孩子一旦真实验证过，就再也不想回到到处写数字的写法。

为什么用main函数包起来？因为很多孩子学编程的时候，代码是从第一行一路往下执行的，写到最后自己都不知道哪个变量在哪一步被用到。有了main函数，程序"从哪里开始、先做什么、后做什么"一目了然。对12岁孩子而言，这是一种把流程"画出来"的方式，不需要大讲特讲作用域和函数栈的问题。

4. 实操中最容易翻车的三个点

看孩子做重构，最容易出现的不是"不会改"，而是"改完反而更糟"。这种情况非常常见，不是孩子笨，而是重构这件事有几个天然陷阱。

4.1 追求一步到位，结果越改越复杂

孩子改代码有一个习惯：想一次性把所有"不满意"的地方全改完。改完变量名之后觉得函数也该拆，拆完函数觉得数值也该提成常量，提完常量又觉得注释要补。结果一次改动量巨大，任何一步出错都很难定位。

遇到这种情况，建议让孩子一次只改一类问题。第一次只改变量名，跑一次；第二次再抽函数，再跑一次；第三次整理常量和注释，再跑一次。每次改动范围小，出错了很容易发现。这其实就是职业开发者常用的"小步重构"原则，只是不需要让孩子背那个名词，只需要让他感受"小步改、频繁验"的过程。

4.2 没有"跑一遍再改"的习惯

很多孩子拿到代码的第一反应是直接开改，根本没先运行一遍原代码，不知道原代码在正常输入下应该输出什么。改完之后运行，发现结果不对，但说不清是自己的问题还是原来代码本身就有问题。

正确顺序应该是：先运行一遍旧代码，记录正常输入下的输出结果；改完一处，立刻运行，对比输出是否一致。这个习惯比代码本身重要得多。低龄孩子一旦养成"改前先备份、改后马上验"的习惯，后面的学习会顺利很多。我会在练习开始前把"原代码的运行输出"写在一张纸条上，改完一步对照一次，对不上就先停。

4.3 把改接口当成重构

低龄孩子重构时最容易出现的认知混淆，就是一边调整内部结构，一边偷偷改掉原有的交互方式。比如原来代码是直接执行、打印结果，孩子改成了让用户输入之后再打印；或者原来函数接收三个参数，孩子改成接收一个列表。程序功能看起来差不多，但使用方式已经变了。严格来说，这已经不是重构，而是功能变更或界面变更。

对老师来说，这不是需要批评的错误。相反，这是一个很好的教学节点。可以借机给孩子讲清楚：重构的前提是"外面看起来完全没变，里面变好了"。如果外面也变了，就要先说明"我改变了使用方式"，再继续改。这个意识一旦建立，孩子对"接口"这个概念就有了最早期的直觉。

5. 家长和老师可以参考的引导流程

如果家里或班上正好有一个12岁左右、正在学编程的孩子，想让他体验一次完整重构，可以参考下面这套流程。不需要特殊工具，只需要一段现成的代码和一个能运行代码的环境。

5.1 五步练习法

第一步，选代码。挑一段十到三十行、已经能运行的旧代码。可以是孩子自己以前写的，也可以是老师提供的样例。代码不要太大，否则孩子光读懂就要花很多时间。

第二步，记录基准结果。运行一遍，把输入和输出记录下来。这一步不要省略，它是后面所有修改的对照标准。

第三步，找"不舒服"的地方。让孩子通读代码，找出至少三个让他觉得不舒服的地方。找不到的话，可以提示他看几个方向：变量名能不能看懂、有没有重复代码、数字是不是直接写在逻辑里、有没有多余的嵌套。

第四步，一次改一处。每次修改只处理一个"不舒服"的地方，改完立刻运行，对比基准结果。

第五步，让别人读一遍。改完之后，找另一个同学或者家长，让对方不看原有代码，只看新代码，然后复述这段程序是干什么的。如果对方两分钟之内能说出来，这次重构就算成功。

5.2 用"能不能讲给同学听"当验收标准

对于12岁孩子，不要用什么可维护性、可扩展性、耦合度这些词去验收。最直观的验收标准就是：你能不能把这段代码讲给同学听，让对方在没有你解释的情况下读懂它。如果对方听完还要问"这个变量是什么意思""这个函数到底在干什么"，那就说明还有改进空间。

这个标准特别适合低龄学习者，因为它不依赖任何抽象概念，只依赖"给别人讲明白"这种孩子本能就有的表达冲动。我会让孩子假设自己是个小老师，要把这段代码讲给一个完全没看过的人听。一旦他进入"讲解者"的角色，很多结构问题自己就暴露出来了。

5.3 什么时候可以引入测试概念

重构做到第三次、第四次的时候，孩子通常会有一个疑问：我怎么知道改完没有改错？这时候就可以顺理成章地引入最基础的测试概念，不需要用单元测试框架，只需要写几个固定的输入，预先把应该得到的输出列出来，每改完一次手动跑一遍即可。

如果孩子已经能熟练使用if语句和列表，甚至可以让他写一个简单的自动对比脚本：把输入列表和期望输出列表放进去，程序自动判断重构前后的运行结果是否一致。这一步一旦完成，他实际上已经理解了"回归测试"的核心思想。对孩子来说，这比背十遍测试的定义都有用。

6. 怎么判断一次重构练习"真的学会了"

低龄编程学习有一个特点：孩子经常"会做但说不清"。所以判断一次重构练习是否有效，不能只看最终代码是否漂亮，更不能看改动行数是否够多。要看得更细一些。

6.1 不是看改动量，而是看能不能说清原因

一次优秀的孩子重构，可能只改了三个变量名和一个函数结构，改动不大。但只要孩子能说清楚"我为什么这么改""原来哪里不好""改完之后哪里变好了"，这次练习就是有效的。反过来，如果代码被改得面目全非，但孩子说不出任何理由，那大概率是模仿了某个范例，并没有真正理解。

所以在练习结束后，我一般会追问几个问题：你觉得原来的代码哪里最差？你改完之后，别人读起来和原来有什么不同？如果下次遇到同样的场景，你会直接写成新版本还是先写旧版本？这三个问题比任何测验都能反映孩子的真实理解水平。

6.2 更长远的能力指标

长期来看，重构练习对孩子编程能力的影响，会体现在几个可观察的指标上。第一，新写的代码从一开始就更清爽，不再需要事后大规模整理。第二，读陌生代码的能力变强，能很快找出主要结构和薄弱点。第三，愿意回到旧代码里做修改，而不是一遇到问题就推倒重写。第四，对"代码是写给人看的"这句话有了自己的体会。

这四个指标里，前两个可以短期看到，后两个需要更长时间才会显现。但只要孩子能保持小步练习，它们会逐渐变成稳定的编程习惯。

6.3 下一步：从"重构自己的代码"到"重构别人的代码"

如果孩子已经能稳定重构自己的代码，下一步可以试着让他重构一段别人写的代码，很多课程里也会设计"给一段糟糕代码，让同学们优化"的环节。这一步的挑战在于：孩子不熟悉原作者的思路，必须先通过代码推断当时的想法，才能动手改。

这其实非常接近职业开发者的日常：拿到的代码往往不是自己写的，读代码的时间远多于写代码的时间。能在12岁就完成这个练习，性价比非常高。做完之后最好再安排一次"原作者和新读者"的对话：让原作者看重构后的版本，说说能不能接受，让孩子解释每个改动的理由。这一步会把重构练习从"改代码"升级成"理解别人、表达自己"的沟通练习，收获远不止于代码本身。

最后说一个我自己的判断。低龄重构的价值，从来不在"重构"这个术语本身，而在于它逼迫孩子完成一次完整的"读代码、发现问题、动手修改、运行验证、讲给别人听"的闭环。这个闭环对成年人来说稀松平常，对一个十二岁的孩子来说，却是编程学习中第一次真正地"对自己写的代码负责"。所以下次再看到"12岁小学生重构代码"这种话题，别急着当成噱头。拿一段几十行的旧代码，陪着孩子跑一遍、改一遍、讲一遍，比什么都有用。