3.5 菜鸟无畏——《逆袭大学》连载

淩亂°似流年 2022-03-28 10:08 182阅读 0赞

返回到【[全文目录][Link 1]】

**目录**

3.5 菜鸟无畏

我是菜鸟，我怕啥？

抄之有道

何以编程到呕吐

抓紧与放松

我的编程思路呢？

学编程，要记住什么

--------------------

## **3.5 菜鸟无畏** ##

编程对绝大多数人而言，是在上大学时才正式开始的。尽管目前在初、高中都设有信息技术课，但总是因为“高考不考”的理由而被忽略。高中的数学课中有“算法初步”的一个模块，势单力薄，似乎也并未在学生头脑中留下什么印象。

当开始进入这样一个全新的世界时，不少人遇到了困难。在我的教学工作和课外咨询中，大学生们会在说“我不会编程”前，加上各种各样的原因作为铺垫。“数学不好”、“逻辑思维差”、“我是女生”，林林总总。人有了自我保护的意识真是太好了，在寒风般的逆境中，总是想找一顶帐篷钻进去，借此能舒服一些，而不是逆风而上，快点回到真正温暖的家中。我要做的，就是残忍地掀开帐篷的一角，让寒风将同学们吹得清醒一些，而不至于在这种“不冷”中冻得失去知觉，进而失去了走出的愿望和力量。

> 一位大二的学生给我来信了，他写道：“我的学习状况不是很好，主要因为我是一个零基础的计算机专业学生……”

我笑了，零基础，一个我以前没有听到过的新的理由。有谁从娘胎里出来，就有学某个专业的基础？计算机类专业的招生没有像艺术类那样提前加试专业基础，这已经是说明计算机类专业就是面向零基础招生的。这样的理由站不住脚，所有事情都是从零基础开始的。

### **我是菜鸟，我怕啥？** ###

初入大学的同学不容易，诸事都需要适应。中学到大学，中间的跨度不小。刚学编程的同学伤不起。打火、挂挡、抬离合、加油门，这套老司机习以为常的动作，对菜鸟司机就是一个坎。于是不少刚趴在门口看了看，还不知道编程是个啥东东的同学说：“俺就不是个编程的料。”

其实，何必这样呢？不说本来就喜欢计算机的，对所有新手而言，编程关是一定要过的，想躲也躲不过了，坦然接受更好。菜鸟最大的资本就在于一穷二白，可以任意地想事，可以问出任意问题——将来可能自己都要发笑的问题。白手起家，无牵无挂的菜鸟，可以为学会输出“hello world”而自豪，只要抓住一点点的阳光，就可以让自己无限灿烂。

菜鸟的优秀品质在于敢往前冲，做事舍得下力气。这是能够得门而入的途径。我和学生说：“老师将带着你们这帮菜鸟学习飞翔。”有学生说：“我们就是个鸟蛋。”认同了自己顶多就是个菜鸟级的身份，就可以走得轻松一些，可以无所顾忌地投入进来，经过积累，很快就能找到起飞的跑道。在菜鸟的自我定位中，带着一些自嘲，但也就此摆脱了不必有的心理负担，轻装上阵，找到让自己梦想起飞的地方。

时下为数不少的学生只要找到一个人云亦云，有时甚至是子虚乌有的说辞，就将自己划到了“不学编程、学不会编程”的阵营中去。见过了太多背着各种包袱学习的大学生，他们羽翼未丰，却背负着不该有的负担，难以前行。本该是走一步看一步，摸着石头过河的时候，却恐惧无比，担心承受不起想象中失败带来的后果，不敢前行。真也怪了，不少人真的就学不会编程了。四年专业学习的时光，或许在某个时刻及时回头，能够从头开始。有的人，却永远失去了本不该丢掉的机会。

