框架選擇的7個原則

Liszt發表於2012-01-23

原文連結: 7 Tenets Of Framework Selection

特別說明:感謝大家積極參與【iTran樂譯】第3期

當你開發應用程式時,你需要選擇整合各種各樣的工具,庫和框架到你的應用程式中。在某些情況下,選擇最流行和廣受好評的工具是一項非常簡單的人物。然而,情況不是總是這樣。在大多數時候,總有多款工具適合你的基本需求,並且它們都有各自的長處。那麼問題就變成“你如何在多種選項之間做出選擇?”。我已經討論過這個主題了,但是這是很早以前的事,現在有了一些不同的側重。所以,今天我將給大家分享這些嶄新的和改善過的7個框架選擇原則。

什麼是必須的特性?

在你開始任何選擇流程之前,你需要一些評價的標準。假設我們忽略借個因素,你仍然需要決定這個框架是否適合你的使用。你需要什麼特性來彌補整合框架帶來的開銷?這應該是一張最小去求的列表,反之你總是會選擇一個“大雜燴”框架而不關它是否最合適。例如,考慮一下一個XML解析庫。它應該可以建立一個DOM然後返回一個組織良好的錯誤列表。如果你使用DTD,你需要這個庫具有DTD驗證功能。然而,這並不意味著一個解析器需要去支援XSD,因為你並不真正需要這個特性。

引進的這個框架是不是會於其他工具,框架或者庫有不相容?

一個框架可能看起來很酷,但是它是否與其他你正在使用的庫產生不相容呢?這種衝突在JS的世界裡經常發生,當我們在處理各種JS外掛時。例如,你可能會使用Prototype作為你的JS框架,但是當你尋找內嵌的HTML編輯器時,你需要檢查她們是否於你現有的Prototype版本相容。我在上一份工作時,調查了這個例子,有一個編輯器唄淘汰了就因為它在我們使用的Prototype版本下產生了問題。謝天謝地,不相容行一般會記在文件上而且有時一些新版本或者有針對性的版本會糾正這個問題。

它的擴充套件性和可定製性怎樣?

對於任何解決實際問題的框架來說,你將或多或少的需要定製或者擴充套件它。在Java中,可能可以通過利用介面來完成。如果我們回頭看XML解析器的問題,我可以通過實現特殊的介面並提供給解析器,以此來建立一個自定義的錯誤處理其。這種型別的定義是非常直接的,在大多數框架中也是可行的。另一種擴充套件是使用外掛。雖然不同應用程式定義外掛的方式不同,但是一般來說總是將程式碼“丟”到一個預先定義的方法。例如,一些內嵌的HMTL編輯器允許你把JS程式碼放到一個特定的目錄。這段程式碼必須符合某些規範,就像實現Java藉口一樣。外掛是一個有趣的模型,因為它們讓你建立原始框架所不具備的特性。這種方式是非常強大的,也是非常令人渴望的。

它有多成熟?

在CodingHorror有一個有趣的帖子,它解釋“流行/瘋狂”原則。鋪天蓋地向你介紹新技術的廣告,你需要應用“流行/瘋狂”原則來衡量,某些東西是否真的適合使用。基於java的web框架和NoSQL產品是一個很好的例子。web框架出來年頭了而且非常穩定。NoSQL是一個最近非常火熱的產品領域。有許多的工具正在被構建,所有這些產品都不同的假設和期望。對於任何的工具總有一些穩定性和一致性的考慮,因為你可能不會使用這些工具所針對的目標。這也是“流行/瘋狂”原則應用的地方:如果一個應用程式表現得太瘋狂,那麼它不在乎它有多火熱。

你是否可以快速地開發一些原型來決定它的易用性?

大概兩個月前,我寫過關於實驗新技術的文章。如果你不能實驗一個技術,那麼當你想使用它們時,你將會付出巨大的努力來學習它們。關於實驗新技術,你可以做的一件事情是開發一個原型來解決一個簡單問題,有時候這可以在一天內完成。快速原型的目的是檢驗這些工具是否易用,所以你需要為快速原型設定一個時間限制,通過給所有工具同樣的時間,你可以從中得到不同工具之間的易用性和生產性的比較。快速原型同樣可以檢驗這種風格的工作是否適合你的開發環境。縱使是最好的工具,如通過它需要使用一門你專案組裡都不懂的指令碼語言,這也會顯著地提高使用這個工具的成本。

我可以在哪裡獲取幫助?

成熟的框架總是比它的新競爭者有更多的幫助資源。社群論壇,郵件列表,部落格,甚至像StackOverflow這樣的站點都提供了豐富的幫助資訊。你調查的框架是否有活動的社群,郵件列表,StackOverflow的權威回覆,能夠回答關於框架的大量問題?在你學習一個新工具的過程中,尋找幫助和樣例程式碼總是幾位重要的。看部落格也非常有幫助,因為它告訴你誰在談論這個框架。如果只有少量不致命部落格在談論這個框架,那麼這個框可能太新了而沒有得到廣泛接受。

有用的加分項?

加分項(那些你用不到但是整合在框架中的功能)總是非常有趣但是又不能作為你選擇這個工具的主要理由。雖然可能有其他讓你選擇這個框架的理由,但是如果選擇兩個框架的理由差不多,那麼加分項就可以打破這個平局。回頭看XML解析器的例子,假設你只需要DTD解析和驗證。如果兩個框架都有你需要的特性,你可能會選擇一個具有XSD驗證的框架。這樣做是有意義的,尤其當你可能想在未來應用這些特性時。然而,也不要被大量“廣泛”的特性所迷惑,從而選擇一個過於複雜的框架。

有趣的是,這些原則同樣適用於你構建自己的產品和框架。牢記這些目標會幫助你的產品獲得更廣泛的採用。

相關文章