作份早餐,多少因素要考慮?光是烤個土司、煎個荷包蛋、煮個咖啡,就得事先買好土司、蛋跟咖啡,隔天得早起料理,用餐完得清洗餐具,想到這麼麻煩,許多人寧可就近到早餐店、點份餐,中餐或晚餐大概也是類似方式解決,在速食文化下,誇張卻常見的現象,是在便利商店就能解決三餐,不少便利商店更以此作為廣告噱頭。

Hello World的本質
當面對的問題太複雜時,人們就會開始傾向簡化問題,幫助自己從複雜問題中解脫。光是吃東西這件事就可看出端倪,更何況是面對日新月益的技術問題,新技術不斷出現,消化卻需要時間,現在學到的東西,可能在一年半載後過時,在技術如雨後春筍般不斷冒出的情況下,為了吸引開發者,也就各自提出速食店般的號召技倆。

例如有程式語言標榜,如何簡單快速地寫出第一個「Hello World」,然後明確或暗示地告訴你:「看!這樣就可以顯示Hello World,這語言好簡單」。

使用Hello World來作為程式語言的第一個範例,本身並沒有什麼錯,只是許多使用者忽略了顯示Hello World的背後,仍有一定的複雜度。有沒有想過,為什麼一定要顯示Hello World?若要顯示「哈囉世界」呢?

對某些語言來說,這個問題很容易解決,只要鍵入中文就好,但對某些語言來說,可能就無法執行;也許某些語言要顯示「哈囉世界」只要鍵入中文,但顯示「哈囉!王大犇!」就出問題,按照現在許多文件或書籍介紹Hello World的方式,如果真有王大犇這個人,他可能很難成為程式設計師吧!

也許沒人取名為王大犇,但常有開發人員從未想過,撰寫程式時使用的檔案到底是什麼編碼?!更別說日後遇到程式執行出現亂碼時,有能力瞭解原因與解決問題。

Hello World式的號召,並非僅出現在程式語言。有些工具可能告訴你,用拖拉方式就能建立視窗文字編輯器,有些程式庫可能會告訴你,如何用10行寫出自動提示文字的搜尋框,有些框架可能告訴你,如何十分鐘快速地開發出BLOG,這樣的速食文化下,不少技術書籍也開始強調一本書就可習得所有技術,標榜短時間上手開發網站。

成熟的使用者看到Hello World式的範例,自然會去作深度的瞭解。遇到可自動化的工具,必然探討產生的程式碼為何。引用可封裝細節的程式庫,就會對底層實作細節產生好奇。使用可簡化設定的框架,自然會思考框架設定的流程是否符合需求。

這樣的模式下,即使技術某些地方不盡人意,也有能力自行開發或修改;即使有些工具、程式庫、框架尚未深入接觸,也不至於產生焦慮。

不成熟的使用者面對Hello World式的範例,反而會像看到浮木般地瘋狂擁護,不顧是否符合框架流程,只為迎合潮流而使用,不理解底層原理,只會依樣畫葫蘆或照表設定。

語言差異的本質

處於現在這個世界中,資訊的取得、傳遞相當方便。打開瀏覽器隨手搜尋就可取得想要的基本資訊,取得資訊似乎不耗成本,然而並非如此,由於資訊的傳遞過於方便,任何人都可以將自身意見透過網路對世界傳播,眾口紛云,有時取得的資訊本身也夾帶著雜訊,過濾資訊中的雜訊成了一種成本,取得資訊的成本越來越低,但過濾資訊的成本越來越高,最終有用資訊的成本存在一個臨界點。

傳遞雜訊而非資訊的一個例子,就像某些程式語言的擁護者,往往善於批評其它語言的缺點,用以強調所偏好語言的優點,這似乎是人之常情,也容易製造話題吸引更多人的目光。

有些使用者在擁抱另一門語言時,會如連續劇般,將當初摰愛的優點說成是缺點,甚至在擁抱另一門語言技術時,如上演恐怖片般地加上駭人口號「XXX 已死」。

