框架(Framework)的出發點,在於解決軟體開發過程中重複出現的流程設計,每個框架實作背後必然支持某個架構與流程,這是框架要解決的本質性(Essence)問題,然而框架作為一種工具,本身必然會帶入某些附屬性(Accidents)問題,使用框架必先辨識框架要解決的流程本質,並對即將被導入框架的系統有通盤瞭解,方可評估採用後的價值,是否超越隨著框架附屬而來的繁複設定。

框架解決問題間的概念交集
《人月神話》作者Frederick P. Brooks在1986年,發表了論文《沒有銀彈:軟體工程的本質性與附屬性》,原文中Accidents並非現代用語中意外或突發之意,而是古希臘哲學家亞里斯多德的用語。在Brooks近作《設計的設計》中,則針對本質與附屬加以解釋:「若採用現代用語,必要的(essential)和次要的(incidental)應較容易理解」。

Brooks書中亦談到:「軟體建構中本質的部份,指的是概念的智能創作,而附屬的部份,指的是實作程序。」在開發軟體的過程中,有時會發現解決軟體中某些問題時,創造出的方法概念具有某種程度的相似性或交集,若對類似概念重複進行實作,重複耗費的附屬性成本著實是種浪費,因而在實作類似概念時考量了彈性與通用性,使得後續軟體開發中出現類似的智能創作時,可以直接套用先前既有成品,避免一再重複的實作程序,而這個既有的成品就是框架。

倘若將軟體開發中概念的智能創作以圓形表示,若重疊在交集部份的圓越多,抽取該概念的實作程序,並通用化為框架的價值就越高,而交集部份的概念智能創作,就是框架中本質的部份;在通用化的過程中,須考慮交集部份的概念間依舊存在的差異性,因此要能在套用框架時,根據差異性,個別進行組態,而使用框架時也需遵守所提供程式庫的組裝規則,這類框架使用時必須依循的組態方式與程式庫規範,就是隨著框架而來的附屬性問題。

建立微型框架理解框架本質

對於實際軟體開發中出現的重複流程,嘗試將其一般化並建立微型框架,有益於瞭解軟體本身,亦有助於選擇適用的成熟框架。

舉例而言,若開發軟體過程中有測試的需求,而你必須撰寫測試執行器(Test runner),負責執行測試工程師撰寫的測試案例(Test case)。為了能讓測試工程師獨立作業,你嘗試使用命令(Command)模式,定義並要求測試工程師實作測試介面;為了能讓測試工程師自由組合測試案例,你嘗試使用組合(Composite)模式重新改寫測試執行器,定義並要求測試工程師使用測試套件(Suite);為了能夠收集與呈現技術無關的測試結果,以便之後能以各種方式顯示測試結果,你採用了收集參數(Collecting Parameter)模式。

此外,當你進入下一個軟體開發,同樣必須執行測試時,你想到前後兩個軟體的測試概念是類似的,於是將先前為測試而撰寫的實作進行通用化,帶入下個軟體開發之中,這通用化的實作部份,就是測試框架的微型版本。

或許隨著一個又一個的軟體開發,你的測試框架越來越通用,因而想到對外公開釋出,以讓有類似測試需求的軟體可以直接套用;又或許是在自行開發微型測試框架的時候,發現到JUnit測試框架的概念流程與你的微型框架類似,但功能更成熟,因而決定直接將JUnit導入軟體開發之中,由於先前自行開發微型框架的經驗,讓你在使用成熟測試框架時,能立即掌握核心流程。

類似地,在開發的軟體中有產生報表的需求,格式可能是HTML、PDF或JSON。為了隱藏報表產生器的實作細節,你可能採用工廠(Factory)模式,在傳回報表服務物件的方法中,進行報表產生器、報表服務物件的實例化,以及建立兩者之間的依賴關係,為了更有彈性地設定採用何種報表產生器,於是採用XML設定檔。當你進入下一個軟體開發,發現同樣有物件生成與建立依賴關係的需求,於是將先前撰寫的工廠類別予以通用化,帶入下一個軟體之中;隨著一個又一個的軟體開發,你的微型框架,不再只是針對特定物件生成,或特定依賴關係建立。

有天你發現到,Spring的依賴注入(Dependency Injection)容器(Container)更為成熟,而且整個Spring框架以其為核心整合諸多主流開放原始碼框架,這對你是個極大便利,先前花費時間自行建立微型框架的過程也不是個浪費,因為你的想法概念與Spring框架契合,導入Spring框架,會讓你更得心應手。

避免框架附屬困難模糊應用焦點
同樣的方法概念,有可能會有不同的實作,在抽取交集部份實作程序並予以通用時也會有不同成品,也因此同樣的方法概念,可能會有不同的框架實作可供選擇,當同樣方法概念有過多的框架實作可以選擇時,各種框架附屬而來的困難度就會讓開發者疲於奔命,而對想進入該領域的開發者,驟然面對的,就是諸多框架加乘在一起而產生的陡峭學習曲線,此時最重要的就是具備辨識框架本質的能力,並避免將重點放在附屬而來的困難。

舉例來說,實現MVC/Model 2概念的框架繁多,有些會將Model 2的概念予以細化,削減不必要的通用性,使其適用於特定領域,而通用性被削減,代表了設定組態與相關程式庫的簡化,也就是降低了使用該框架時的附屬性困難,然而此類框架的本質是方才提到的「適用特定領域」,開發者理解或使用此類框架,重點應放在該框架所謂特定領域為何,而不是放在組態與相關程式庫簡化後,應如何設定。

另一個例子是,近來許多Model 2框架在呈現(View)上結合Ajax元件,使用此類框架時,除了瞭解其如何支援Model 2流程之外,更要瞭解提供的Ajax元件與Model 2流程的互動模式為何,才有助於同時解決前端的呈現問題。

有些框架一開始會有組態不便或設定複雜的問題,然而,這些附屬的困難度,可隨著輔助工具的推出、框架的改版、新的組態媒介,而降低甚至消失。

過於將學習或使用重點放在框架的附屬性困難上,會對理解框架本質造成阻礙,只是學會那些將來可能不再適用的API組裝並不值得炫耀,也不應自認為懂得如何完成複雜組態設定而洋洋自得,畢竟那並非框架存在的真正意義。

而當前徵才需求上列出求職者必須熟悉某些框架,並非僅要求應徵者能在系統中設定與組裝框架,而是在尋求不被框架附屬性困難絆住、瞭解框架本質,並可應用在系統中真正解決問題的人才。

將通用框架特化為領域框架

除了掌握要採用框架的核心流程之外,對即將被導入框架的原系統也要有通盤瞭解,如此才能瞭解框架核心與被導入框架的系統在流程上是否符合,也才能挑選合適的框架元件,而不是試圖採用所有的功能。

通常一個框架越通用,或者是隨著版本更進而功能越趨龐多時,就會有許多系統中根本用不上的附屬功能,因此試圖學習框架全部的功能,往往是不可能,也是不必要的舉動。

也唯有在同時瞭解框架本質以及被導入框架的系統流程,在面對框架核心流程與系統流程略有不符時,才有能力對框架作出擴充調整,像是整合其他框架或程式庫,或者在必要時將框架某些API予以封裝,成為適用該領域的API,甚至在數個類似的框架調整過程之後,從原有的通用框架沿生出適用特定領域的框架。

 

作者簡介


Advertisement

更多 iThome相關內容