隨著眾多傳統工作面臨失業風險，編程成為21世紀必備的技能。網上有許多編程的資料，也有各種各樣的培訓班，但是很多都沒有抓住編程的重點方面，其教菜鳥的辦法很糟糕。為此，有20多年編程經驗的Rainer Hahnekamp總結了新手學習編程的5大支柱，希望初學者能夠從中掌握到學習的方法。

我編程都已經超過20年了。在這段時間內，很高興能跟很多人一起工作，我從他們身上學到了很多。同時我也接觸了很多的學生，他們都是剛剛大學畢業的新人，這時候我就得擔負起老師或者導師的角色。

最近，我作為培訓師參與到一項教完全的初學者學編程的計劃當中。

學習如何編程是很難的。我經常發現大學課程和新手訓練營沒有抓住編程的重點方面，其教菜鳥的辦法很糟糕。

為此，我願將我所認為的一門成功的編程課程必備的5大支柱分享給大家。一如以往地，我會將介紹放在主流web應用的背景下。

菜鳥的目標是掌握編程的基礎並且理解庫和框架的重要性。

像雲、一般運營或者開發工具這樣的高級主題不應該成為課程的一部分。說到設計模式我也持懷疑態度。這需要的經驗是初學者所不具備的。

那麼我們就來看看程序員新手應該從何開始。

基礎優先

我經常聽說菜鳥應該馬上從框架開始學習。這就好比把人放到賽車上讓對方避免轉向過度一樣教人如何開車。這根本是忽視了他們仍然會把剎車誤認成油門的事實。

一開始讓學生學Angular這樣的框架也是同理。初學者首先需要理解編程的基礎。在使用別人的代碼之前，的他們需要熟悉基本要素以及寫代碼意味著什麼。

函數、變量、條件、循環這些改變對於新手來說完全就是陌生的。這四個要素構成了編程的基礎。程序構成的一切都要靠它們。

學生都是第一次聽說這些概念，但是他們最終精通這些概念是極其重要的。如果學生沒掌握這些基礎，後續的一切看起來就像是魔術一樣，會導致迷惑和沮喪。

教師應該在這些基礎上花更多的時間。不過，悲哀的是，很多人向前推進得太快了。問題在於很多教師沒能從學生的角度去考慮問題。他們編程有些年頭了，已經忘了初學者必須應對的問題類型是什麼了。這相當類似於專業賽車手。賽車手是無法想象某人剎車前還要想一下的。他的動作都是自動的。

我設計練習會利用這四種要素的結合，一方面要具有挑戰性，同時在合理的時間範圍內又是可以解決的。

一個很好的例子是羅馬與阿拉伯數字的轉換。這個挑戰需要學生有耐心。一旦他們成功應用了4個要素解決了這個問題，其積極性就會得到很大的促進。

基礎很重要。在學會基礎之前不要貿然前進。

測試驅動開發（TDD）

TDD帶來了很多好處。不幸的是，這是一個高級主題，初學者恐怕還沒有完全準備好。

初學者不應該寫測試。對於他們的基礎技能水平來說這要求太高了。相反，他們應該學習如何使用測試以及配合測試。

每一門編程課程都應該以練習為核心。我把練習拓展到單元測試，給學生一個已經為運行那些測試做好設置的環境。

學生需要做的就只是寫他們的代碼然後看著testrunner的燈從紅色變成綠色。結果的遊戲化是一個很好的副效應。

比方說：如果選定技術是Spring，我在一個Spring項目內會提供練習和測試。學生不需要知道Spring的任何事情。他們所需要做的就是知道練習和觸發測試的按鈕在什麼位置。

此外，學生必須知道如何使用調試器並且要有一個讀取﹣求值﹣輸出循環（REPL）環境。在運行時分析代碼的能力以及有一個進行小型實驗的場地對於TDD要說是必不可少的。

要點是要確保學生在習得核心變成技能之後不需要學習基本的TDD行為。在學生職業生涯後期改變習慣要比現在學習這些習慣困難得多。這就是為什麼他們應該從一開始就感受單元測試的原因。

在其以後的職業生涯裡，他們應該會對沒有進行單元測試的項目感到厭惡。他們應該本能的將缺少單元測試視為反模式。

庫和框架

在學生花費了大量時間去編程後，他們必須知道大多數代碼已經以庫或者框架的形式存在了。這與其說是一種模式不如說是一種理念。

