这世上最纠缠不清的一对情人

这世上最纠缠不清的一对情人

"愚蠢"的争论——先实践还是先理论？

        每当一个社群中出现理论和实践的执行次序时，总会吵成一片，吵地不可开交，吵地乱七八糟......更糟糕的是，一旦这种关于理论实践谁先谁后的话题出现后，这种争论总是不可避免地要发生——无论它原来已经发生过多少回。然而这种争论是“愚蠢的”。

这个世界不是线性的

        我个人认为，很多的认知层面上出现的问题都源于我们试图用线性思维去解释非线性发展的对象。说这争论愚蠢，倒不是说先实践的人愚蠢，当然也不是说先理论的人愚蠢，而是——把理论和实践的关系理解成线性的，简单的先后关系是愚蠢的。事实上，理论和实践的发展是一种“链条”式的发展。

作为一名GIS专业的学生，可以说我是饱受折磨之后才借着编程这件事彻底把这种链条式的发展想明白的，那就干脆拿它举例说明。编程的教和学，理应是这样一个过程

                                              从实际需求引入概念和理论→深入学习相关概念和理论→运用相对熟练掌握的理论试图解决实际问题。

上面这个过程，也仅仅涵盖从接触编程到初期工作这样一个过程（我甚至倾向于认为这个过程仅仅是学生时代的表述，工作以后可能就已经不够用了）。而当工作继续深入，会发现实际的问题越来越复杂，越来越细化。这时候以前自认为“熟练”掌握的理论又不够用了，需要耐下性子，拿出原来的经典理论继续研读（这应该是在工作初期发生的事情，此时你已经是一名程序员）。终于，你对理论有了更深一步的理解，可以更顺利的解决问题，并且可以站在更高的角度看问题。（此时，你可能已经是一名合格的工程师了~）。随着工作地继续深入，你会发现原来的理论理解深度又不够了，你再返回去看，再深入理解以后站在更高的层面更有效地解决实际问题。（此时，你可能已经变身公司架构师或者CTO了！）。我们再梳理一下上面这个过程

解决实际问题的过程中发现理论掌握不牢固→再深入学习理论→继续用进阶了的理论理解去解决问题→又发现之前的理论理解还不够深入→再次学习理论→再运用进一步进阶的理论功底解决实际问题。

看起来很简单吧？不就是理论实践相互促进吗？连中学的课本都讲过。不错，如此简单朴素的道理，很多人自以为掌握了，却没有深入思考，于是就发生了把这链条当中的某一段拿出来进行讨论，争论先理论还是先实践这种相当愚蠢的事情。我们再来看一个更清楚的链条。事实上，这争论的两个对立面都只是形成整个链条的一个Step。假如按照这个链条进行解释，每一个奇数的Step都是先实践后理论，每一个偶数的Step都是先理论后实践，你能告我我们在争论什么吗？

害人不浅的迷惑性描述

        这种"愚蠢"的讨论，除了没有深入的思考意外，还有一个隐藏的罪魁——具有相当迷惑性的描述。

        依然拿学习编程来举例。说起来可能会得罪一些我的同学甚至老师。很多经验丰富的老师们说得好：直接上理论怕你们觉得枯燥，咱们从应用开始讲起吧。套用上文愚蠢的争论中的观点，这不是叫先实践后理论吗？于是，学生们觉得：恩，先做项目再说，管他理论不理论呢。再于是，于是点鼠标和敲键盘成了IT相关专业学生的“学习”。更可怕的是，有些老师们竟然会觉得：恩，先实践后理论，我就这么教了，管它理论不理论呢。于是，本人大学本科的前两年的GIS专业课学习可以用煎熬和折磨二次来形容。原因很简单——不会走就想跑？你不摔得头破血流谁摔得头破血流？

        不过貌似也没错啊？人家说了从应用开始讲起嘛，先实践嘛...我们再来看看这一张图，在理论和实践的链条上加上IT学习和工作的发展流程。

你可能已经发现了：哎？如果把这个链条中抠出两个节点，单说先理论还是先实践，这初学者跟工程师看起来一模一样啊？！这就是问题的关键。读者还可以从另一角度去理解：把这个链条编程立体的，想象成一个竖着放的大弹簧，一层一层地绕上去...相当于我们造了一个螺旋式上升的模型（再次说明，世界的发展不是线性的），在这个模型当中，我们从下往上看，又或是从上往下看：学生，工程师，CTO好像都在一个位置啊？说的抽象一点，我们把位于螺旋上的位置做一个垂直投影，他们重合在了一个点。（这就是线性思维的后果）。可是我们稍微多想一步就会明白，这三个职位根本不在一层上啊。

        上文中迷惑性的描述，加上理论和实践这种循环往复的关系，使得这种描述变得极具迷惑性——它让你感觉初学者和工程师在一个位置上了。同样是从实践开始，但是要知道，工程师的从实践开始可是经历了前面两个步骤的，我们活生生地把这两个步骤就这么跳过去了。毫不夸张地讲，这就相当于盖高楼的时候，跳过了地基和1~5层，直接从6层开始建了，后果恐怖得令人发指。如果你在盖楼，那么从6层摔下去的是你的砖头，你的木头，你的玻璃。而如果学习的时候这么干，被摔得粉碎的，将是你学习的信心和热情。

