古語云工欲善其事，必先利其器，對于工程師而言，選擇一款合適而強盛的開發(fā)框架對開發(fā)工作是大有裨益的。那么我們該從什么角度來進行衡量和挑選呢？

首先對于一家創(chuàng)業(yè)公司而言，這更像是一個貿易抉擇而不僅僅是技術選擇，時間人力物力等開銷都必需要考慮周全。一旦公司規(guī)模上來了資金不成題目了，可選擇的空間就更大了甚至可以進行遷移或重新架構。原文作者Ramigbtech總結了以下10點以供參考。譯文如下：

1.  語法

擁有優(yōu)雅語法的語言無疑可以讓編程工作變得舒服，但有時候我們輕易被表象所蒙蔽，假如憑直覺你認定，"this is text".split(’ ‘).reverse.join(‘ ‘)比" ".join("This istext".split(’ ‘)[::-1]) 的寫法要好或差，那么這僅僅是外貌協(xié)會，實際上咱們更應該著眼于它本身是不是具有局限性或語法是不是累贅，用更少的代碼完結等價的工作咱們自個或團隊都會對當初的選擇心存謝謝感動。

2.  功能和體型

我們需要為路由編寫復雜的正則查詢嗎？路由中含有內建的DSL嗎？我們需要使用ORM嗎？或許我們還想擁有更多其它功能。建議選取一款較輕盈框架作為開始，日后我們可認為它添磚加瓦。

3.  文檔資源

具有豐盛文檔資本的結構運用起來的確是稱心如意事半功倍。例如我在學習CodeIgniter時，根本不必像無頭蒼蠅那樣四處尋找謎底，其自帶的教程和配套范例都做得非常當真仔細。相對而言，我在學習ExpressJS的時候就比較費力了。

4.  代碼自動天生

框架中的代碼自動天生功能通常能為我們節(jié)省不少時間，我們僅需要做好控制器/類等的處理而把其它重復的編碼工作交給框架，固然有時候不能自由地進行自定義，但對于想快速開發(fā)出一個能運行的原型是有積極意義的。

5.  模塊化

Django在模塊/Apps的處理上令人驚嘆，不僅僅讓代碼復用變得簡便，同時有助我們培養(yǎng)良好的模塊化思維。當咱們不再需求X模塊時，咱們只需把它移除然后做好代碼重構作業(yè)就可以了。

6.  基礎架構

不論是使用LAMP仍是MEAN堆棧，或是Rails/Unicorn等，最樞紐的仍是我們對這個架構有沒有足夠的了解，有沒有相關組件的維護能力。假如使用的前端和后端都與Javascript有關，選用MEAN倉庫架構是個不錯的挑選。

7.  社區(qū)和更新速度

框架相關的社區(qū)是否活躍？有沒有技術大咖坐鎮(zhèn)？官方會否經常上StackOverflow幫忙解答技術疑難？為這些題目找到完美的謎底是有一定難度，但絕大多數(shù)時候數(shù)字是最真實的。日期或介入度/帖子熱度都是不錯的衡量指標。此外，補丁的更新速度也十分樞紐，對安全性和漏洞的正視與否可謂是牽一發(fā)而動全身。

8.  重大變更

就在最近不少程序員聽到Angular 2.0的重大變更后感到震動和抓狂，盡管要到2015年晚些時候才會全部完成，但一想到辛辛勞苦做好的代碼都會變成過去時，又怎能安之若素呢？另一個例子是Yii框架，新版本2.0的推出意味著對前個版本的完全重寫。

9.  部署和依靠

輕易部署嗎？能利便進行擴展嗎？需要花費多少時間來學習把握部署工具？固然有Docker這樣的工具可以幫我們解答上述題目，但是抽取時間來思索這方面的題目仍是有必要的。

10. 人力

咱們能方便地找到相應的開發(fā)人才嗎？即將運用的框架在咱們所在的區(qū)域是不是流行？縱然訓練作業(yè)是管理的一部門，但對于初創(chuàng)公司而言時間和資金時刻都得精打細算。

寫在最后：

假如是中型的網站，我會選擇Django。假如我暫時不能確定網站的規(guī)模和將投入多少開發(fā)精力，我會選擇Rails。假如我不想前后端工作分得太開，我會選擇MEAN堆棧。