从菜鸟阶段走过，每个人都会有这个时期，这真是一件令人自豪的事情。有了菜鸟无畏的向前精神，发现自己的点滴进步，自信也将逐渐而来。这种自信，是向成功迈出的第一步。相信自己能够从零开始，唯有在这种心态下，学得一点，就是收获，这样走来的脚步不会沉重。既为菜鸟，要的就是这种放松。

### **抄之有道** ###

常见有初学者在上机的时候，将教科书上的例题逐句输入计算机进行验证。运行得到了正确的结果：“哈哈”。结果不正确：“怎么会这样？！”在究竟是书中错还是计算机错的疑惑当中，接着输入下一道例题。有时候，老师布置了一道习题，编不出来，找出习题解答，用相同办法，结果是“哈哈”，或者再次疑惑是书上错了，还是计算机错了。

这样的叙述，让本来学习就不顺利的同学不舒服了。当自己编不出程序，看书找不着感觉，学习难以打开局面的时候，将书上写的、别人做的程序抄一抄、调一调，这是在编程起步的时候可以采用的一种方式。有人在介绍学编程的经验时，也提到将某本经典的教材上所有题目都输入、运行一遍，最后找到了感觉。这是一种不错的笨办法。

采用这种方式，一定要亲自输入，不要直接复制、粘贴。输入过程中用的是手，但也将大脑用起来了，用手敲键盘的动作，在大脑中建立起问题与代码之间的联系。这样的手敲打、脑思考的过程，就是找到感觉的过程。限于学习的阶段，可能还不会有目标地思考，但潜意识中一定要让大脑充分参与。

但是，抄程序的过程，千万不要仅限于我在上面描述的“哈哈”或者“书错了？”的情形。那样做的收获，最多是练了个打字，自己对程序的感觉越来越差。程序输入计算机后，编译、连接、运行。能够得到正常的运行结果，这中间一定有你细心工作的成分。有不少的人在照着书抄的过程中缺这个少那个。试想着行末少个分号，把main写成mian，大小写没有区分，这样很菜的错误谁都犯过。一次能抄对，充分表明了你在抄的过程中的专注，以及对这些问题已经能够有所注意，决定了你在写出自己的程序时也会避免这些菜鸟错误。所以，当结果对了，再将程序看一遍，欣赏一次。这也是找到好感觉的一个环节。

最重要的是，程序不对怎么办？抄不对，很正常。在不得已抄程序的阶段，常见的问题一般在基本的语法层面。静下心来，结合提示的编译错误，仔细对照，有时候需要将教材中相关的知识点看一看，发现其中的问题。将程序改出来，这是一个必须要做的事，万万不能止于带着满脑子的不解，改输别的程序去了。每改一处错误，就是一个收获，直至程序正确运行。从第一个错误开始改起，往往错误有相关性，百十个错误常常只需要改动几个地方就可以了。有不少的问题是共性，改一处，不用再提示也知道其他要改的地方。从错误中成长，在失败中成功，这是无数过来人体会到的真理，抄程序中用好了这些错误提示，威力无穷。

看着满屏的错误提示，首先要做到的，就是不烦不急，程序员就要有大将军一般的镇定。集成开发环境（IDE）真是我们的一个好老师。见过哪个老师为你如此严格地把关工作成果，详细地一一列出问题的？只是这位严格的老师不懂心理学，性子也急了些，一股脑全端出来了。正如我在前面提及的，好老师就在你身边，只是待学生去发现。作为伯乐，要将IDE这个老师用好，没有哪个老师是完人，每个能够独立面对的学生都应该有这样的胸怀。

程序运行一有错误就怀疑计算机出问题的，以及搞不清语法就想是IDE不对的，这是一种罪恶迁移的心态：有了成绩是我的，出了问题，别人的可能性更大。然而我要遗憾地告诉读者，几乎所有的情况下，问题还是你自己的。程序员们在谈恋爱中最可贵的品质就是这样练出来的，他们问自己最多的一个问题是：“我错在哪里了？”他们时常告诫自己：“只要知道问题在哪里，我一定改。”不是书上错了，是你在什么地方输入错了，不是计算机有问题了，而是你在某个地方还不明白。如此下来，必将进步。不过，如果啃不下来，不要把自己逼疯，动用你可以利用的力量吧，老师、同学、论坛、搜索引擎，伯乐还是要做的。在信息时代，找不到老师，那是你自己的能力还待有提高。