亂世出英雄,散佈雜訊有時目的在製造混亂,看能不能趁亂闖出一片天地。而移情別戀不需打擊舊愛,琵琶別抱不需殺人標題。如果帶著批判眼光看待另一門語言,只是限制自己的思維,看不出語言間設定的模型相似與不相近的部份。

針對程式語言,成熟使用者會有的認知是,完美語法的語言不一定受到重用,缺點滿身的語言也未必受到冷落,任何語言都有其優點與缺點,也有其興起的時空、條件與應用平臺。在學習另一門程式語言時,應該深入理解該語言與已知曉的語言相似部份為何,不相近部份在哪,使用程式語言時,應盡量善用其優良部份、避開語言中不良的設計,如此在面對不同語言時,才可以持更開放的態度,立場才不至於搖擺,才可以看到各種語言的模型以及想解決的問題,甚至讓各種語言的觀念彼此激盪,讓不同語言的優良設計觀念彼此融合應用。

技術生態的本質
使用何種程式語言重不重要?使用何種技術重不重要?這個問題本身也被簡化了。選擇一門語言或技術,不僅是在選擇語言或技術本身,而是在選擇背後整個生態系,評估一門語言或技術,也應當評估背後整個生態系,而不僅是語言技術本身,這個生態系可能包括語言技術本身的製訂方式、應用平臺、支持廠商、開發工具、程式庫或開放原始碼專案、書籍、文件、使用者社群等,語言或技術的重要性,往往不在於語言或技術本身細節的學習,而在於瞭解整個生態文化的過程中所需付出的成本。

單就程式語言本身而言,資深開發人員雖然有可能在幾天內了解語法,也可無視於語言的慣例或文化,將應用程式或專案改用該語言實作,然而通常無法真正發揮語言的長處,最後只會像是用C風格寫Java,用Java風格寫JavaScript。真正要發揮語言的長處,就要了解語言的慣例與文化。

例如循序處理物件清單時,視所採用的語言本身是否支援函式物件而定,就可能有截然不同的寫法,可讀性與維護性也就截然不同,光是為了要掌握語言間諸如此類具差異性的慣例與文化,有經驗的開發人員通常就得花上一到兩個月的時間。

技術速食化的結果常導致低估了選擇技術的成本,有些開發人員被Hello World式的範例吸引,投入了一定的時間成本之後,才逐漸發現語言某些特性造成限制、某些功能沒有適當程式庫,或工具輔助、框架流程不符合需求,這都是沒有了解語言慣例與文化的結果。

語言慣例與文化常來自背後更大的生態系,面對龐大的生態系,資深開發人員可能需要三個月到半年,才有辦法熟悉到一定程度,從容地從生態系中擷取所需資源,在必要的時候與社群成員溝通。

掌握不變的本質
在看似變動的世界中,其實總有些不變的道理,技術中也總有其本質不變的部份。

不同的Web方案會提供不同的Session機制,然而無論Session如何抽象與簡化,使用方式再怎麼魔幻,無非都是建立於HTTP無狀態協定的基礎。從這樣的本質出發,就可思索背後實作機制,自然也會自然顧及相關安全問題。

提供各種功能的框架,無非背後就是在支援一套(或數量)重複性的流程。例如多數Web框架是基於MVC/Model 2流程再予以變化,是否採用這些框架?應思索該流程是否符合需求;例如Spring核心容器支援依賴注入,在採用前應思考應用程式中是否有眾多相依物件,相依物件間是否需要適時地抽換更動;採用ORM方案時,是否想過其實只需關聯式增刪查找,而非物件導向永續機制?

採用框架前,優先思考框架解決流程問題時帶來的方便性,是否遠超過繁瑣設定以及複雜程式庫帶來的麻煩,才不至於被框架中繁複功能與設定細節迷惑,真正獲得採用框架的好處。

 

作者簡介


Advertisement

更多 iThome相關內容