就像我之前寫過那樣：現代開發者瞭解並選擇合適的庫。他們不會浪費時間自己去寫一個充滿bug的版本。

要想讓這種理念轉變成功，“基礎階段”的例子應該用Moment.js、Jackson、Lodash或者Apache Commons等知名的庫來解決。

這樣一來，學生馬上就能理解庫的價值了。之前他們曾經絞盡腦汁去解決這些複雜問題。現在他們發現庫一下子就把那些練習給搞定了。

跟TDD類似，學生應該對同時吹噓自己編寫的狀態管理庫秒殺Redux保持懷疑態度。

說到框架，一旦理解了庫的用處之後學生理解其重要性就會毫無問題。

取決於課程的時間長短，專門開闢時間將框架也許會比較困難。但是正如我已經指出那樣，最重要的方面是心態的轉變——從一切都白手起家自己寫轉到使用庫來實現。

我沒有給這根支柱添加工具，因為工具只對有經驗的開發者有用。在現在這個早期階段，學生不需要了解如何集成和配置工具。

師傅與徒弟

我20出頭的時候曾想學鋼琴。我不想找老師，以為我自己就能學。5年後，我諮詢了一位專業家教。怎麼說呢。那1個月內我學到的東西就比我5年時間學到的還要多。

我的鋼琴老師指出了我在演奏過程中出現的錯誤，那些是我自己聽不到的，這讓我意識到一些我從未想象過的東西。畢竟，她給我灌輸了音樂和藝術的理念，這些都不是我這個搞技術的人能瞭解的。

編程也一樣。如果某人對編程毫無經驗，則自學就是個糟糕想法。儘管有很多成功故事，但我質疑其效率。

相反，應該有一種“師徒”關係。一開始時，師傅給出規則讓徒弟遵守——盲從！師傅可能會解釋一下規則，但通常推理會超出徒弟的理解範圍。

這些內化的規則會形成一道安全網。如果一個人迷路了，能保證有一些安全地帶可以返回。

教學不應該是獨白。師傅必須因材施教。應該看看學生是怎麼做的，然後給出建議，根據他們的進展情況調整課程速度。

挑戰與激勵

“我們來做個Facebook克隆版吧！”這話不是出自有一群資深開發者和數百萬歐元預算撐腰的CEO。而是來自一門針對程序員的介紹性課程的練習。這樣一項任務幾乎是不可能的。甚至更糟的是，學生被放到仙境裡面被哄騙以為自己有做超出自身能力的技能。

教師無疑是意識到這點的，但出於激勵的原因還是設立這樣的練習。

練習的主要目標不是娛樂。練習應該圍繞著特定技術設立，同時應該幫助學生理解那項技術。

激勵是好的，但不要犧牲掉內容：編程不易。如果學生缺乏內在動機，編碼這條路也許不合適。

新手應該體會到成為職業開發者意味著什麼。在投入大量時間之前他們應該知道等待他們的是什麼。

比方說，很多商業應用圍繞著複雜表格進行處理。創建表格是練習可以賦予的一項重要技能。開發類似Facebook那樣的應用也許不是學生馬上就能學習的最佳課程。

類似地，非程序員可能會對開發者每天寫的代碼行數至少感到驚訝。甚至有時候我們還刪除代碼或者一事無成。

為什麼？因為總有狀況發生。我們花費了無數時間去修復一些極其怪異的bug，結果最後發現只是拼寫錯誤而已。一些工具工作不了可能僅僅因為一個庫進行了小型的版本升級。或者因為某人忘記把一個文件添加到git而系統崩潰。這樣的事情可以一直列下去。

學生應該享受這些練習。在時間壓力下面向一個未知庫的練習未必合適。

現實生活中不是每天都充滿陽光。初學者應該對編程的現實做好充分準備。

最後建議

最後但並非最不重要的一點：一個人無法在2周、2月或甚至2年之內成為職業程序員。這需要時間和耐心。

想要在程序員生涯內有更高的成就的話，C/C++就是一個既可以強化思維能力，又可以打好編程基礎的編程語言，將來想要做軟件開發，有一份好的前景的話，學習C/C++的話筆者有一個C/C++的編程倆千人群（Q艘索：

閱讀更多 C語言編程學習 的文章

關鍵字: 設計模式 設計 大學