[轉載]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++) 這樣的題目到底是什麼意思:

學會: 在 3 天時間裡, 你不夠時間寫一些有意義的程式, 並從它們的失敗與成功中學習。你不夠時間跟一些有經驗的程式設計師一起工作, 你不會知道在 C++ 那樣的環境中是什麼滋味。簡而言之, 沒有足夠的時間讓你學到很多東西。所以這些書談論的只是表面上的精通, 而非深入的理解。如 Alexander Pope (英國詩人、作家, 1688-1744) 所言, 一知半解是危險的 (a little learning is a dangerous thing)
C++: 在3天時間裡你可以學會 C++ 的語法 (如果你已經會一門類似的語言), 但你無法學到多少如何運用這些語法。簡而言之, 如果你是, 比如說一個 Basic 程式設計師, 你可以學會用 C++ 語法寫出 Basic 風格的程式, 但你學不到 C++ 真正的優點 (和缺點)。那關鍵在哪裡？Alan Perlis (ACM 第一任主席, 圖靈獎得主, 1922-1990) 曾經說過:「如果一門語言不能影響你對寫程式的想法, 那它就不值得去學」。另一種觀點是, 有時候你不得不學一點 C++ (更可能是Javascript 和 FlashFlex 之類) 的皮毛, 因為你需要接觸現有的工具, 用來完成特定的任務。但此時你不是在學習如何寫程式, 你是在學習如何完成任務。
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.)

下面是我在程式設計這個行業裡獲得成功的處方:

對程式設計感興趣, 因為樂趣而去寫程式。確定始終都能保持足夠的樂趣, 以致你能夠將 10 年時間投入其中。
跟其他程式設計師交談; 閱讀其他程式。這比任何書籍或訓練課程都更重要。
程式設計最好的學習是從實踐中學習。用更加技術性的語言來講, 「個人在特定領域最高水準的表現不是作為長期的經驗的結果而自動獲得的, 但即使是非常富有經驗的個人也可以通過刻意的努力而提高其表現水準。」 (p.366), 而且「最有效的學習要求為特定個人制訂適當難度的任務, 有意義的反饋, 以及重複及改正錯誤的機會。」 (p.20-21) 《Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life》 (在實踐中認知: 心智、數學和日常生活的文化) 是關於這個觀點的一本有趣的參考書。
如果你願意, 在大學裡花上 4 年時間 (或者再花幾年讀研究生)。這能讓你獲得一些工作的入門資格, 還能讓你對此領域有更深入的理解, 但如果你不喜歡進學校, (作出一點犧牲) 你在工作中也同樣能獲得類似的經驗。在任何情況下, 單從書本上學習都是不夠的。「電腦科學的教育不會讓任何人成為內行的程式設計師, 正如研究畫筆和顏料不會讓任何人成為內行的畫家」, Eric Raymond, 《The New Hacker's Dictionary》 (新黑客字典) 的作者如是說。我曾經僱用過的最優秀的程式設計師之一僅有高中學歷; 但他創造出了許多偉大的軟體 (XEmacs, Mozilla), 甚至有討論他本人的新聞組, 而且股票期權讓他達到我無法企及的富有程度 (譯註: 指 Jamie Zawinski, Xemacs 和 Netscape 的作者)。
跟別的程式設計師一起完成專案。在一些專案中成為最好的程式設計師; 在其他一些專案中當最差的一個。當你是最好的程式設計師時, 你要測試自己領導專案的能力, 並通過你的洞見鼓舞其他人。當你是最差的時候, 你學習高手們在做些什麼, 以及他們不喜歡做什麼 (因為他們讓你幫他們做那些事)。
接手別的程式設計師完成專案。用心理解別人編寫的程式。看看在沒有最初的程式設計師在場的時候理解和修改程式需要些什麼。想一想怎樣設計你的程式才能讓別人接手維護你的程式時更容易一些。
學會至少半打程式語言。包括一門支援類抽象 (class abstraction) 的語言 (如 Java 或 C++), 一門支援函數抽象 (function alabstraction) 的語言 (如 Lisp 或 ML), 一門支援語法抽象 (syntactic abstraction) 的語言 (如 Lisp), 一門支援說明性規約 (declarative specification) 的語言 (如 Prolog 或 C++ 模版), 一門支援協程 (coroutine) 的語言 (如 Icon 或 Scheme), 以及一門支援併行處理 (parallelism) 的語言 (如 Sisal)。
記住在「電腦科學」這個名詞裡包含「電腦」這個詞。瞭解你的電腦執行一條指令要多長時間, 從記憶體中取一個 word 要多長時間 (包括暫存命中和未命中的情況), 從磁碟上讀取連續的數據要多長時間, 定位到磁碟上的新位置又要多長時間。 (答案在這裡)
嘗試參與到一項語言標準化工作中。可以是 ANSI C++ 委員會, 也可以是決定自己團隊的程式風格到底採用 2 個空格的縮進還是 4 個。不論是哪一種, 你都可以學到在這門語言中到底人們喜歡些什麼, 他們有多喜歡, 甚至有可能稍微瞭解為什麼他們會有這樣的感覺。
擁有盡快從語言標準化工作中抽身的良好判斷力。

抱著這些想法, 我很懷疑從書上到底能學到多少東西。在我第一個孩子出生前, 我讀完了所有「怎樣……」的書, 卻仍然感到自己是個毫無頭緒的新手。30 個月後, 我第二個孩子出生的時候, 我重新拿起那些書來複習了嗎？不。相反, 我依靠我自己的經驗, 結果比專家寫的幾千頁東西更有用更靠得住。

Fred Brooks 在他的短文《No Silver Bullets》 (沒有銀彈) 中確立了如何發現傑出的軟體設計師的三步規劃:

儘早系統地識別出最好的設計師群體。
指派一個事業上的導師負責有潛質的對象的發展, 小心地幫他保持職業生涯的履歷。
讓成長中的設計師們有機會互相影響, 互相激勵。

這實際上是假定了有些人本身就具有成為傑出設計師的必要潛質; 要做的只是引導他們前進。Alan Perlis 說得更簡潔:「每個人都可以被教授如何雕塑; 而對米開朗基羅來說, 能教給他的倒是怎樣能夠不去雕塑。傑出的程式設計師也一樣」。

所以儘管去買那些 Java 書; 你很可能會從中找到些用處。但你的生活, 或者你作為程式設計師的真正的專業技術, 並不會因此在 24 小時、24 天甚至 24 個月內發生真正的變化。

Vixual