震惊!靠看书永远都学不会编程!千万人深受其害!

基友写代码总有一个想法,“这题我不会,让我先看!饱!书!再写代码”。

这个观念很难扭转,但是事实是,任何时候,靠看书都是学不会代码的。
最好的方法就是稍微看一下语言的特性和直观外表,就着手写代码,肝肝肝淦淦淦。

让不才兼劣生逐条说出理由。

1.编程最需要的能力是什么?

是对计算机相关的知识储备吗?是XX年编程经验吗?

都不是。编程最重要的,是解决未知、复杂问题 的能力。
面对未知领域需要不发怵,能慢慢思考分析出一些切入点,整理整个问题的脉络。
面对复杂问题,能简化它,先从整体审视,再进入细节。一步步地完善解决方案。

从认知心理学的角度讲,就是通过编程的锻炼,提高认知的复杂度。“复杂度越高,接触新的、复杂的事物的时候,就能与已有的认知结构点(知识点)产生链接,通过这些链接的指引,掌握新事物就变得容易,也不易产生认知失调。”

做程序开发,总是面临新的需求,新的技术,新的框架,新的语言,新的项目。无论技术怎么更新,解决问题的能力总是能让你快速适应,快速走入正轨。

很明显,看书没法锻炼这个能力喔。

2.教科书并不擅长教学

教科书很大的缺点就是,需要严谨,需要严格定义,易读性可以随意牺牲。

你可能在C语言的教科书上看过对形参这样的定义:全称为“形式参数”,是在定义函数名和函数体的时候使用的参数,目的是用来接收调用该函数时传递的参数。

涡则发?
这是教初学者的态度吗?

这个说法,太形式化了,太严谨了,人们去获得一个初步的理解就需要思考很久了。文绉绉的名字很难靠直觉去理解,形式化的描述又不亲民,与其说是在教学,不如说在劝退,用艰涩的名词把人吓跑:“程序员这种月薪过万的职业,不是你们这种弱鸟可以染指的。”

这些文绉绉的名词和形式化的描述联合起来,光理解就非常困难了,要怎样记住呢?就算你记住了,对你编程的帮助又有多大呢?

更何况,这些名词的选取都是出于最初的编者、译者的翻译。受限于编者、译者水平,这些名词的选取未必是最好的。举个例子,还是“形参”和“实参”这两个名词,我觉得更好的描述是“绑定(到函数的)变量”和“自由变量”。

总之,看书学不到编程思维,还容易把精力花在无关紧要的记忆和理解上。

3. 书太厚了

我曾听闻一个传闻,IT出版社对书的厚度有一定的要求,必须要够厚,够充实。否则不允出版。动辄数百页,十余万字的书,如何看完呢?如何记住呢?如何灵活运用呢?

对于老手来说,有办法。把自己的大脑当成一个解释器,用自己运行代码。如果能运行得通,那么这一章节的内容就算是掌握了。自然语言是模糊的歧义的,但是计算机的语言是精确的无二义的。十行代码能描述的,也许比千言万语还多。

但是新手太难抓住重点了,眉毛胡子一把抓,看来看去看懵自己,也许只记住了非重点的只言片语。

4. 书的表述能力有限。

就算IT大牛写的书,真的就是好书吗?这又双叒叕不一定了。

对于新手来说,一本书要好好的分章节,分解成许许多多小的问题仔细叙述。
但是一个完全未知的问题,你最少要解释清除以下5部分的内容:

a, 这是什么情况下会出现的问题?
b, 造成这个问题的(直接,间接)因素是什么?
c, 这个问题的表现(表象)是什么?
d, 这个问题的解决方案是什么?
e, 这个问题的特殊情况有哪些?

教科书会把后两个问题解释得非常严格、标准。

然后读者懵逼于:这塔码到底是在干什么?这样做有啥意义呢?学不会呀!

结论

还是直接写代码吧!多思考,多谷歌,不会了稍微查一查书,抓住重点记忆。这比看书省时省力多了。

PS:以个人经验,我一开始就没有纠结过高大上的名词。我大三都不知道什么是实参,什么是形参,一切都是自然而然的运用和理解。我也不管是“面向对象的”,“面向过程的”,“命令式的”,“函数式的”。我也不管“设计模式”。但是我对“面向对象编程的理解”,起码不弱于自夸XX年开发经验的老手了。

你可能感兴趣的:(震惊!靠看书永远都学不会编程!千万人深受其害!)