位元詩人 技術雜談:教程、範例、指引、原始碼:由淺至深的學習之路

Facebook Twitter LinkedIn LINE Skype EverNote GMail Yahoo Email

前言

許多初學程式設計的讀者,會不知道怎麼選擇合適的教材,平白耗費了許多時間卻抓不到方向。基本上,程式設計的教學資料可分為四個層次:教程 (tutorial)、範例 (example)、指引 (reference)、原始碼 (code)。在理想的情形下,假設我們有充足的學習資源,透過這四種層次的學習,就可以逐漸掌握某個語言、函式庫或框架。

教程 (Tutorial)

教程是最淺白的學習資料,大部分的技術書籍和線上課程都是某種教程。

理想的教程會按部就班,從概念、建置環境、Hello World 然後開始教基本語法,一次不會加入太多概念,讓讀者可以慢慢吸收。

有些教程會附上一些習題,讓讀者複習先前所學的概念,理想上的習題不會超越目前所學的概念,因初學者可能會無法辨識是自己的能力面還是教程的先導知識不足。

對於較缺乏經驗的學習者來說,有好的教程的確可以幫助學習者早日脫離新手村。

範例 (Example)

範例則是另一種形式的學習資料,一般的範例是為了展示某個函式庫或框架的使用方式,像是 Unity 和 Corona 等遊戲框架都會附上一些範例程式來展示其 API 如何呼叫。

由於閱讀範例需要學習者自己追踪專案程式碼,稍微需要一點點程式設計的經驗。大部分的範例會比真正的應用程式短得多,通常會附一些註解,讓學習者易於追蹤。有些網友會建議學習者上 GitHub 或其他同質網站找專案來看,但 GitHub 上的專案有些規模過大,其實不適合做為初心者學習之用。

指引 (Reference)

指引像是語言、函式庫、框架等軟體工具的字典,主要是用來查閱某個函式或方法如何呼叫,通常不會逐字閱讀。

對於程式設計者來說,從教程和範例的舒適圈跳到指引是必經之路,因為教程和範例不可能鉅細靡遺地將所有的 API 寫出來,就像字典不會將所有的單字都寫相對應的例句和例文。

初學者會以為程式設計師要把所有的 API 記在腦中,但其實知名的程式專案的 API 都會放在網路上供人查閱,根本不需要背誦;而且,API 的用法每隔一陣子可能會因不同因素而改版,硬記這些東西其實沒啥助益。

原始碼 (Source)

原始碼則披露程式內部實際運作的過程,沒有什麼東西比原始碼更真實了。早期的程式人將原始碼視為私人資產,不會輕易將原始碼嚗光,後來隨著開放原始碼運動,程式人才逐漸意識到原始碼也是可以分享的。

不過,閱讀程式碼相對耗時而且容易遺忘細節,如果前述的各類教材寫得夠好,不太需要逐行地閱讀程式碼。程式碼通常只有要在了解該工具內部運作時才需閱讀;筆者偶爾會因某專案文件不足而去閱讀其原始碼。

結語

商業公司的專案有現實利益的驅動,通常都有基本的教學文件可看,也會有一些書籍可參考。所以,有商業公司推動的語言往往比較容易學習。

由社群所推動的專案有時就沒那麼好命,通常都是有程式碼但缺乏足夠的教學文件,這時候,程式設計者僅能從少數的教學材料去拼湊出自己所需的功能。

對於技術人來說,這或許是化阻力為助力的時機,如果網路上缺乏教學文件,何不自己寫呢?不僅可造福社群,也可以給未來的自己留個筆記。如果某個議題在當下需要花費心力才能兜出解決方式,有可能在未來又要重新思考如何處理相同的議題,這時候,先前所做的筆記就可以發揮作用了。

關於作者

身為資訊領域碩士,位元詩人 (ByteBard) 認為開發應用程式的目的是為社會帶來價值。如果在這個過程中該軟體能成為永續經營的項目,那就是開發者和使用者雙贏的局面。

位元詩人喜歡用開源技術來解決各式各樣的問題,但必要時對專有技術也不排斥。閒暇之餘,位元詩人將所學寫成文章,放在這個網站上和大家分享。