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