Vixual

转载自: 酷壳 - 21 天教你学会 C++

下面是一个《Teach Yourself C++ in 21 Days》的流程图, 请各位程式设计师同仁认真领会。如果有必要, 你可以查看这个图书以作参照: http: //www.china-pub.com/27043

看完上面这个图片, 我在想, 我学习 C++ 有 12 年了, 好像 C++ 也没有学得特别懂, 看到 STL 和泛型, 还是很头大。不过, 我应该去考虑研究量子物理和生物化学, 这样, 我才能重返 98 年杀掉还在大学的我, 然后达到 21 天搞定 C++ 的目标。另外, 得要特别提醒刚刚开始学习 C++ 的朋友, 第 21 天的时候, 小心被人杀害。呵呵。

当然, 上面只是一个恶搞此类图片, 学习一门技术, 需要你很长的时间, 正如图片中的第三图和第四图所示, 你需要用十年的时间去不断在尝试, 并在错误中总结经验教训, 以及在专案开发中通过与别人相互沟通互相学习来历练自己。你才能算得上是真正学会。

这里有篇文章叫《Teach Yourself Programming in Ten Years》, 网上有人翻译了一下, 不过原文已被更新了, 我把网上的译文转载并更新如下:

用十年来学程式设计 Peter Norvig

为什么每个人都急不可耐？

走进任何一家书店, 你会看见《Teach Yourself Java in 7 Days》 (7 天 Java 无师自通) 的旁边是一长排看不到尽头的类似书籍, 它们要教会你 Visual Basic、Windows、Internet 等等, 而只需要几天甚至几小时。我在 Amazon.com 上进行了如下搜索:

pubdate: after 1992 and title: days and (title: learn or title: teach yourself)
(出版日期: 1992 年后 and 书名: 天 and (书名: 学会 or 书名: 无师自通) )

我一共得到了 248 个搜索结果。前面的 78 个是电脑书籍 (第 79 个是《Learn Bengali in 30 days》, 30 天学会孟加拉语)。我把关键词“days”换成“hours”, 得到了非常相似的结果: 这次有 253 本书, 头 77 本是电脑书籍, 第 78 本是《Teach Yourself Grammar and Style in 24 Hours》 (24 小时学会文法和文体)。头 200 本书中, 有 96% 是电脑书籍。

结论是, 要么是人们非常急于学会电脑, 要么就是不知道为什么电脑惊人地简单, 比任何东西都容易学会。没有一本书是要在几天里教会人们欣赏贝多芬或者量子物理学, 甚至怎样给狗打扮。在《How to Design Programs》这本书里说“Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.” (坏的程式是很容易的, 就算他们是笨蛋白痴都可以在 21 天内学会。)

让我们来分析一下像《Learn C++ in Three Days》(3 天学会 C++) 这样的题目到底是什么意思:

1. 学会: 在 3 天时间里, 你不够时间写一些有意义的程式, 并从它们的失败与成功中学习。你不够时间跟一些有经验的程式设计师一起工作, 你不会知道在 C++ 那样的环境中是什么滋味。简而言之, 没有足够的时间让你学到很多东西。所以这些书谈论的只是表面上的精通, 而非深入的理解。如 Alexander Pope (英国诗人、作家, 1688-1744) 所言, 一知半解是危险的 (a little learning is a dangerous thing)
2. C++: 在3天时间里你可以学会 C++ 的语法 (如果你已经会一门类似的语言), 但你无法学到多少如何运用这些语法。简而言之, 如果你是, 比如说一个 Basic 程式设计师, 你可以学会用 C++ 语法写出 Basic 风格的程式, 但你学不到 C++ 真正的优点 (和缺点)。那关键在哪里？Alan Perlis (ACM 第一任主席, 图灵奖得主, 1922-1990) 曾经说过:“如果一门语言不能影响你对写程式的想法, 那它就不值得去学”。另一种观点是, 有时候你不得不学一点 C++ (更可能是Javascript 和 FlashFlex 之类) 的皮毛, 因为你需要接触现有的工具, 用来完成特定的任务。但此时你不是在学习如何写程式, 你是在学习如何完成任务。
3. 3 天: 不幸的是, 这是不够的, 正如下一节所言。

10 年学程式设计