不少使用抄程序学编程的学生止步于语法正确。抄程序是从很容易的程序开始的，不在简单程序中入手练出找错误的本事，程序设计的感觉来不了。最低级的问题，就在没有语法错误的虚假繁荣中一直潜伏着。止步于语法正确，就是一种掩耳盗铃的做法。这样一种做法，将本不该一直依赖抄程序的做法一直保持下去，将本该是程序入门的学习，完全地成为了练打字的过程。等到要编写复杂程序了还得依靠抄程序，这样的学习历程和学习感受堪忧。

语法问题只是表面，最难办的是运行错误和逻辑错误。这也是在编程序的时候我们面临的最大挑战。这要靠在实践中锻炼自己的逻辑思维能力，运用好各种调试工具和调试手段。现在面向初学者的教材和大学的课堂里，对调试缺乏必要的重视。初学者要及早通过各种途径主动掌握调试工具。

语法正确了，运行正确了，圆满了吗？No！尽管很多人的抄程序之旅就此结束。**抄完了程序，将参考资料放到一边，再将程序自己写出来——可以是手写到纸上，也可以是直接输入到计算机中。**在写出来的过程中，一块一块，而不是一句一句地回忆，不必追求一模一样，但求思路跟上。当再次完成时，这个程序就是你的了。如果写不出来，说明前面抄程序的体会还不到，翻开参考再读一读，直至自己能写出来为止。有同学拿出了应付高考的利器，一咬牙：我把程序背下来！哎呀亲呀，赶紧省一省，这个办法笨到家了，坏透顶了，千万别试。

再将程序自己写出来，是抄程序学编程的最后一个环节。这个环节是我们的目标所在，体现的是自己真正的进步。不去实施这一步，前面所费周折的收益大减。有人讲了：“好不容易有了正确的运行结果，已经是头昏脑涨了，你这贺老师害人不偿命怎地？”谁让你硬撑着了？该休息该活动随你去，只是，需要再有个时间，将程序自己再写出来。如果真能冷一冷再重做，效果还更好。

抄程序的学习方式，只是一种适合起步的做法。抄程序，排除语法错误，解决逻辑错误，再将程序写出来。这样做了，是抄之有道，将使你尽快地走到不抄的道路上去。在以后偶尔也抄一个，但逐渐地就能自己去写。如果将自己仅当作了打字员，可能抄完了几十个程序，还是起不了步。抄程序解决的是编程序的感觉问题，突破的是起步难的困境。很多问题，回头看并不是什么大事，只是有一层“窗户纸”隔开了两边。面对“窗户纸”，捅破了，就好了。

有些同学对编程一开始就有感觉，这实在是一件庆幸的事。起步阶段抄点程序也很正常，对某些同学来说是有效的。要抄之有法，抄之有道。要是抄程序久了还得抄，一定要想着抄中的不得法，要改变方法。抄是手段，不是目的。要抄得智慧，抄出精彩，抄出风采来。

### **何以编程到呕吐** ###

和大一的Y同学谈心。她痛苦地告诉我：“调程序就恶心，有两次坐在计算机前超过两小时，都呕吐了。”她的这个问题把我吓了一跳。我也真为她难过。不说她目前编程还有些困难，调程序就恶心，日子怎么过？

怀着想帮她解决问题的愿望，再多了解一些，我知道问题可能就坏在了“编程有些困难”上，并且坏在了她有一种要改变现状的强烈愿望。当面对bug，她总是告诉自己，我真差，但我不能退缩。我和她分析，如果不出意外，这是由心理导致的生理问题。

