許多人說,程式設計是吃青春飯,40歲之後的老程式人,比不上精力旺盛、全力追求新技術的年輕程式人。

實際上各行各業都一樣,時間可以是最大的敵人,也可以是最強的盟友,差異在於歲月流逝之餘,經驗中是否含有年輕人必須花同等時間追趕的因子。

就程式設計領域來說,就是從新技術的拼裝上看不到,而是那些必須在逐步演化過程中,才得以積累的知識、思路與專業。

對效率的多角度思考
談到效率(Efficiency),很多人會想到Donald Ervin Knuth談過的:「程式設計者對效率的思考或擔憂,多數在程式中非關鍵部份,這類努力在除錯或維護時實際上會有很大的負作用。97%的情況下,過早最佳化是萬惡根源。然而,我們不該放棄那關鍵的3%。」,近來「過早最佳化是萬惡根源」這句話有被濫用的情況,Knuth的話中並沒有告訴我們,撰寫程式不需考慮效率。

對效率的探討是個逐步演進的過程,程式人過程中要懂得如何多角度思考。就算列印三角型這類簡單程式,在觀摩不同實作時,也會發現不同的思考深度。

學習資料結構與演算法就是在培養思考過程,單是排序就有多種方式,不同資料結構對搜尋也會有不同影響。現在不少程式庫實作了有效率的資料結構與演算法,如果經驗上已知某演算或資料結構可有效率解決某問題,那就應該使用對應實作,這並不會造成除錯或維護的負擔。

思考效率也可從數學方向著手,以計算1至N總合為例,不少程式人被程式語法制約採用了迴圈解法,然而數學上可用等差數列公式求得,費式級數也有公式解法。

對效率反覆且多角度的思考並非過早最佳化,有時多角度思考效率,也可同時對效率與維護發生助益,像是函數式的思考方向,經常可以清楚地分解問題,也有助於後續的效率檢討。

Knuth提到的,還有不要放棄關鍵的3%,這關係到如何實際測試以找出效率瓶頸,以及找到瓶頸後如何改進,這些都需要多角度思考,是該減少I/O?重用物件?採用非同步?平行處理?運用叢集?考量可擴充性?

面對問題時,從累積的知識中找出最好解決方式,這樣的思考方式,並非朝夕得以形成。

對安全的持續認識與警惕

需求文件中不斷出現「此時應該要……」的字句,在開發程式過程中,我們致力於撰寫出符合功能的程式,然後按照一般使用者會進行的流程進行測試,以確定程式正常運行,然而後續卻發現有使用者特意構造意料外的流程,讓程式在依然遵循原本的設計下,產生了不想要的結果。如同效率,安全也是屬於非功能需求,使用者可以感受到程式運行緩慢,然而安全問題卻不易察覺,直到某天構成傷害為止。

幸運(或者該說不幸)的是,由於過去發生的傷害累積得夠多,留下不少模式與經驗,讓開發者在撰寫程式時,可以避免類似誤用而導致的安全問題,然而就如同無法宣稱程式中沒有臭蟲,即使運用了過去經驗避免了形式上可能的誤用,也無法保證程式中沒有安全問題。

如同效率,對安全議題的認識與預防也是個持續演進的過程,隨著時間遞移,相關的模式與經驗越來越多,而瞭解與落實卻需要時間。

確實,作為一個程式人不一定要有安全知識,這也許是現今多數程式設計教學或教育訓練,多著重在如何運用技術實作功能,只有少數著重在使用或銜接技術時必須留意的安全問題,安全知識有賴於程式人的自發學習。然而,好的程式人應該要持續認識與警惕安全問題,正如同效率需要多角度思考,安全也需要多角度,而且是負面方向的思考。

系統的不同層面,也會有不同的安全議題,將系統各層面的認識及安全議題相結合,隨著時間累積越久,對相關的安全問題也會越有不可取代的敏感度。

培養撰寫可讀性程式的能力
先前Knuth引言中可以看出,易於除錯或維護是程式的重要考量,而易於除錯或維護牽涉到可讀性,實際上,效率、安全與可讀性並不衝突,同樣的演算法,越有經驗的程式人,越能寫出有效率且兼具可讀性的程式碼。

Robert C. Martin在《Clean Code》書中亦提到:「今天你撰寫程式碼的難易度,取決於周遭程式碼閱讀的難易度。」可讀性牽涉到許多層面,從變數、方法與類別的命名,函式職責、物件內聚性與獨立性,仍至於清楚的架構,都是可讀性的探討範圍。

現今程式碼的可讀性不斷地受到重視,寫出正確功能對大多數程式人來說並不困難,然而要寫出可讀性高的程式碼,單是命名就不簡單,如果不能為變數、方法或類別等取個適當名稱,可能表示你不夠瞭解它要的作用與職責,或者是它擔負了過多的工作,你必須知道如何重構它,直到可以為它取個適當名稱為止;除了命名之外,如何撰寫適當註解、編排程式碼、清楚地處理程式錯誤、設計職責適中的函式與類別,都需要時間與經驗的累積。

可惜的是,與安全問題類似,程式碼可讀性雖然不斷受到重視,但程式設計教育上鮮少著重,同樣有賴於程式人的自發學習。

可讀性牽涉層面極廣,這也代表它是個逐步演進的過程,在認識與培養時有對應的順序與基礎,不少人從抽象的設計模式與架構探討,忽略了可讀性為前題,因而對模式或架構產生了錯誤的認知。

撰寫可讀性程式的能力需要時間與經驗的累積,有時基於可讀性考量,也會推翻自己先前的設計,《Clean Code》中寫到童子軍規則「離開營地前,讓營地比使用者更乾淨。」對程式設計來說,似乎這是很嚴格的規則,實際上不少程式人都有類似經驗,在閱讀舊程式碼時,都能看出自己不成熟的過去,因而想讓它更為乾淨。

深化特定領域的專業能力
回到一開始的主題,程式設計是吃青春飯嗎?先前針對效率、安全或可讀性的論述,無非是在強調,不要只是問「我寫程式贏得過年輕人嗎?」單比寫程式,老程式人也許不一定贏得了,如果程式能力中有必須付出同等時間追趕的因子在裏頭,那就是年輕人欠缺的而老程式人具備的優勢,多數人常說經驗中無可取代的,就是這個部份。除了從程式能力面向來累積這種能力之外,另一個面向就是深化特定領域的專業能力。

技術終究只是程式人的工具,工具是用來打造解決問題的產品。許多程式人除了程式相關技術之外,沒有其他領域的能力,更別說具備其他領域專業了。有時只要結合特定領域知識,就算使用簡單技術也能有出色表現。

舉例來說,我曾很快地概覽並教會我太太Excel VBA,讓她撰寫程式,來解決手動計算必須兩小時的基金計價表格,Excel VBA對我來說沒什麼,然而若表格中新增基金,我連改都不敢幫她改,因為我不具備該領域的知識,多數人稱「domain know how」才是最重要的,就是指這類情況的延伸。

特定領域的知識可以是在工作中累積,也可以是結合自身的興趣或能力,無論如何,要讓它隨著時間而成為專業,並與程式設計結合;實際上效率、安全與可讀性,也正是程式設計這特定領域的專業,強大的功能或者是新技術,終究只是一時,能夠累積特定領域專業,程式設計才能像好酒一樣,越陳越香。

作者簡介


Advertisement

更多 iThome相關內容