一些研究者 (Bloom(1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) 的研究表明, 在许多领域, 都需要大约 10 年时间才能培养出专业技能, 包括西洋棋、作曲、绘画、钢琴、游泳、网球, 以及神经心理学和拓扑学的研究。似乎并不存在真正的捷径: 即使是莫扎特, 他 4 岁就显露出音乐天才, 在他写出世界级的音乐之前仍然用了超过 13 年时间。

再看另一种音乐类型的披头士, 他们似乎是在 1964 年的 EdSullivan 节目中突然冒头的。但其实他们从 1957 年就开始表演了, 即使他们很早就显示出了巨大的吸引力, 他们第一次真正的成功 -  Sgt.Peppers  - 也要到 1967 年才发行。Malcolm Gladwell 研究报告称, 把在伯林音乐学院学生一个班的学生按水准分成高中低, 然后问他们对音乐练习花了多少工夫:

在这三个小组中的每一个人基本上都是从相同的时间开始练习的 (在五岁的时候)。在开始的几年里, 每个人都是每周练习 2-3 个小时。但是在八岁的时候, 练习的强度开始显现差异。在这个班中水准最牛的人开始比别人练习得更多 - 在九岁的时候每周练习 6 个小时, 十二岁的时候, 每周 8 个小时, 十四岁的时候每周 16 个小时, 并在成长过程中练习得越来越多, 到 20 岁的时候, 其每周练习可超过 30 个小时。到了 20 岁, 这些优秀者在其生命中练习音乐总共超过 10,000 小时。与之对比, 其它人只平均有 8,000 小时, 而未来只能留校当老师的人仅仅是 4,000 小时。

所以, 这也许需要 10,000 小时, 并不是十年, 但这是一个 magic number。

Samuel Johnson (英国诗人) 认为 10 年还是不够的:“任何领域的卓越成就都只能通过一生的努力来获得; 稍低一点的代价也换不来。” (Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price.) 乔叟 (Chaucer, 英国诗人, 1340-1400) 也抱怨说:“生命如此短暂, 掌握技艺却要如此长久。” (the lyf so short, the craft so long to lerne.)

下面是我在程式设计这个行业里获得成功的处方:

1. 对程式设计感兴趣, 因为乐趣而去写程式。确定始终都能保持足够的乐趣, 以致你能够将 10 年时间投入其中。
2. 跟其他程式设计师交谈; 阅读其他程式。这比任何书籍或训练课程都更重要。
3. 程式设计最好的学习是从实践中学习。用更加技术性的语言来讲, “个人在特定领域最高水准的表现不是作为长期的经验的结果而自动获得的, 但即使是非常富有经验的个人也可以通过刻意的努力而提高其表现水准。” (p.366), 而且“最有效的学习要求为特定个人制订适当难度的任务, 有意义的反馈, 以及重复及改正错误的机会。” (p.20-21) 《Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life》 (在实践中认知: 心智、数学和日常生活的文化) 是关于这个观点的一本有趣的参考书。
4. 如果你愿意, 在大学里花上 4 年时间 (或者再花几年读研究生)。这能让你获得一些工作的入门资格, 还能让你对此领域有更深入的理解, 但如果你不喜欢进学校, (作出一点牺牲) 你在工作中也同样能获得类似的经验。在任何情况下, 单从书本上学习都是不够的。“电脑科学的教育不会让任何人成为内行的程式设计师, 正如研究画笔和颜料不会让任何人成为内行的画家”, Eric Raymond, 《The New Hacker's Dictionary》 (新黑客字典) 的作者如是说。我曾经雇用过的最优秀的程式设计师之一仅有高中学历; 但他创造出了许多伟大的软件 (XEmacs, Mozilla), 甚至有讨论他本人的新闻组, 而且股票期权让他达到我无法企及的富有程度 (译注: 指 Jamie Zawinski, Xemacs 和 Netscape 的作者)。
5. 跟别的程式设计师一起完成专案。在一些专案中成为最好的程式设计师; 在其他一些专案中当最差的一个。当你是最好的程式设计师时, 你要测试自己领导专案的能力, 并通过你的洞见鼓舞其他人。当你是最差的时候, 你学习高手们在做些什么, 以及他们不喜欢做什么 (因为他们让你帮他们做那些事)。
6. 接手别的程式设计师完成专案。用心理解别人编写的程式。看看在没有最初的程式设计师在场的时候理解和修改程式需要些什么。想一想怎样设计你的程式才能让别人接手维护你的程式时更容易一些。
7. 学会至少半打程式语言。包括一门支援类抽象 (class abstraction) 的语言 (如 Java 或 C++), 一门支援函数抽象 (function alabstraction) 的语言 (如 Lisp 或 ML), 一门支援语法抽象 (syntactic abstraction) 的语言 (如 Lisp), 一门支援说明性规约 (declarative specification) 的语言 (如 Prolog 或 C++ 模版), 一门支援协程 (coroutine) 的语言 (如 Icon 或 Scheme), 以及一门支援并行处理 (parallelism) 的语言 (如 Sisal)。
8. 记住在“电脑科学”这个名词里包含“电脑”这个词。了解你的电脑执行一条指令要多长时间, 从内存中取一个 word 要多长时间 (包括暂存命中和未命中的情况), 从磁盘上读取连续的数据要多长时间, 定位到磁盘上的新位置又要多长时间。 (答案在这里)
9. 尝试参与到一项语言标准化工作中。可以是 ANSI C++ 委员会, 也可以是决定自己团队的程式风格到底采用 2 个空格的缩进还是 4 个。不论是哪一种, 你都可以学到在这门语言中到底人们喜欢些什么, 他们有多喜欢, 甚至有可能稍微了解为什么他们会有这样的感觉。
10. 拥有尽快从语言标准化工作中抽身的良好判断力。

抱着这些想法, 我很怀疑从书上到底能学到多少东西。在我第一个孩子出生前, 我读完了所有“怎样……”的书, 却仍然感到自己是个毫无头绪的新手。30 个月后, 我第二个孩子出生的时候, 我重新拿起那些书来复习了吗？不。相反, 我依靠我自己的经验, 结果比专家写的几千页东西更有用更靠得住。

Fred Brooks 在他的短文《No Silver Bullets》 (没有银弹) 中确立了如何发现杰出的软件设计师的三步规划:

1. 尽早系统地识别出最好的设计师群体。
2. 指派一个事业上的导师负责有潜质的对象的发展, 小心地帮他保持职业生涯的履历。
3. 让成长中的设计师们有机会互相影响, 互相激励。

这实际上是假定了有些人本身就具有成为杰出设计师的必要潜质; 要做的只是引导他们前进。Alan Perlis 说得更简洁:“每个人都可以被教授如何雕塑; 而对米开朗基罗来说, 能教给他的倒是怎样能够不去雕塑。杰出的程式设计师也一样”。

所以尽管去买那些 Java 书; 你很可能会从中找到些用处。但你的生活, 或者你作为程式设计师的真正的专业技术, 并不会因此在 24 小时、24 天甚至 24 个月内发生真正的变化。