到底先理论还是先实践？

        就我个人而言，我觉得过分强调“相对”是一种不负责任和缺乏深入思考的表现。这些言论觉得什么都对，什么都能说通。可问题是，这有任何方法论指导意义吗？想必各位在复习考试的时候，总有老师说这书里所有的东西都可能考这种片汤儿话吧。这是典型的不负责任，而且这种言论相当不科学。科学的言论既可以证实又可以证伪，你告诉我所有东西都可能考，这话怎么证伪？考了说明你对了，不考的话，又因为你说可能考，也不能说你错......关键在于，他们没有深入思考问题所在的领域，和两个对立面所占的比重对人们的影响。对于很多问题，你的能力过不过硬，就体现在你敢不敢，有没有水平就一个具体问题提出绝对性的，有方法论指导意义的判断。如果你认同我的观点，那你一定会想：你说这么半天，那学习到底先理论还是先实践啊？那我给一个绝对的答案：先理论。

       说到这，想起李笑来老师关于学习的一句话：所有初始阶段的学习科目，概论绝对是最重要也是最难的一章。虽然教授编程的老师很多都从实际的需求引入理论和概念，我本身也觉得这样非常有助于自己的学习。但是需要指出的是，并不是所有的理论都可以从实践引入的。这时你所要做的就是上来就掌握一些貌似你感觉"没用"的理论。这也是概论为何学习难度如此之大的原因。所有的高难学科几乎都有一个特点，那就是本章的内容需要后面章节的某些内容辅助才能深入理解。（可是你明明就把这一章放在前面了啊...）初学一门课程，你对它所在的那个世界的所有知识都是空白，要求掌握经典的理论绝对是相当吃力的一件事。可它又是必须掌握的，因为不掌握这些理论，后面的学习不仅举步维艰，而且可能事倍功半。

       这就又可以拿学习编程来举例子，而且是我的亲身经历。前些日子学习C#里面Windows编程的一些基础内容，试着做一小音乐播放器，但是在利用LRC文件显示歌词的时候遇到了麻烦。

在当前音乐播放时间处于两句歌词时间的中间时，显示前一句歌词。看起来再简单不过的逻辑了，但是有点经验的人一看就知道这代码有问题，循环到最后一位索引的时候，判断条件的i+1直接越界了...然而就这么个问题困扰了我许久。有的人看了我的问题跟我说：你去补习一下数据结构吧...我默默的流着眼泪赞同一下...另一位仁兄更是一句话就帮我解决了问题：最后一句歌词，判断的时候只判断左边界。（你都是最后一个了你还判断右边界干啥？很简单的逻辑...）而且这位仁兄有一句话说得好：先有逻辑，后有代码。逻辑这个词估计从哪个角度理解都应该属于理论的范畴吧。显然像我这样的，就属于逻辑还不清晰就写了代码，结果就是基本毫无价 值的，费时费力的，低效的实践。而更可怕的是，这事就发生在一周前——当我已经彻底意识到了理论功底重要性的时候。各位读者，这样的实践你们要吗？

       由此又可以引发一个论题，那就是理论指导下的实践是有效的，高效的实践。有些同学又在想了，我少了理论学习的时间，我在实践上补回来了啊。又是一个糟糕的线性思维。平时说的好好的：该做事的时间不做事，需要的时候你要用数倍于当时的时间和精力来补上。怎么到这又成了实践上可以补回来了？扎实的理论学习，使得实践得以高效地进行。糟糕的理论学习，让实践变成了上一段描述的笔者那样的实践——还不如摊煎饼的活——摊煎饼也可以约摊越熟练，摊出来好歹能吃呢。

      

       在这里我还想说关于理论和实践的关系层面，运用线性思维的危害的另一个例子。想象一个场景：一个成功人士，轻轻松松地完成着各种价值巨大的劳动。这时候我们常常会听人说：你光看见人家光鲜了，你看见人家背后的努力了吗？对于这种话，我真的只能是不屑一顾。原因还是一样，它没有什么指导意义。咱们分析一下这句话，它的意思是想告诉你，他在人前做事很容易，背后做事很艰难（都摆上努力这种字眼了，能不难么）。它强调的是做事的难度这个单一维度的难和易——程度问题。看起来和文中开始提到的理论和实践的先和后是不是惊人的相似？这就是分析问题的时候仅仅留在了单一的维度考虑程度问题。我们需要做的，是站在不同的维度上考虑层面问题。同样是这个场景，我觉得这样说会更合适：你光看见人家做事做的漂亮，你看到人家背后深厚的理论功底了吗？前一句是从实践的层面看出别人做事做的漂亮，后一句分析这个现象背后其实是他内在的理论基础给了他巨大的支持。这就是不同的维度考虑层面问题。 面对这个复杂的世界，我们需要做的就是：多从层面角度考虑问题，少从程度角度考虑问题。

       这样一来，当看到硅谷的工程师们写出那么多高质量的代码，做出一个个出色的APP和网站之后，你自然会明白他们能做项目，背后是有强大的理论功底作支撑（而这些是你看不见的），比如你正在学的数据结构，计算机组成原理，编译原理......你就会明白那么厉害的人也是从一个初学者做起的，你自然不会焦虑，自然就会塌下心来好好练习基本功，自然也就有可能向着优秀的工程师和架构师的方向去发展和提升自己。如果你听到是前一种版本的话呢？你会觉得：哇人家太努力了，人家太优秀了，人家优秀因为人家努力，比我优秀的人还比我努力，那我能干什么呀......（这些字眼笔者在敲上去的时候都觉得令人反胃）越发焦虑，越发破罐子破摔，然后失去了原本完全可以拥有的进步的机会。你看，就源于一个线性思维，这后果多么可怕？

      

       另一个“先理论”的原因是，很多理论那都是前辈们用宝贵的时间和精力“试”出来的，甚至可能是用血“淌”出来的。有一句说得好：不听老司机话的人不值得同情。在已经有了这些理论给你铺路的条件下，你是还想浪费你宝贵的实践和精力再去“试”一把？还是用你的血去“淌”一把？各位读者，这样的实践你们要吗？

