robot
最新文章(10)
MadButterfly 和 Javascript 合體的威力
Adapt C code for Javascript
OpenVG for Linux/FreeBSD with X
回收 Linux cached memory
公告: 更換 domain name
關於 GCC nested function
GLUT 作為 Embedded System 的 UI 平台
別被 kernel 嚇到了
SVG 加 Gecko 完全攻略
在 OSDC 展示的 Plurk client
首頁
新編
最新留言
Entries RSS
重要關鍵字(10)
coding (120)
Python (93)
FreeBSD (71)
WEB (61)
URL (48)
hardware (46)
雜記 (45)
javascript (36)
Linux (31)
blog (30)
所有關鍵字
新增 URL
Framework - no evil
by thinker
2 Columns
關鍵字:
雜記
在 Eddy 的 linkname:[Ruby on Rails觀察(負面$想法$,非喜勿視)] http://eddychang.blogspot.com/2006/11/ruby-on-rails.html 這篇文章裡,提出對 framework 的質疑。這個質疑不只是針對 RoR ,對 J2EE 等等的 framework 也一樣適用。```那ROR呢?重學一套新程式語言和框架?另一個學習的曲線浮現了,又有新的玩意要學,等你花了不少的時間學到靈活運用之後,而接下來又是下一個問題。''' 這句話對 J2EE 平台而言,更是確實。換成 .Net 或另何其它的 framework ,也幾乎都是確實。 Framework 到底出了什麼問題呢?首先,得問 framework 的目的是什麼。Wikipedia 對 framework 有這麼一段說法 ```Frameworks are designed with the intent of facilitating software development, by allowing designers and programmers to spend more time on meeting software requirements rather than dealing with the more tedious low level details of providing a working system.''' 簡單說,就是要避免 programmer 接觸一些繁雜的低階技術,多花點時間在任務上面。 放眼所及的 framework ,似乎都達到包裝低階技術的目的,但為什麼還有那麼多抱怨呢?問題出于```by allowing designers and programmers to spend more time on meeting software requirements''' 這才是真正的目的。我們的 framework 無法讓 programmer 更心在解決專案的需求,反而要分心處理 framework 的巧妙設計。就如同 Eddy 所說的,學習一套 framework ,有如在學習一套語言。 Framework 為了提供多方位的服務,系統設計環環相扣在一起。對 programmer 而言,必需一一搞懂這些峰峰相連的元件。再加上有些 framework ,以高度 OO 自豪,弄出了一層又一層的繼承關係和一堆的 interface ,讓形勢更加困難。 有些人也許認為,搞懂這些 framework 是 programmer 的責任。也有些人,將 framework 當成玩具把玩。然而,當 framework 出現地雷時,又有誰能解決這些問題呢?尤其是專案時程吃緊的時侯。就算對某 framework 非常的熟悉,也無法隨時關照到 framework 的每個層面,偶爾就會引爆一兩個地雷。或許這不是 framework 的錯,是自己的失誤。但,認清事實吧! 在同一時間裡,人腦無法精確的處理這麼大量的技術需求。過去,我們對於 framework 抱有太大的夢想,以致於忘了本身的不完美。 說了這麼多,並不是告訴大家,我們不要 framework 。我們還是需要 framework ,但 framework 的設計,必需是服務 programmer ,而非考驗。我們要輕巧的 framework 。(又來了) == 理想的 Framework == 所謂輕巧的 framework 並不是 framework 功能簡單,而是 framework 易於了解、易於修改。 Framework 必需是 design for modify ,所以不該連環扣,可以拆開來修改,甚至是使用。 Framework 必需是總集 programmer 常用的指令序列,減少 $coding$ 的量,但不是包裝出另一個 VM ,讓 programmer 去學習。programmer 也可以選擇,而非被迫使用。常見的 framework ,總是想要弄出另一個 VM ,但這個 VM 總是更複雜。比擬成 CISC 相對 RISC ,還要更複雜。 Framework 應該告訴我們,常見的問題該如何解決,而非告訴我們「請用這套 framework 解決」。 Framework 應該提供工具,幫助我們 implement 某種 pattern ,以解決特定形態的問題,而非直接 implement 某種 pattern ,要我們硬套進去。(這樣的套子,往往不是太小就是太大,您用的安心嗎?) Framework 必需提供減少程式碼的方法,而非只是試圖幫我們寫程式碼。只試圖幫我們寫程式碼的 framework ,往往是提供一堆不很合用的 interface 。 Porgrammer 必需在這上面疊床架屋,繞一大圈才能完成功能,還不如省略 framework,直接 $coding$ 還來的快。減少程式碼的方法,可以是簡單 pattern 的 example code,讓 programmer 可以直接修改成合用的形式。或是告訴我們,如何避免重複的程式碼,並提供工具。(DRY) == 結語 == 好的 framework ,是指引我們更快的完成工作,而非命令我們如何完成工作。重量級的 framework ,都像盯著小學生完成作業的父母一樣,只會加重我們的負擔。
最後更新時間: 2007-02-07 10:53:50 CST |
引用
查詢:
COMMENTS: