这些代码很恶心，尽管有些程序员特别好这一口，但怎么说，这种代码自然是越少越好。真正能产生商业价值的是那些处理业务逻辑的代码。当然，很明显你也不可
能只写业务代码对吧。还有一类代码是用来运行这些业务代码的，当然了，基础架构和业务的代码的边界并不是那么清晰。你很难跟别人说这些是业务代码，那些是
基础设施的代码。
　　你能做的就是选择一个适合业务场景的框架。那些比较容易配置，不需要大量模板代码，容易学习的框架。这样的话你可以更聚焦于业务代码。当然了，知易
行难。现在项目还有这么多的不确定性，你怎么才知道长期来看哪个框架最好？这个很难确定。不过你可以试一下，争取能更准确一些。有一个能遵循的选型的模型
就最好了。那么在这里，这个模型应该是什么样的？
　　在一个项目的生命周期里，肯定是需要花费一些精力来开发业务逻辑的。如果业务逻辑是确定的，那么需要开发的代码量肯定不会变化太大。由于有些编程语
言写起来可能比较啰嗦，代码量上面可能会略有不同。同时还有学习框架的成本，不过这个对于一个长期的项目而言可以忽略了。你只需要在项目的开始阶段费点工
夫，比如中sprint中的1，2阶段，在那以后这个成本和整个的开发量相比就无足轻重了。对于我自己建立的这个模型而言，我会忽略掉这块的工作，一个原
因也是因为我没办法提前预估平均每个程序员大概需要多少时间来学习某个框架。
　　那么最终简化版的模型就是比较开发商业价值的代码以及配置和支持所选框架的代码之间的比例。怎么去衡量这个？
　　我通常是。。好吧，其实也算不上经常。选择框架也不是每天都干的事。我们团队上一次做这个选择的时候是这样的：
　　我们先选取了5个可选的框架。第一轮我们先剔除掉了一个并不是太有名用的也不是很多的框架。我们也不想赶这个时髦。另一个被淘汰掉是因为最近的一次
调查表明这个框架完全不适合我们。那么还剩三个。最后我们在GitHub中去搜索那些使用到了其中某个框架的项目，每个框架至少挑两个。我们一共看了8个
项目，去统计它们的业务代码和框架代码之间的比例。紧接着我们意识到，在有限的生命中这个是完成不了的，因此我们将它简化了下。我们开始按类的名字对它们
进行分类。有一些业务类的名字是和业务数据相关的，有些是以某些业务功能来命名的。剩下的那些都认为是框架支持、配置的类。
　　最终的成果写到了之前的一个PPT中，我们加了两页幻灯片来分析这三个框架的优点及缺点。毫无疑问，最终的结果高度一致：计算表明，框架需要的配置和支持代码越少，大家就越喜欢。
　　那么这个选型的附加价值是什么？
　　做这个测试我们必须去审查项目，同时我们也学到了很多关于这些框架的知识。虽然和正常写代码没法比，但总比盯着那些宣传资料要强。我们接触了开发人
员在面临实际的问题以及实际的框架特性时所写出的实际代码。这有助于评估员了解到更多的知识，让他能快速提高，以便让我们知道什么是该注意的，什么是该去
尝试的。
　　还有一个尤其重要的结果就是，我们对这个决策的结果没有太多疑问。如果结果是相反的，那么麻烦就大了，这会让我们很困惑：为什么大家会选择一个需要更多与业务无关代码的框架。不过所幸没有。结果跟我们的直觉一致。
　　那么我是不是推荐使用这种方式来进行框架选型呢？当然不是。不过它可以作为
一个很好的补充，这只会花掉你的SCRUM团队的两到三天的时间而已，而且这还能让你的团队接触一下新的技术。