很多家长和老师问我同一个问题孩子明明写出来的程序能跑为什么还要花整整一节课去“优化程序”我的回答通常是这样的程序能跑只代表“代码认识你”代码写得足够清晰才是“你和代码互相认识”。今天这节第28课主题就是让 Python 代码变简单——这里的“简单”不是指代码少而是指更容易读、更容易改、更容易拓展。我打算用一套真实的少儿课堂案例带你把一段“又长又乱”的程序逐步改造成清爽、好维护的样子。这节课适合正在学 Python 基础语法的小朋友也适合陪学的家长和带班的老师就算你之前只写过十几行简单代码照着今天的方法也能做出结构像样的程序。1. 为什么要让代码更简单从一次报错说起1.1 一个让小朋友崩溃的“面条代码”上课的时候我经常让学生互相“读代码”——读一段别人写的程序然后说出它想干什么。结果有个孩子读了三分钟都没看懂那代码长这样sint(input(n:)) r1 for i in range(1,s1): rr*i print(r)程序没有错输入5也能算出120。但问题很明显第一个字母s是啥r是什么i循环从哪里开始到哪里结束每个变量都像密码连写的人自己过几天再看都头疼。我给这类代码起了个外号叫“面条代码”因为它像一碗乱面条一样搅在一起。小孩子写代码最常见的通病就是这个以为只要机器能看懂就完事了完全忽略了人也是代码的读者。后来我跟孩子说写代码其实是在写“给未来自己的一封信”如果未来的自己看不懂现在的操作这封信就白写了。1.2 代码优化的三个层级看得懂、改得动、跑得快我给7到14岁的学生讲代码优化时从来不说“性能优化”这种吓人的词我会把目标拆成三层。第一层是“看得懂”变量名有意义、结构有层次别人读你的代码就像读一篇通顺的小作文第二层是“改得动”当需求变化时比如成绩等级从5档变成6档你只改一处而不是翻遍全代码第三层才是“跑得快”循环能不能减少、内存能不能省、执行时间是不是过长。对少儿阶段来说前两层永远是重点最后那一层只有在数据量变大时才需要认真考虑。记住一个原则优化的第一目标是降低“人”的成本而不是降低电脑的负担。电脑最不缺的就是算力缺的是能快速理解并维护代码的人。很多成人程序员也有这个误区为一秒不到的耗时反复折腾代码结构结果程序没跑几次人倒是被难读的代码折磨得够呛。少儿阶段就把这个观念立住后面写复杂项目时走的弯路会少很多。2. 第28课核心招式六种让代码变简单的常用方法2.1 变量命名让代码会“说话”第一招最简单但效果最立竿见影——给变量起个“会说人话”的名字。我记得上次课有个学生写了一个猜数游戏变量名是a、b、c、d程序100多行调试的时候他自己都分不清a到底是猜的数还是剩余机会。我让他改成guess、chances、target他三分钟就找到了Bug。在优化代码时命名遵循三条原则第一用英文单词或约定俗成的缩写不要用拼音首字母第二变量名能体现“它是谁”能用名词比如score、total、names第三函数名前用动词比如calculate_average、show_menu。Python的变量名区分大小写也建议统一用全小写加下划线的风格这是PEP 8推荐的写法孩子们提早养成习惯后面写复杂项目会省很多事。我经常在课上举一个例子同样是输入成绩写着core_score和写着a哪个更像在跟人对话前者一眼知道是核心分数后者还得根据上下文猜。我给学生的口诀是能让人猜出意思的名字才是好名字。2.2 魔法数字与常量告别“天书数字”代码里直接出现的数字比如90、80、60、5我们叫它“魔法数字”。魔法的意思是程序跑着跑着莫名其妙就做了一下比较旁边没有注释也没有名字读起来像天书。比如刚才那个成绩程序里写“if average 90”过了两个星期你还能记得90代表什么吗水平基准线满分课时数都说不准。正确的做法是用常量或表格把这些数字包装起来比如PASS_LINE 60、EXCELLENT 90或者干脆弄一张等级表。这样代码的意思一眼就能看出来将来改标准时只需改一处不会出现“改了这里忘了那里”的连锁Bug。我常说一句话数字本身没有说话权给它起个名字它才算是代码里的正式住户。这个毛病不止小孩子会有很多大人在工作里也喜欢随手写魔法数字半年后维护时恨不得重写整个模块。养成起名的习惯本质上是在给代码建立“身份档案”能省掉大量排查时间。2.3 列表推导式一行搞定循环累加如果要让孩子体验“从复杂到简单”的爽快感列表推导式绝对是最好的道具。普通写法要四五行先建空列表再写for循环再append最后赋值。而推导式一句就能做完比如scores [int(input(f请输入第{i1}个同学的成绩)) for i in range(5)]我建议孩子们先用普通循环写“笨办法”等写熟练了、理解了循环的每一步做什么再切换到推导式。顺序不能反过来否则他们就只会背格式不理解背后的执行过程。还有一个非常容易踩的坑推导式里尽量别放太复杂的逻辑一旦超过一个if或者嵌套两层循环可读性就崩了这时候更推荐用普通循环。记住优化不是越短越好而是“该短时短该长时清晰”。课堂上有孩子为了显摆自己厉害把一个三重循环压成一行的推导式结果第二天自己也看不懂了。这个反例我几乎每年都要讲一遍让孩子明白代码丢给机器跑之前首先要丢给人看。2.4 函数封装把大问题拆成小积木这一招专治“面条代码”。程序一长从头到尾只有一条流水线就像一堆积木全倒在地上。函数封装做的事儿就是把一堆积木搭成几个有名字的小模块比如get_scores负责录入成绩calculate_result负责算总分和等级display_report负责打印结果。每块都独立、可测试、可重复调用。这样做的最大好处是“定位Bug”的速度变快了如果打印出来的成绩不对直接去看display_report如果总分算错了只需要检查calculate_result不用再把整段代码从头读到尾。而且小学生天然喜欢“搭积木”的类比我在课上就用彩色积木块演示哪个块出问题就换哪个块互不干扰。这个思路会一直伴随到他们的高级编程阶段不管是面向对象编程还是大型项目协作其实都离不开“模块化、高内聚、低耦合”的朴素思想。别觉得这些词太深奥在搭积木的语境里孩子天然就能理解什么叫“各司其职互不干扰”。2.5 f-string格式化让输出更直观低年级学生最常见的输出写法是print(总成绩是 str(total) 分)。字符串拼接其实不难但一旦拼接的东西变多代码里就会布满加号、引号和str()函数又长又容易拼错。Python 3.6以后的f-string格式化字符串可以完美解决这个问题写法是在字符串前加一个f然后用花括号直接嵌入变量比如print(f总成绩是{total}分平均分是{average:.1f}分)我每次教这里都会让学生把我围起来因为大部分人第一次看到f-string都有种“原来还能这样”的惊喜。特别提醒两个细节f-string花括号内可以用表达式比如{f是对average:.1f}但如果要保留花括号本身记得写两层花括号这个细节在写生成器模板时经常用到。很多现成的教程里只讲最基础的插入变量我会让学生多做几个联系比如同时输出多个变量、控制小数点位数、进行简单的算术表达式这样他们才能把f-string用出花来。2.6 条件逻辑简化用“拍脑袋”级别的布尔运算程序里大量出现复杂的条件判断时读起来极其烧脑。比如“如果分数大于等于60且小于90打印及格”这种嵌套条件是可以被语法和结构吸收的。第一个技巧是拆分判断用等级表替代一长串if/elif/else第二个技巧是布尔值优先判断如果条件本身就是True或False不要再写“if x True”直接写成“if x”第三个技巧是条件合并比如多个条件走同一个分支时用or或and合并但要小心不要合并到看不懂。课堂上的练习是写一个“今天要不要带伞”的判断器孩子用一堆复杂条件写出几百字最后我引导他们想到用一个布尔变量is_rainy加一个or就搞定这就是“拍脑袋级别”的简洁感。实际上条件多了就容易乱一乱就容易出逻辑漏洞我常常看到有的程序里同一个分支被别人重复判断了三次还不是故意的就是没梳理清楚。用布尔变量给条件“起名字”相当于把判断的意图写在代码里比满屏的and/or好懂多了。3. 实战演练把一段“又臭又长”的成绩统计程序改造成清爽版3.1 原始代码混乱的版本优化不能空谈一定要有对照实验。我课堂上用的例子是“全班成绩统计”需求很简单输入5个同学的成绩计算总分和平均分并且根据平均分给出对应的等级90分以上优秀、80分以上良好、60分以上及格、否则就是需要加油。下面是小朋友第一版写出来的代码完全能跑但问题特别典型a[] for i in range(5): sint(input(请输入第str(i1)个同学的成绩)) a.append(s) total0 for i in a: totaltotali print(总分是str(total)) avgtotal/len(a) print(平均分是str(avg)) if avg90: print(优秀) elif avg80: print(良好) elif avg60: print(及格) else: print(需要加油)这段代码看起来没毛病但请大家把眼睛闭上10秒钟再睁开当作第一次见到它a是什么s是什么i有几种含义字符串拼接让人头晕“优秀”“良好”这些等级是怎么来的这些就是面条代码最常见的四种症状变量含义不明、类型转换散布、魔法数字成堆、条件分支重复。我要求每个小朋友先把这段抄一遍然后开始做“代码整理手术”。3.2 第一次优化命名与常量手术第一刀先解决“看不懂”的问题。把所有变量名替换成有意义的词a改成scoress改成scoretotal不变avg改成average。魔法数字也要处理5个人这个数量用STUDENT_COUNT等级分数线打包成GRADE_TABLE。改完的中间版本大概是这样的STUDENT_COUNT 5 scores [] for i in range(STUDENT_COUNT): score int(input(f请输入第{i1}个同学的成绩)) scores.append(score) total sum(scores) average total / len(scores) print(f总分{total}平均分{average:.1f})这里的sum(scores)其实也是一种微优化把累加循环直接替换成了内置函数sum内置函数是C语言写的比自己循环快得多代码还更短。我给孩子的解释是能用积木盒就不要自己锯木头Python这个玩具箱里好多现成工具等着你们拿来用。看到这里有的家长会疑惑为什么只改一部分等级判断还没改因为我想让孩子体验“分阶段优化”的节奏一次只做一个动作不要眉毛胡子一把抓改完一个版本测试一次确认没破坏原有功能再继续下一步。3.3 第二次优化函数分层第二次手术是把整段程序拆成三个函数让结构清晰。录入、计算、输出各管一段像一条流水线。这样写的好处是将来改成6个人只需要改一个常量将来想再算中位数在计算函数里加一行就行将来想再加一个“成绩排名”输出直接再写个函数拼上去。“搭积木”的感觉一下子就出来了。课堂上的中间代码如下STUDENT_COUNT 5 def collect_scores(): scores [] for i in range(STUDENT_COUNT): score int(input(f请输入第{i1}个同学的成绩)) scores.append(score) return scores def calculate_report(scores): total sum(scores) average total / len(scores) return total, average def get_grade(average): if average 90: return 优秀 elif average 80: return 良好 elif average 60: return 及格 return 需要加油 def display_report(scores): total, average calculate_report(scores) print(f总分{total}平均分{average:.1f}等级{get_grade(average)}) def main(): scores collect_scores() display_report(scores)注意到这里我把返回值用元组打包了total和average一次取出来这让代码清晰不少。我特别强调一点函数名要用“动词名词”的格式比如collect_scores读起来就像一句迷你指令。很多孩子一开始把函数叫abc、fff我提醒他们“你的积木块上要贴标签不然怎么知道这块是干嘛用的”这个比喻他们立刻就能接受。3.4 第三次优化列表推导式与等级表到这里读代码已经舒服多了但还能更上一层楼把录入循环压缩成列表推导式把if/elif/else等级判断换成遍历等级表。经过两轮优化后最终版本是这样的STUDENT_COUNT 5 GRADES [ (90, 优秀), (80, 良好), (60, 及格), (0, 需要加油), ] def collect_scores(): return [int(input(f请输入第{i1}个同学的成绩)) for i in range(STUDENT_COUNT)] def get_grade(average): for threshold, grade in GRADES: if average threshold: return grade return 需要加油 def display_report(scores): total sum(scores) average total / len(scores) print(f总分{total}平均分{average:.1f}等级{get_grade(average)}) def main(): scores collect_scores() display_report(scores) if __name__ __main__: main()对比原始版本行数差不多但阅读时间缩短了至少一半扩展性大大提升。注意我把GRADES设计成列表而不是一连串if/elif因为列表是有序的从上往下匹配就能处理“平均分同时满足多个条件”时取更高等级的需求。这个设计别小看它把“业务规则”和“代码逻辑”分开了以后改等级标准只需要改GRADES这张表一个if都不用动。3.5 优化效果对比行数、阅读时间、扩展性下课前我带着学生做了一张对比表记录同一个需求在三个版本里的表现。原始版本24行命名版本22行函数版本虽然行数变多但结构最清晰最终版本20行。大概十分钟后大家就发现代码简洁和可读性有时并不冲突关键在于把重复的逻辑收拢让信息密度变高。对比项原始版本最终版本变量是否易懂否a/s/i混用是scores/average等让人快速看懂所需时间至少2分钟20秒左右修改人数时改动量改2处改1处修改等级标准时改动量改4个if改1张表打印总分平均分是否方便只能伴随主流程可单独复用这张表课上孩子们看了都很震撼因为他们第一次意识到代码优化不是给自己找麻烦而是在给未来的自己减少麻烦。尤其是“修改等级标准时改动量从4个if变成1张表”这个直观对比比任何说教都有效。我趁机问他们如果你是这个程序的维护者你希望收到哪种版本所有人都选择最终版我说很好那以后你们交作业就按这个标准来。4. 代码诊断与运行效率优化后会不会更慢4.1 用时间模块实测性能很多家长担心用列表推导式、用内置函数会不会让程序变慢这其实是好问题因为不应该盲信“新写法一定更快”。我带学生用time模块和timeit做了个小实验分别用普通循环和列表推导式生成1万个数然后测耗时。结果是推导式通常更快原因是它把循环推到了C语言的底层减少了Python解释器逐条执行字节码的消耗。我实际测得的结果普通循环大概0.3毫秒左右推导式0.2毫秒左右数据量不大时差距很小。真正会拉开差距的是数据量当数据量达到10万条甚至百万条时差距才可能翻倍。这也是我反复强调的性能优化要基于真实数据不要凭感觉。课堂上的小实验很有趣孩子们看到时间模块输出那一串小数时纷纷惊叹“原来代码跑得快也能看得见”。这里也可以顺带提一句现在的编辑器里有很多代码诊断插件会帮你标出魔法数字、过长函数、重复代码等坏味道但少儿课堂我更推荐先学会人工诊断插件只是辅助工具不能代替思考。4.2 数据量变大时的选择推导式 vs 普通循环这里要给孩子建立一个认知性能优化要基于真实数据不要凭感觉。如果全班只有5个同学的成绩用普通循环和推导式没有任何体验差异优化目标是可读性但如果处理的是几千几万条销售记录那就可以认真考虑一些性能优化手段了。比如sum(scores)比自己写累加循环快列表推导式比循环append快map加list转换在某些场景比推导式更快。我在课上写了一个简单测试让程序统计一千万次累加结果内置函数明显胜出这种直观的数字比讲一百次大道理都更有说服力。不过我还会补一句速度和可读性常常是跷跷板如果一行代码又短又快但谁都没法维护那它就不算好代码反过来如果代码写得像老太太的裹脚布一样又长又啰嗦即使每行都看得懂整体逻辑照样会把人绕晕。好代码是在“短”和“清晰”之间找平衡。4.3 什么时候不推荐优化优化也有反例。我给孩子们强调三种“不要优化”第一程序只跑一次、数据量又小就没必要为可读性过度包装比如两行代码能完成的练习题硬拆成5个函数反而不利于练习理解第二优化之后可读性明显下降的比如把一个清晰的3层循环硬压缩成一行列表推导式这个亏我吃过调试起来怀疑人生第三在还没写对之前优化先把功能实现正确再考虑性能。我自己的习惯是“先让它跑对再让它跑快最后让它优雅”顺序错了优化就是空中楼阁。少儿阶段尤其要记住这句话很多人长大后写代码喜欢在初期纠结性能结果功能都没做完这就是舍本逐末。我会让学生在每次优化前先问自己三个问题现在的程序能跑吗测试过吗有没有可能出现边界情况没处理如果原版还是错的那优化没有任何意义只会让错误藏得更深。5. 常见问题与排查技巧实录5.1 优化时最常踩的四个坑我在教这个课的过程中发现孩子在做代码优化时翻车率最高的地方有四类。第一类是“为短而短”把好好的代码硬压成最短路结果一行里有三个推导式嵌套别人完全看不懂第二类是“命名过度”给个循环变量i都硬改成index_of_current_item_in_score_list反而累赘简洁和清晰要平衡第三类是“过早封装”一上来就拆十几层函数其实很多函数只调用一次纯属增加跳转阅读负担第四类是“忽视注释”以为代码够短就不用写注释其实好代码也需要注释来交代“为什么这样写”比如等级表为什么从上往下匹配这种背景知识只有注释才能表达。这些坑我几乎每届学生都会踩一到两个所以现在会提前打疫苗在每一轮优化前先提醒“这次我们要克制住哪种冲动”。有一次学生为了秀操作把成绩统计程序改成一行超长推导式结果里面有个缩进错误找半天我用调试器一步步展开成普通循环才帮他把问题揪出来他后来跟我说“老师我再也不追求最短了”。这个教训比我说十句都管用。5.2 给学生讲解优化时的提问技巧老师说十句不如问一句。我在课堂上的做法是拿两段功能相同的代码并排展示让孩子自己当评委问三个问题“哪个版本更容易看懂”“你为什么觉得它容易看”“如果让你加一个新功能你会选择改哪个版本”孩子们通常会自发说出“因为变量名有含义”“因为函数名像一句话我不用看实现就知道它干嘛”。这个过程比老师灌输“使用列表推导式”重要得多因为它训练的是审美和判断力而不是背语法。另外一个很有效的游戏叫“代码大侦探”给出一个全是乱编码的程序让孩子扮演侦探找出三个需要优化的地方他们找完会非常有成就感这种正向反馈会让他们更愿意主动优化自己写的程序。我有时候还会故意写一段带复杂魔法数字和混乱命名的代码让他们先把问题找出来再动手改这样一节课下来既有观察训练又有实操训练比单纯讲“大家要好好命名啊”有用得多。5.3 优化完成了吗一份检查清单下课前我发给学生的检查清单特别简单就5条。第一条每一行代码我都知道它在干什么不需要猜第二条每一个变量名都能用一句中文解释清楚第三条如果需求里出现“以前是5个现在6个”这种小变化我能指出修改位置不超过两处第四条代码里没有连续三次以上重复的模式有重复就想办法用循环或函数收拢第五条我给关键逻辑补了注释但注释解释的是“为什么”不是“是什么”。满足这5条就可以骄傲地在代码开头写一行“v2.1 优化完成”。这个检查清单是给小学生用的要的就是具体、可行动不要喊口号式的“我要写出好代码”。我还会提醒他们清单里最难做到的是第五条因为大部分初学者写注释都喜欢写“这个地方是循环”“这个是加法”这种注释跟没写一样真正值钱的注释是“为什么这里从90开始判断”或者“为什么等级表顺序不能乱”。5.4 课后作业建议这节28课的课后作业我留了三道难度递增的题。第一题是改造题把上节课写的一个猜数字游戏按今天学的方法优化要求用函数和常量重写并提交一份“优化前后对比说明”。第二题是挑战题统计100个随机数的平均值、最大值、最小值和超过平均值的人数要求至少使用列表推导式、内置函数和f-string。第三题是专门给学得快的孩子准备的扩展题用列表推导式生成九九乘法表的每一行然后思考如果把乘数范围从9改成20你的代码要改几处。作业的目的不是刷题而是让孩子在真实场景中反复体会“优化”带来的好处只有亲手改过、对比过优化的意识才会长在他们身上。我批改作业时重点看的不是代码跑没跑通而是他们对“改了几处”“为什么这样改”的描述因为描述过程就是在逼自己理解。很多家长反馈做过对比说明后孩子再看自己旧代码时都会露出“嫌弃”的表情这就是审美的觉醒。6. 我的课堂体会与下一步可以做的事6.1 代码审美是比语法更值钱的东西这一课真正想传递的不是某个语法技巧而是一种“代码审美”。我带过这么多孩子见过最明显的分水岭有的孩子学完循环、函数、列表就原地踏步遇到需求变化总是手忙脚乱有的孩子在同样节点突然开窍会主动把代码翻出来整理会自豪地跟爸妈说“我今天把程序变简单了”。差别往往就在这节课里种下的种子。我常说学Python不只是学一门语言而是在建立一套“怎么把事情想清楚”的习惯。优化程序时不仅要考虑机器怎么执行还要考虑别人怎么阅读、未来怎么修改这本身就是一种换位思考。当孩子开始主动说“我这段代码能优一下”我知道他们不只是技术变强了而是思维变得有条理了。6.2 后续课程可以这样延伸这一课之后紧接着可以讲两个方向。一个方向是“数据结构入门”因为当程序变复杂之后选择列表、元组、字典来存数据本身就是为了让代码更简单另一个方向是“模块化项目”让孩子把多个函数放进不同的文件里感受大型项目里的协作和管理。我个人在实际操作中的体会是先让孩子尝到优化的甜头他们再去学数据结构和算法时就会带着“我为什么要学这个”的好奇心效果会比直接按部就班讲语法好很多。最后再分享一个小技巧每节课最后几分钟我都会让孩子对着自己当天写的代码念一遍检查清单第一条“每一行代码我都知道它在干什么”。如果念到某一行卡住了那就当场改掉。这个习惯坚持一个学期后班里几乎没人再写面条代码了。代码简单了思路就清晰了思路清晰了写程序这件事就会从“应付作业”变成“享受创造”。这就是我坚持把“优化程序”单独拿一节课来讲的原因——它值得被认真对待。