坚持做正确的事会面临压力

       真理掌握在少数人手里，这话不假。问题是，这少数人知道了这些道理并践行，让自己有了巨大的提升以后，他们把这道理告诉那“多数人”之后，那些“多数人”不仅不会学习这些道理，反而会去嘲笑和讽刺甚至攻击这些“少数人”。或许是看到了这些“少数人”的进步，他们已经心理彻底失衡了吧。当有人告诉他们：凡事全靠积累。他们会说：巨大的事情背后一定有巨大的阴谋！我就不信成功没有秘诀！当有人告诉他们：一年的时间是可以成为合格的全栈工程师的。他们会说：别侮辱全栈这个词了。很显然，他们觉得全栈工程师不可能这么短时间就能做成——我自己做了这么多年还不行呢！更显然的是，他们觉得自己的智商受到了侮辱。其实哪里是什么智商不智商的问题，当别人掌握了你所没有深入思考过的朴素的道理，你不仅不去取经，还去诋毁和谩骂，这分明就是你自己放弃了进步的机会。（你现在可以想象人和人之间的差距为什么比人和狗之间的差距更大了吧？）

       反过来，当我们笃信一件事情是正确的（比如学习就是要打好理论功底再实践），并且去做的时候，压力就接踵而来。当经历了直接跳过初学者和程序员，直接开始干工程师的活的这令人崩溃的两年以后，我觉得我真的有必要好好去补习自己的基础概念和理论了。其实越来越多的过来人都在跟我们说：你以后能走多远，高度能到多高，看你的基础有多扎实。问题是，学校里的老师不见得这么看，他们还被第三段那令人迷惑的描述迷惑着，认为在培养我们在做工程师的活。同学不见得这么看，他们也被这迷惑性的描述迷惑着，认为自己在做工程师的活。于是，我的选择只能是逃掉从那种类似从六楼开始直接建房子的课程，去补习基础——我不得不放弃百分之百的安全感。我的选择也可能会让以后的研究生导师认为自己没有水平——连个项目也做不出来，能有啥水平？我的选择更没有办法让我有资本跟周围人吹牛逼——人家哪知道值传递和引用传递，人家哪知道委托和事件是怎么回事，人家哪管地理数据集到底是同一类型的要素类的集合还是具有同样空间参考的要素类的集合？你丫就说你做了什么项目吧？没有你说什么？

       面对这些压力，坚持做正确的事，着实不易。不过既然我们知道凡事皆靠积累，知道耐心是多么重要，知道理论基础是多么重要，我们就拥有了最强大的抗压法门——我们不是因为笃信这些事是正确的才这样做的吗？其实我也从来不想说服别人什么，热脸贴冷屁股的事，我也做了不少。孰是孰非，没有时间的考验谁说了都不算。实践和理论——这可能是世上最纠缠不清的一对情人，他们的关系应该是什么样的？同样地，时间依然会给出最绝对，最冰冷的答案。