有不少学生，尤其中考生、高考生快到考试的时候，出现了腹痛、腹胀之类的生理反应，到医院去检查却往往没有任何生理上的指标异常。这种情况完全是由于焦虑紧张的情绪引发的，其中多数是由于家庭或个人对考试的期望值过高。

在编程起步时出现困难，这是很正常的事。一些人很快地适应了，走上了辛苦而又快乐的学习道路。一些人仍在坚持着，等待适应的那一天。每个人的内心不一样，有人告诉自己，我一定会进步，更幸运的是，他或她能敏感地发现自己哪怕一丁点的进步，为之欢欣鼓舞，这样的同学迟早会找到乐趣。也有人不看自己的进步，反倒是一再地和自己对话：怎么这么难，真烦人！什么时候才能做完？我什么时候才能学会？这种负面心理，让自己一直生活在阴暗之中，不仅编程学不好，生活状态可能也会陷入困境。

对于Y同学，她的心理暗示恰好就是负面的。有一天她告诉自己，调程序真恶心。再有一天又这样想了一遍，在逐渐强化中，终于，有一天，忍不住吐了。

我给她了一些建议。

给自己正面的暗示，有意识地看到自己的进步，多花些时间，欣赏自己做出来的程序，而不是一做完看到结果正确了，赶紧逃离这个“恶魔”。再编程时将“恶心”的念头放到一边，取而代之的是想一些愉快的事。作为视觉型学习者，我不赞成学习时听音乐。但她处在这种情况下，可以试一试一心二用，用听音乐之心，听音乐获得的欢娱，压制那个邪恶的念头，用另一心完成编程。这一招叫**“转移意念法”**。

编程时，不要持续时间太久。其实对于没有这种问题的同学也一样，至少一个小时活动一下，利用三五分钟随便走动一下，不要连续坐在那里两小时以上。而对Y同学，半小时放松一下，也不失为暂时的积极应对。这样，负面的感觉不会积累起来，谓之**“分而化之法”**。

胃病病人一般要少吃多餐，Y同学也可以每次少学一些，换个其他事情做，然后再做编程的工作，也就是学习的次数增加，每次的量要减少。这是编程中的**“少吃多餐法”**。

上机调程序之前，先做好“功课”。把要做的程序先在草稿纸上写好，通过看书将基本原理搞明白，不用电脑，而用“人脑”将自己写的程序运行好，这样可以减少在计算机前调程序的时间。再者，一出手，就差不多了，这种更成功的体验也有利于早日解决这一问题。诗人常说“功夫在诗外”，学编程可以讲“功夫不在电脑前”。这在我们那个计算机奇缺的年代不是没有用过。这可以称之为**“围魏救赵法”**。

解铃还需系铃人，“编程困难”引起了“恶心呕吐”，需要用提高自己的编程能力的手段去解决。只有这样才能够摆脱折磨，获得自信、获得兴趣，获得愉悦，最终成功地渡过这一难关。

有心魔，就想办法去克服。但心魔往往都是自己招来的。学习中的投入是前提，但是方式可以灵活些，策略可以多样些，时刻找到让自己积极的暗示。学习中有了这种好的感受，学习就是件快乐的事，好的学习效果何愁不来？

### **抓紧与放松**  ###

又一名“亲”学生给我发来一封信，标题为“救命”。

> 从开学到现在也有两个多月了，学习C++，一开始觉得很有意思，也觉得能学好C++是一件值得骄傲的事。可是，不知怎么的，脚步慢下来了，总感觉自己有好多东西都不会，看到舍友发了一篇又一篇博文（注：我要求学生编完一个程序，就发一篇博文），很是羡慕，但同时又有了好大的压力，看到自己没做的作业，心里越是着急，想快点做完，越是编不出程序，这就成了一个恶性循环，感觉自己与大家的距离越来越远。我好好看书，也向同学请教，当时明白了，可是一上机，却不知道用什么语句，上机时也不知道编什么好，编一个半路出错，再编一个还是半路出错，时间就这么浪费了，两节课也做不了多少程序。老师，我该怎么办呢？我好想和他们一样，能又快又好地做出程序，请老师指路。

