當你在開發應用的時候，大多數時候你都在寫一些處理資源的代碼。那些打開
數據庫連接，分配內存之類的代碼。更底層的就是和計算環境打交道的代碼了。這些代碼很惡心，盡管有些程序員特別好這一口，但怎么說，這種代碼自然是越少越好。真正能產生商業價值的是那些處理業務邏輯的代碼。當然，很明顯你也不可能只寫業務代碼對吧。還有一類代碼是用來運行這些業務代碼的，當然了，基礎架構和業務的代碼的邊界并不是那么清晰。你很難跟別人說這些是業務代碼，那些是基礎設施的代碼。
你能做的就是選擇一個適合業務場景的框架。那些比較容易配置，不需要大量模板代碼，容易
學習的框架。這樣的話你可以更聚焦于業務代碼。當然了，知易行難。現在項目還有這么多的不確定性，你怎么才知道長期來看哪個框架最好？這個很難確定。不過你可以試一下，爭取能更準確一些。有一個能遵循的選型的模型就最好了。那么在這里，這個模型應該是什么樣的？
在一個項目的生命周期里，肯定是需要花費一些精力來開發業務邏輯的。如果業務邏輯是確定的，那么需要開發的代碼量肯定不會變化太大。由于有些編程語言寫起來可能比較啰嗦，代碼量上面可能會略有不同。同時還有學習框架的成本，不過這個對于一個長期的項目而言可以忽略了。你只需要在項目的開始階段費點工夫，比如中sprint中的1，2階段，在那以后這個成本和整個的開發量相比就無足輕重了。對于我自己建立的這個模型而言，我會忽略掉這塊的
工作，一個原因也是因為我沒辦法提前預估平均每個程序員大概需要多少時間來學習某個框架。
那么最終簡化版的模型就是比較開發商業價值的代碼以及配置和支持所選框架的代碼之間的比例。怎么去衡量這個？
我通常是。。好吧，其實也算不上經常。選擇框架也不是每天都干的事。我們團隊上一次做這個選擇的時候是這樣的：
我們先選取了5個可選的框架。第一輪我們先剔除掉了一個并不是太有名用的也不是很多的框架。我們也不想趕這個時髦。另一個被淘汰掉是因為最近的一次調查表明這個框架完全不適合我們。那么還剩三個。最后我們在GitHub中去搜索那些使用到了其中某個框架的項目，每個框架至少挑兩個。我們一共看了8個項目，去統計它們的業務代碼和框架代碼之間的比例。緊接著我們意識到，在有限的生命中這個是完成不了的，因此我們將它簡化了下。我們開始按類的名字對它們進行分類。有一些業務類的名字是和業務數據相關的，有些是以某些業務功能來命名的。剩下的那些都認為是框架支持、配置的類。
最終的成果寫到了之前的一個PPT中，我們加了兩頁幻燈片來分析這三個框架的優點及缺點。毫無疑問，最終的結果高度一致：計算表明，框架需要的配置和支持代碼越少，大家就越喜歡。
那么這個選型的附加價值是什么？
做這個
測試我們必須去審查項目，同時我們也學到了很多關于這些框架的知識。雖然和正常寫代碼沒法比，但總比盯著那些宣傳資料要強。我們接觸了開發人員在面臨實際的問題以及實際的框架特性時所寫出的實際代碼。這有助于評估員了解到更多的知識，讓他能快速提高，以便讓我們知道什么是該注意的，什么是該去嘗試的。
還有一個尤其重要的結果就是，我們對這個決策的結果沒有太多疑問。如果結果是相反的，那么麻煩就大了，這會讓我們很困惑：為什么大家會選擇一個需要更多與業務無關代碼的框架。不過所幸沒有。結果跟我們的直覺一致。
那么我是不是推薦使用這種方式來進行框架選型呢？當然不是。不過它可以作為 一個很好的補充，這只會花掉你的SCRUM團隊的兩到三天的時間而已，而且這還能讓你的團隊接觸一下新的技術。