程式設計知識的片段化

過去曾經寫過一系列名為「程式設計2.0」的文章，主要是提到了在網路如此發達、資訊交流如此快速、頻繁、豐富的情況下，對於程式設計的模式都產生了很大的衝擊，甚至造成了模式上的改變。

網路社群集結改變了軟體開發方式
尤其是各大論壇上的討論及回答，對於許多程式設計者在設計時會遭遇到的共通問題，時常都能夠提供很大的幫助。因此，過去可能要耗費數日光陰都不見得能解決的問題，透過網路的搜尋引擎，很快就能在散布在全世界各地的討論中，找到和你問題相關的解決方式。你也可以透過類似的方式，找到各種你所需要的範例程式碼；有些時候，你甚至稍微修改一下程式碼，就可以直接將它們套用在你的專案中。

這當然是一個很大的進步，天下資源更輕易地為你所取用。原本要花上大量時間的工作，都可能在極短的時間內完成。在過去我就曾經提過，在網路中找到自己所需資源的技巧，將會成為程式設計者的重要技能之一。

不論是找到教學文章、找到問題的解答、或是找到所需的程式碼片段，甚至是整個開放原始碼專案，都能夠對程式設計工作起很大的作用。

尤其，是在stackoverflow.com這樣鎖定程式設計領域的問答網站風行後，更可以看到一個現象，就是許多程式設計者可以很容易在這樣的網站找到答案，也就更願意在其上發問，而這也使得它們，愈來愈能夠收集更多程式設計者在日常開發生活中，可能會遭遇到的種種問題，使得這些問題的廣度愈來愈大。

若是能夠讓更多的程式設計者參與討論及回答，其答案的深度及品質也會愈來愈好。而且，透過搜尋引擎的協助，程式設計者更可以輕易將自己的問題，關聯到網站上的問與答，進而很快從中找到可能的答案，並且判斷那些答案符合自己的需求。

我曾經聽過一個朋友在Facebook上，感嘆了一句：「若是沒有stackoverflow，好像都不知道該怎麼寫程式了。」由此可見，此類網站在目前對許多程式設計者的重要性。

相關知識的掌握變得片段化

不過，我觀察到，這的確改變了程式設計者學習新技術，或吸收新知識的方式。

程式設計者似乎更不耐於把許多冗長的教學文章好好細讀完畢，才著手開始進行程式設計，他們反而是轉為以程式範例為主，先試著在網路上找到若干個和自己目的相似的範例程式，然後開始著手修改，將它修改成自己想要的面貌。很多時候，目的可以很快達成，程式設計者也得到了很高的生產力，但是這背後其實暗藏一些兇險。

這些凶險其實都源自於一點，使用這些範例程式碼的人，往往並未全盤了解這些程式碼真正的行為，以及它們之所以如此被設計的原因。很多時候，他們甚至不明白程式碼中所使用技術的原理。程式碼經修改後、整合進來，或許表面上滿足需求了，或許在系統裡產生額外的效應，卻是他們所無法預期的。

不過，除了這點以外，我想這個現象背後還有一個值得討論的議題，那就是知識的片段化。

我們在學習一項新事物的時候，愈來愈少像過去一樣，打開一本書，按著其中的章節先後順序，一章一章地讀完，確保自己對整個觀念或是技術有全貌的認識（那怕只是入門的水平）之後，才開始進行程式設計的工作。即使許多技術書籍都有電子化的版本，願意耐著性子把書讀完的人，愈來愈少。因為從網路上取得的資源，常常足以讓程式設計者提前開始有所產出。

就像本文先前文字中所說的，他們只需要先找到和目的差不多的程式範例，接著改成自己想要的結果，不需要搞懂所有的細節及運作方式，只需要想方設法讓程式碼得到自己所要的介面，接著和自己現有的程式模組整合在一塊就成了。但在不了解背後運作方式的情況下，若是遇到了問題，怎麼有辦法呢？不打緊，把問題到丟上Google，或是stackoverflow就好了，常常很快就能找到答案。

從程式元件化的角度來看這並不算太差，你不需要搞懂一個黑箱裡究竟在做些什麼，你需要的是生產力，而上述的模式可以幫助你得到生產力。對於這個黑箱裡的新事物，若是在之後你需要針對它除錯、針對它修改擴充時，你就會因為必須更深入地閱讀其中的程式碼，而能了解其運作方式。

但是透過這種方式來學習，就像是我所說的「知識的片段化」，你對新觀念或新技術、甚至只是新的程式庫或應用程式框架的學習，不再是依循一個有脈絡可循的學習路徑，而是經由拼湊散落在四處的範例程式碼、問答說明來組成。這樣子的方式，很多時候行得通，而且更有效率，提供了更直接的生產力。但是最大的問題在於，你不容易辦法透過這種方式認識全貌－－認識一項新技術背後的原理，或者是它的中心思想。

「技」與「道」的拿捏
有些技術透過這種方式來學習是比較適合的，因為它們「技」的部份多，「道」的部份少。有些觀念，卻是「道」的部份多，「技」的部份少。從知識的片段要領略「道」並不是不行，只是難度多半勝過循著完整的知識脈絡體系來習得，就是了。

此外還有一個問題是，利用這種散落的知識片段來解決問題，有時候是「知其然，而不知其所以然」，你知道了how，卻不見得知道了 why。這等同於限制了你對事物瞭解的深度，也限制了對原理的認識。

這也是為什麼我們需要讀經典書籍或文章的原因。因為它們往往能闡述「道」，而不光只是「技」的部份。當然，它們會更著重在 why， 而非 how 的部份。

不過我想，閱讀經典的技術書籍，和從這種有效集結知識片段的方式，兩者是可以相輔相成的。雖然，坊間有很多書籍也只講「技」，不講「道」，它們和知識片段的集結也相去不遠，而且可能還更沒有效率。但是，我們還是可以找到一些經典的程式設計書籍，不論是講觀念的、講技術原理的，在作者的精采寫作鋪陳下，清晰的將觀念及原理表達出來。透過這些書籍，我們得窺程式設計「道」的部份。而有了「道」，那麼就容易駕馭「技」。

當你懂得「道」的時候，即使你看到的只是片段，你會知道這個片段是基於什麼原理。你會更容易明白為什麼一段範例程式會這麼寫，以及某一個特定的問題為何是如此的被解決。如果你懂得編譯器的設計原理，當你遇到編譯器的奇怪問題，再看到解法時，你會明白，這個解法是基於什麼道理，所以才能解決你所遭遇到的問題。

舉例來說，我們在網路上，可以找到很多人天天為了連結器（linker）的錯誤訊息在頭痛而發問，當然他們也可以找到對應的解法方法，但是，如果他們可以懂得連結器的原理及運作方式，這些錯誤或許就不會一犯再犯。你可以透過特定的知識片段，像是問答網站上的答案，來解決你眼前的問題，可是你不見得能明白中心思想。

不過，如果你懂得背後的道理，或許會不小心犯錯個一次，但對原理的了解會讓你知道日後該如何避免類似的錯誤，這便是我說的，有了「道」，那麼就容易駕馭「技」。因此，若能以經典書籍的道為骨幹，輔以有效率的知識片段集結，應該會是個不錯的方式。