以为真要出人命的我，赶紧回复。

> 你的一声“救命”，吓死为师了。你的来信中，通篇看到的就是急躁，这样一个心态让自己沉不下来，进而更急。在任何时候，我们需要忌讳“比”字，不要总将自己与别人比，觉得比别人差，比别人慢，对你无益；觉得比人强，沾沾自喜，有意思么？人各有别，怎能一样？如果要比，是一定要和自己比。回顾一下两月前，你的进步有多大！昨天还在受困于见了循环就让人眼晕；而今天，学了函数，写出了好多个模块，完成一个整体的功能。漂亮的程序结构，你可以为之自豪！上机时也不知道编什么好？我布置的任务不是要做的吗？看书中遇到的疑惑是否可以通过自编一个小程序去体验？是否可以根据做过的题目改进一下需求，或者换一种解法？
> 
> “编一个半路出错”，不出错正常吗？自己的理解和本来的样子之间有偏差正常，但在不断推进中，我们的学习一直在向着掌握知识的方向有效行进。出现错误是我们最好的进步机会，是我们的朋友，而你将之视为敌人。编程序的过程，就是和这位朋友一起共同成长的过程。换种立场看问题，海阔天空，曾经感觉的“有意思”和“骄傲”仍然在。只是，你不近他，他不理你。在这期间，无论做得多慢，时间并不是浪费的。你可能看到了有些同学的快，你没有看到他们在背后的投入，每个人都需要一个过程，有人可以在努力一段时间后，快速地找到感觉，有人时间会长些；有人太急了，反倒是感觉迟迟不来。太过于急躁，感觉有可能永远不会来。
> 
> 所以，沉下心来，抓紧，也要放松，你会找到感觉，会学出精彩。这需要自己有个调整。
> 
> 据我观察，你已经开了个好头，松了两周，但目前还不算跑偏太多。本来均匀发力即可，对你而言，可能真的需要在近期多投入一些，在代码的海洋中多打两个滚，就能回到正轨。

### **我的编程思路呢？** ###

一名计算机专业大二的学生给我来信说，他觉得编程难，却还在坚持学习，并且提出了疑惑：

> 我现在在做一系列C语言竞赛中的一些容易的题目，可是我发现我碰到的问题会很没有思路，不知道方向，看见网上的很多同学都能够解决，而我却不能，我不知道自己差到哪了，我不知道怎么办才好，都有很多中学生的水平都比我这个大学生的水平要高，我真的不知道，那些未上大学就已经在编程方面很牛的同学是怎么做的，我感觉计算机这条路走的好难！

这种情况太常见了。编程初学者常常陷入一种无奈：我一看书就懂，合上书就不会了。看别人的程序能看懂，要是自己编，没思路。在这种无奈中，放不松，抓不紧，感受很差劲。我在前文介绍过有层次地设计，那些方法需要沉下心来运用和体会，但在我的教学中发现，我给同学通过一个例子讲明白了方法，但是离开了这一个问题，同学们却不主动用这样的思维和步骤去解决另外的问题。似乎习惯了题海战术之后，并不讲究方法的迁移。站在老师的角度吐槽这个事情，提醒同学们需要注意知识的关联，需要主动应用老师介绍过的方法。

对于来信的同学，显然还有其他方面的问题。我尝试给出一些建议：

