Framework – The right or wrong way

TL;DR 你願意且能夠投入足夠資源的時候,不要用別人維護的 Framework

圖片來源

前段時間出現的 PHP – The Wrong Way 引發 PHP 社群一陣筆戰。坦白說他的論點並不是站不住腳,可惜說理不夠明確,本身想強調的事情沒有受到關注,反而是一些枝節被人口誅筆伐。要針對整個文章評論,篇幅顯然不是一篇文章所能承載的,所以本文挑了其中一個主題來討論:到底要不要用 Framework

Framework 是啥

Framework 是抽象的結果,所以這裡要先來談談抽象

層層疊疊的抽象

站在一個 PHPer 的角度,世界是經過數層抽象的

  • 整個世界
  • 使用 數學 抽象整個世界之後,得到了 物理世界,排除了數學無法描述的世界
  • 使用 布林等數學家創造的數學 抽象物理世界
  • 使用 電子元件 抽象布林數學的世界,得到了 電腦 也是 組合語言的世界 (換句話說,在這個世界裡,所有的問題都能用組合語言搞定)
  • 使用 C 語言 抽象組合語言的世界
  • 使用 PHP 語言 抽象 C 語言的世界

每一次的抽象都能讓特定的問題變得更好處理,但是也讓其他的問題變的難以處理,甚至是無法處理。比如 PHP 的這層抽象讓你可以輕易寫出 web application,但是要用來寫驅動程式的時候就有心無力了。

Framework 不只是一堆程式碼

Tool 和 Framework 都是對 PHP 世界的抽象。比如 libxml 讓你很簡單就能處理 xml 格式,但是要用它來處理 json 格式就搞笑了。

至於 Tool 和 Framework 的差別,我認為是

  • Tool 的目的是快速解決特定問題
  • Framework 的目的是用特定解法解決問題

當然兩者間的分際並不是明確的一條線,多少有些灰色地帶。

舉兩個例子來說好了

libxml

不論你用什麼方式開發,你都可以順利的使用 libxml。不管你是 oop 還是像 C 一樣用 global function 都沒問題;用 MVC 方式還是傳統的每頁一個 php 檔 (還內嵌 html) 也沒關係。它讓你簡單處理 xml 格式資料,但其他的事就不在考慮之列。

Laravel

Laravel 規範了一定的步驟和格式,照著規範走,你會覺得寫起來比較簡單。但如果你想寫成傳統的內嵌 html 樣式,那你就會覺得不如不要用它。

自己的 Framework

從上面的定義,其實可以推導出另外一個結論:你自己寫的 web application 經過一連串的重構之後,也會形成一個自己的 Framework。

你可能會先把一些 copy-paste 的邏輯先抽出來成為共用函式,這時你已經完成一個專門為了解決你的業務邏輯而存在的 Tool 了。

接下來,你發現每一個頁面處理 POST/GET/COOKIE/… 的方式都大同小異。多方考慮之後,你決定用一個 entry file 來把這些資料預先處理一次,並且把每個頁面都寫成 function($get, $post, $cookie, $...) 的形式,讓 entry file 查表呼叫正確的 function。普天同慶!你已經完成了一個 使用特定格式開發、可以快速處理某些業務邏輯 的 Framework 了。

分析優缺點

所以目前為止,我們可以看到三種可能:使用外部的 Framework (如 Symfony/Laravel)、使用自己開發維護的 Framework,或是完全不使用 Framework。

完全不使用 Framework

只透過某些 Tool 處理難以自行解決的問題

  • 優點:減少需要學習的項目、功能簡單的時候可以快速開發、自由選擇任何開發方式
  • 缺點:太多了,下一節列出來的項目,對於不使用 Framework 來說都是缺點

自己維護 vs 外部

項目 自己維護 外部
新進人員學習成本 視文件完整度 因為文件通常完整,所以較低
涵蓋專案所有已知問題 複雜專案通常無法完全涵蓋
處理特殊專業問題 (如資安) 需要有相關人才 視不同 Framework 而定,通常有涵蓋基礎項目 (如 SQL injection)
Framework 維護成本 需要額外人力 零成本
Framework 最佳化 看開發者能力 越泛用的最佳化程度越低
Bug 能否修正 看開發者能力 看維護 Framework 的組織大小及喜好
Bug 修正進度 在團隊掌握之內 看維護 Framework 的組織大小及喜好

結論

簡單來說,自己維護 Framework 的成本高,但是完全適合專案需要,維護能量和權力也在自己手上,適合專案種類單純,願意投注大量資源在穩定性1的團隊;使用外部 Framework 則相反,適合專案種類多元,資源投注在開發的團隊。

特別要提的是,團隊資源充裕,能夠深入研究、理解外部的 Framework,讓維護問題不需要假手外部組織的狀況,選擇外部 Framework 的優勢不會變高。畢竟不是你送了 PR 人家就一定會收,如果自己 fork 一份的話就變成自己維護的 Framework 了;而且外部 Framework 未來的走向也不一定能和專案同步。所以我的建議仍然相同:這種狀況下,在外部 Framework 的基礎之上,開發自己專屬的 Framework 會是較合理的選擇。


  1. 穩定性不只是指程式不會當掉,也包括了確認錯誤能不能修好。無法掌控錯誤排除流程,代表無法確認錯誤是否可以修復,所以是不穩定的。 

Written by 

熱愛思辨,喜歡透過自我問答來找到可能的答案

Related posts

發表迴響