在軟體開發中,為了不重複、解耦合、易維護等各種彈性需求,程式碼必然地都會有一定程度往抽象化發展,然而,這是一把雙面刃,也容易形成兩個極端:抽象化的極端擁護者,以及抽象化的極端反對者。

複製、貼上,好棒棒!

無論是結構化程式設計、物件導向,或者函數式等典範,無論是狹義的設計模式或廣義的各種模式,只要程式碼是為了追求涵蓋更多的需求,程式碼必然都會朝向一定程度的抽象化發展,一個最簡單的例子排序,若有針對整數排序的sortInt()與字串排序sortStr()兩個函式,其中使用了相同的排序演算法,其程式碼內容必然相近,若因此而定義了一個通用的sort()函式,相對sortInt()、sortStr()來說,sort()函式就是沒那麼具體!

然後,某天程式碼審查(Code review)時,某位主管看到sort()就開飆了:「你寫這個是三小?sortInt()、sortStr()不是用的好好的嗎?」,你辯解著:「可是這樣排序日期或其他物件也可以用sort()啊!」,主管繼續開飆:「你是不會複製、貼上寫個sortDate()嗎?你這樣會害我還要追到sort()才知道它在幹嘛!」

以上是個杜撰的故事,不過可以確信地,身邊一定有人或者是你本身,就遇過類似的情況。遇上極端的複製、貼上擁護者,對他們來說,任何的典範、手法,只要會朝向抽象化,一概反對,理由大概不乏是「書上的東西不能拿來現實中用」、「這樣會影響效能」、「其他人看不懂怎麼辦」、「沒站在使用者的角度想」,或者態度上表現出「老子就是對的」的其他各種理由。

如果搬出可維護性的大旗,提出「複製、貼上程式碼的方式,將來需要修改時,會需要改很多地方」的類似理由,複製、貼上的另一組好夥伴就會上場救援,像是「你是不會搜尋、取代嗎?」

抽象之惡

撇開程式碼審查被拿來當成鬥爭工具的情況,不良的抽象化確實有著不好的名聲。在《約耳趣談軟體》的〈別讓架構太空人嚇到你〉中,一開始就是個鮮明的案例:「他們看到人們要傳送文書處理檔案給別人,又看到人們要傳送試算表給別人,然後就會發現裡面有一個通用的模式:傳送檔案。這已經是一層的抽象。然後他們會再上一層……現在這件事變得愈來愈神秘,再也沒人真的懂他們在說些什麼。」

其實這個案例還算好的,因為至少還是個自下而上的抽象化過程,真正可怕的是自上而下,這就好比公司大頭揭示未來的營運方針「我們要為使用者創造價值」之後,底下各級主管就各自再揣摩,定出各部門層級的抽象方針,如此一層一層地往下無根據地具體化,最後做出一個沒有真實感,甚至損及既有使用者價值的東西。

另一個著名的抽象之惡,就是〈抽象滲漏法則〉了,所有重大的抽象機制,在某種程式上都是有漏洞的,只是抽象滲漏的程度輕重不一而已,自上而下的抽象過程必然有著較大的滲漏,就算執行抽象化的人過去有著豐富的經驗,事先定義的抽象化,終究也是照顧著過去的需求,而不是現在的全部,也因此,任何既有的程式庫或框架一定會有不足之處,最後必然是不斷地加入新功能,終究使得框架臃腫,或者是出現另一個框架,來照顧不滿的另一群人。

就算是自下而上的抽象化過程,基於隱藏複雜度的抽象化,也會引起抽象滲漏。舉例來說,為了隱藏一個物件建立時的複雜度,而採用了工廠方法,就目前來說,這個工廠創建出來的物件是符合需求的,然而,將來終會遇到不合用的場合,就像約耳說的:「總會有一天我們得去追查因抽象滲漏而產生的問題,到時候就得查上兩星期了」,如果這發生在當客戶火燒屁股電話追殺的時候,也難怪會有主管那麼厭惡抽象化了。

重構與分層次地抽象化

毫無根據地抽象,最後會導致架構太空人,最好的方式是基於重構,如此演化出來的抽象化有其根據,如果程式碼有適當地版本控制或文件,也易於追查原始來源。

在《重構》這本書中也會看到,重構不見得一定是抽象化的過程,必要時會朝反方向,無論是為了去除不必要的間接呼叫、委託或者繼承的複雜度等。重構就是基於程式碼的現況,讓程式碼進行抽象化,甚至是解除抽象化,必要時基於需求來解除抽象化,總比一開始就一昧擁抱複製、貼上、搜尋、取代來得好吧!

除了可避免架構太空人之外,基於重構的抽象化,也才有機會建立屬於自己的一套架構邏輯,當必要進一步瞭解抽象化背後的實際機制時,也才容易掌握。例如,在JavaScript界有個虛構的Vanilla JS框架,實際上並不是真的有這麼一個框架,你可以說它是個嘲諷,也可以說它是個鼓勵――鼓勵開發者弄懂抽象原理的來源,以及所隱藏的東西。

至於分層次地抽象化是指,你可以提供一種方式來隱藏複雜度,用以應付大多數的需求,然而,仍保留一定的管道,讓開發者在必要時可以循著它,探索、掌握細節。

舉個例子來說,Python中,每個模組是一個功能概念,各模組往往會提供一些工廠函式(例如open()),協助建構常用的物件或處理常見需求,然而,模組中,也會公開工廠函式實作時,所使用到的相關函式與型態(例如io模組就是如此),它們的抽象層次更往下一層,使用起來更為複雜,然而卻能用來掌握更多的細節,有時,模組中細部的函式與類別,會引用另一更低層次的模組(例如io模組使用了os模組),一旦習慣了這樣的抽象層次規則,在運用時,就能在方便性與複雜度掌握之間,取得一個平衡。

其他人看不懂怎麼辦?

「其他人看不懂怎麼辦」是個偉大的理由,我曾親耳聽到客戶講出來許多次,更別說網路上三不五時看到的開發者靠背或抱怨了。看不懂的原因之一,也許是資料不足,而前面談到,基於重構的抽象化(或解除抽象化),分層次地抽象化,有機會建立屬於自己的一套架構邏輯,這套架構邏輯若有一定的記錄與傳承,應可協助團隊成員必要時快速進入狀況。

當然,記錄傳承與學習需要成本,正如約耳曾經談到的:「抽象機制雖然替我們節省了工作的時間,不過學習的時間是省不掉的」,如果只是為了節省記錄傳承與學習的成本,而摒棄合理的重構或抽象化,必然會在許多需要重複進行修正動作的地方,一點一滴地浪費掉更多的時間。

看不懂的原因之二,也許確實是團隊成員程度不夠,考量團隊整體水平,決定使用某套方法或技術進行開發是必要的,不過,若只是單純地以「其他人看不懂怎麼辦」的理由,通殺各種合理的重構或抽象化,極端擁抱複製、貼上,這感覺就像宣稱:寫程式時根本用不到資料結構、演算法、數學一樣地畫地自限。

而且,也像是在暗示著一個訊息:「我的團隊成員程度就是這麼爛,爛到只能規定他們只能用複製、貼上」,至於為何找來的人程度都這麼差,就讓人有著許多的想像空間了!

作者簡介


Advertisement

更多 iThome相關內容