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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者簡介


熱門新聞

Advertisement