> 遇到问题没有思路？你提的笼统，实际上有时也真说不清思路应该从何而来，其中到底难在什么地方。我也就一些猜测与你共享，但愿有一条适合你，给你启发。
> 
> 1. 人常说，见多识广。是不是见得还不够？凡事都要个积累，量变才能达到质变。此时知道自己的做法是对的，平静一些，做下去即可。
> 
> 2. 在教育、学习中有个非常响亮的词，举一反三。反思在做过一道题以后是做完就将之放过去了，还是总结从这道解题中运用了哪些知识、技能？是否需要在做完若干道题目后将之浏览一遍悟一悟了？动手是表现形式，更深层的是要思考，是动脑。这样，做一道题目，可以获得解答同类问题的启示。
> 
> 3. 常说理论要联系实际，其实，在实践中也需要有理论的支持。有些理论，你以后会学到。在目前的阶段，建议你能看一些通俗点的算法书，结合你要做的竞赛类的题目，可以看竞赛辅导类的书。前人总结好的什么穷举法、迭代法、回溯法之类的，会对你有帮助。
> 
> 随着进展，你的感觉会变好。从信中，我不担心你现在做题不顺，而是担心你的心态，有天要给自己找个“我不行，我没兴趣了”之类的借口而不再坚持到你向往的那一刻。急，急了后就去比，比的结果是让人丧气。看到与人的差距，设定了自己的目标，上路就行。在行进中，不再多想。起步本来就晚，速度还没有提起来，你就老看着比你先起步的，速度还比你快的，这是自找不愉快。如果要比，比自己，做题目比以前快了，写的程序比以前长了，解决的问题比以前难了，你会看到自己的进步，享受其中的乐趣。想想龟兔赛跑中龟的坚持和自我吧，当然咱不是那龟速，它是本来就跑不快，咱只是起步晚，速度还没有上来而已，咱做的是加速运动，甚至加速度在递增，是加加速运动。踏实地走在路上，不急不躁。
> 
> 人和人不能比。看到这句话不要泄气。每个人有先天的一些因素，成长的环境、过程、机遇各不相同。有时，是你本来有天赋的领域也还来不及激活。着眼向前看，让自己的前行更愉快些。其实，你只要平稳上路了，进步了，水平低但主动和牛人同学一起共事、学习，他对你的影响，会成为你的前行的助推剂，你会成为他们中的一员。从大学四年的角度，他们的最大的优势不是现在已经掌握的知识，而是为之投入的兴趣，和在这一领域深入学习的行动。对你来说最大的隐患是，在起步阶段由于对自己的否定，看不到自己的进步，从而不能坚决地前行。
> 
> 最后建议找些同学和你搭伴学。起点差不多，水平差不多，想法也一致的同学，做同样的题，遇到类似的问题，一商量，一讨论，done。可以按我对我的学生的要求，建一个技术博客，记录自己的成长。找到一些同样在做编程题的博友，看他的程序，给他评论，回头他也会投桃报李，网络上的互帮互助也就有了。
> 
> 你并不差，只是缺少积累，时候未到。只要愿意往前走，办法总比困难多，轻快一些往前走吧。

### **学编程，要记住什么** ###

有同学疑惑，学编程要记住的东西太多了，怎么才能记下来？在考完试阅卷中我也常能发现，有些同学的编程题是靠“背”程序完成的。在驴唇不对马嘴的回答中，卷面上依稀就是书中某道例题的影子。我的一位女学生在博文写学习心得：“虽然有些还是不太明白，但是先把这程序背下来了，相信会慢慢懂得。”

在有些同学的心目中，对“背会程序”给予了很高的重视。这个方法有大大的不妥，但从中表现出的渴望获得突破的精神自然要给予好评。我在博客上给这位努力的同学留言：“本周表现出色！希望你所说‘把程序背下来’不是我理解的死记硬背，而是成块地看，关键的语法点和原理能与课堂讲的、书上写的对应得上。”

在突破中力求改变，没有巧劲用笨力，这种精神咱可以有。

看着有些高手们娴熟地敲出程序，好羡慕，这些从指尖自然流出的代码，究竟是从何而来？遗憾地告诉采用了笨办法的同学，这些东西不是通过背书而来的，套用卖油老汉的话，是“唯手熟尔”。和卖油老汉不同的是，编程要用脑子，编程也要有灵感。只是灵感何时能来因人而异，而灵感未到之时，就要靠积累。编程序多了，灵感也就有了，遇到要解决的问题，脑筋一转，方案自然出现，写出程序成为自然。

