[bashing]選擇 framework

剛剛想寫 twitter 的時候才發現 twitter 又掛了。Twitter 服務不穩屢見不鮮,而且近日有漸漸頻密的現象。特別是重要時刻,好像 SJ 登台「演出」,Twitter 甚至會連主頁都連不上。

很難不將這事實跟 RoR 扯上關係,因為 RoR 的「性格」也是臭名遠播的。就連 Mongrel 的爸爸 Zed Shaw 也這樣說(但這傢伙也自大得太厲害了吧?)。自己本身沒體驗過 RoR,固然沒資格插嘴說三道四。不過有好幾點也是很值得留意的。

其一是效能。那是不少高流量網站的痛處。我好像以前說過只要硬件搭救就沒關係,不過我不曾想到語言和框架會有穩定性的問題。所以在留意功能之際不不忘留意一下在這方面以外有沒有一些為人詬病的問題,例如效能,穩定性,部署的複雜程度等等。

第二點是功能。不要見開發速度很快,十分鐘就能寫一個 blog/forum 便爭著當 fans。有時候如果沒有想要的功能,開發到一半才知道原來框架不支援,是多麼麻煩的事。不知道現在 RoR 還支不支援 composite key 呢?(笑

上面提到的 Zed Shaw 特別提到那群 RoR 的用戶很多是從 PHP 跳槽過來,讓用戶群強大之餘,卻也帶著 PHP 開發的「惡習」到 RoR,像是沒 OO 概念之類的。我想說的是學習一套 framework 還要看看自己開發符不符合 framework 的 ideology,看自己跟框架合不合得來。就像挑伴侶一樣,framework 是開發工作的另一半,為時間緊迫的專案挑框架也得相對小心,免得一失足成千古恨。

以前上課導師說過,”The purpose of a framework is to solve common problems”,這次我說的就是在那句後面補上 ” not create”。

框架與開發

1. 有時候不要依框架工作。如果面對框架不能完成或難以完成的工作,不妨試一點比較「穢」的方法。框架是輔助你的工具,不是限制開發的牢獄。

2. 同上,避免用上一些把低階收起,只開放高階介面的框架。拿 Hibernate 為例,即使它是一套 O/R Mapping 的工具,你仍可選擇以 SQL 拿取資料。

3. 要衡量使用框架後所增加的工作量。我的準則是計算框架設定與商業邏輯(Business Logic) 的比重:如果設定比想好商業邏輯更辛苦的話,還是不要用框架為妙。

4. 有時候不要被框架琳瑯滿目的功能所矇蔽。要先釐定出你所需要的功能,再以學習難度,設定複雜程度等等因素挑選合適的框架。

5. 嫌框架還是太繁複的時候,可以考慮在框架上另編寫自己的框架簡化重覆的步驟。

6. 不用太在意自己是否符合 Best Practices;除非有碰釘,程式碼過於複雜等等問題。If it ain’t break, don’t fix it.

7. 不少框架也鼓勵模組化(Modularized)和重用 (Reuse),但有時候應不應該把自己的程式碼拆散成散亂的碎塊。要肯定自己可以隨時會用到自己建立的模組,那便可以避免出現雞肋問題。

8. 使用模組時,如果時間許可才採用模組陌生的功能。時間不足寧可選擇較麻煩的方法。

9. 不要用說明不詳盡的框架。

10. 簡單的東西,例如方便自己的小工具的編寫,cron job 等等東西,除非有其他原因,最好不要碰框架。