基友写代码总有一个想法，“这题我不会，让我先看！饱！书！再写代码”。
这个观念很难扭转，但是事实是，任何时候，靠看书都是学不会代码的。
最好的方法就是稍微看一下语言的特性和直观外表，就着手写代码，肝肝肝淦淦淦。
让不才兼劣生逐条说出理由。
1.编程最需要的能力是什么？
是对计算机相关的知识储备吗？是XX年编程经验吗？
都不是。编程最重要的，是解决未知、复杂问题 的能力。
面对未知领域需要不发怵，能慢慢思考分析出一些切入点，整理整个问题的脉络。
面对复杂问题，能简化它，先从整体审视，再进入细节。一步步地完善解决方案。
从认知心理学的角度讲，就是通过编程的锻炼，提高认知的复杂度。“复杂度越高，接触新的、复杂的事物的时候，就能与已有的认知结构点（知识点）产生链接，通过这些链接的指引，掌握新事物就变得容易，也不易产生认知失调。”
做程序开发，总是面临新的需求，新的技术，新的框架，新的语言，新的项目。无论技术怎么更新，解决问题的能力总是能让你快速适应，快速走入正轨。
很明显，看书没法锻炼这个能力喔。
2.教科书并不擅长教学
教科书很大的缺点就是，需要严谨，需要严格定义，易读性可以随意牺牲。
你可能在C语言的教科书上看过对形参这样的定义：全称为“形式参数”，是在定义函数名和函数体的时候使用的参数，目的是用来接收调用该函数时传递的参数。
涡则发？
这是教初学者的态度吗？
这个说法，太形式化了，太严谨了，人们去获得一个初步的理解就需要思考很久了。文绉绉的名字很难靠直觉去理解，形式化的描述又不亲民，与其说是在教学，不如说在劝退，用艰涩的名词把人吓跑：“程序员这种月薪过万的职业，不是你们这种弱鸟可以染指的。”
这些文绉绉的名词和形式化的描述联合起来，光理解就非常困难了，要怎样记住呢？就算你记住了，对你编程的帮助又有多大呢？
更何况，这些名词的选取都是出于最初的编者、译者的翻译。受限于编者、译者水平，这些名词的选取未必是最好的。举个例子，还是“形参”和“实参”这两个名词，我觉得更好的描述是“绑定（到函数的）变量”和“自由变量”。
总之，看书学不到编程思维，还容易把精力花在无关紧要的记忆和理解上。
3. 书太厚了
我曾听闻一个传闻，IT出版社对书的厚度有一定的要求，必须要够厚，够充实。否则不允出版。动辄数百页，十余万字的书，如何看完呢？如何记住呢？如何灵活运用呢？
对于老手来说，有办法。把自己的大脑当成一个解释器，用自己运行代码。如果能运行得通，那么这一章节的内容就算是掌握了。自然语言是模糊的歧义的，但是计算机的语言是精确的无二义的。十行代码能描述的，也许比千言万语还多。
但是新手太难抓住重点了，眉毛胡子一把抓，看来看去看懵自己，也许只记住了非重点的只言片语。
4. 书的表述能力有限。
就算IT大牛写的书，真的就是好书吗？这又双叒叕不一定了。
对于新手来说，一本书要好好的分章节，分解成许许多多小的问题仔细叙述。
但是一个完全未知的问题，你最少要解释清除以下5部分的内容：
a, 这是什么情况下会出现的问题？
b, 造成这个问题的（直接，间接）因素是什么？
c, 这个问题的表现（表象）是什么？
d, 这个问题的解决方案是什么？
e, 这个问题的特殊情况有哪些？
教科书会把后两个问题解释得非常严格、标准。
然后读者懵逼于：这塔码到底是在干什么？这样做有啥意义呢？学不会呀！
结论
还是直接写代码吧！多思考，多谷歌，不会了稍微查一查书，抓住重点记忆。这比看书省时省力多了。
PS：以个人经验，我一开始就没有纠结过高大上的名词。我大三都不知道什么是实参，什么是形参，一切都是自然而然的运用和理解。我也不管是“面向对象的”，“面向过程的”，“命令式的”，“函数式的”。我也不管“设计模式”。但是我对“面向对象编程的理解”，起码不弱于自夸XX年开发经验的老手了。