用背书的方法学编程，是用应试的方法学习和备考的一个典型反面案例。一个人的记忆力再好，能背会多少程序？工作中要解决的问题，岂是书本中的例题能够涵盖的？日新月异的IT业创新多多，背会了再多的程序，究竟能干些什么？用背书的方法学编程，无疑是钻了死胡同。

在学习中文、英语这样的自然语言时，需要记忆一些文章，是为了找到和积累语感。对于很多美文，经过记忆后，文章中的表达方法慢慢成为自己表达的习惯，各种表达方式，借此能够自然流露。高中时某些科目中的强记，是一种完全低级的考证方式和学习方法的结合，并不值得再继续。到了学习程序设计的时期，要明确程序是用于解决问题的。一个问题有多种解决办法，有了解决方案，程序自然能写出来。用背程序的方法，就是不追求方案之根本，偏索要表达之末节。

编程中最重要的环节不是实现，不是用语言表达出来。编程序的关键在设计。写不出程序，往往是在设计环节上出了问题。试图在用语言表达的层面上记住，实则掩盖住了在思维上的不足，使得编程最核心的问题久拖得不到解决。有些人背过了一个程序，问题稍加变化，就不会解决，还是不能做到灵活应用。

有同学要问：“程序设计语言中的各种关键词、语法规则也不需要背会吗？”其实，对于一个编程语言来说，关键词一般最多也就几十个，在英语当中属于常用词，其意义和自然语言并无太大的差别，而编程语言的语法规则死板且有限，只要经过实践，可以做到不记而记。有人说一个程序中出现的词太多了，细问之下发现他将变量名、函数名等可以自由命名的标识符也当成不能改变的成分了，如此背过的程序只能是死水一潭。

在程序员的工作当中，记住代码毫无价值，只会成为同行的笑料。在实际工作中，遇到问题可以随时查手册，且很多人习惯使用在线资源。开发中引入的软件包倒是需要知道大量的库函数及其调用格式，有集成开发环境中“代码自动完成”等功能的支持，还可以查询在线的参考资料，这些根本不是个事。在ACM竞赛等面向大学生的程序设计大赛中，规则是可以带上你想带的任意纸质资料，很多参赛队都准备着非常实用的“代码库”。

那么，不背程序，程序设计的考试能通过吗？有人背会了程序，在很少的情况下押题成功，撞了运气。但是，学会编程的目标没有解决，这个分数只是问题的遮羞布而已。有些在答题时用背会的程序生搬硬套，只会出现驴唇不对马嘴的笑话。真正掌握了程序设计，而不是背会了程序的同学，无论怎么考试，题型怎么变化，面对这个年代大学的考试，随便就是高分。我倒是真愿意取消程序设计的笔试，这或许才能真正抽去了企图背程序的同学的“绝招”，才能让他们添置新的“装备”，改变学习的思路。

在学习编程时，遇到了再大的困难，也不要把自己交给死记硬背。我们知道，学过的和做过的东西，会在大脑中形成记忆，这是从实践中得来的记忆。这些记忆加入了自己的体验，在多方对照中形成了知识和体验的交织，成为了更为可靠的知识。这些鲜活的知识具有强大的再生能力，当遇到类似的问题时，会自动由大脑调动起来，形成解决新问题的方案。在持续的实践中，这些知识会不断体验，学与习的反复交互，不背而记。这就是我们要的境界，也是我们追求的自由。

安排出有效的实践，习、学结合，学会读代码，学会调试的手段，有勇气往前冲一冲，自然会获得这些能力。拿出有效的方法突破瓶颈，让背程序永远成为历史吧。

返回到【[全文目录][Link 1]】【[下一节][Link 2]】

[Link 1]: https://blog.csdn.net/sxhelijian/article/details/85908097
[Link 2]: https://blog.csdn.net/sxhelijian/article/details/86154145