我们如何选择框架

大多数时候，在开发应用程序时，您正在编写处理某些资源的代码。 打开数据库连接，分配内存等的代码行。 编码的级别越低，处理环境所处理的代码就越多。 这很麻烦，尽管对于某些程序员来说可能是令人愉快的，但所需的这种代码越少越好。 当您编写实现业务功能的代码行时，提供业务价值的真正努力。 显然，您无法做出仅编写业务功能实现代码的简单决定。 执行代码还需要其他类型的代码行，并且的确，基础结构代码和业务代码之间的边界有时是模糊的。 您只是无法在某个时间告诉您键入的代码是基础设施还是企业。

您真正可以做的是选择最适合业务问题的框架。 易于配置，不需要模板代码且易于学习的东西。 这样，您可以将更多精力放在业务代码上。 好吧，说起来容易，很难做。 当项目存在很多不确定性时，从长远来看，您如何判断哪个框架是最佳的？ 您无法准确分辨。 但是您可以尝试提高精度。 遵循模型并不会造成伤害。 那么在这种情况下是什么模型？

在项目的生命周期中，将不断努力开发业务逻辑。 如果业务逻辑是固定的，则要开发的代码行数不会有太大变化。 可能会有一些差异，因为某种编程语言比另一种更为冗长，但这并不重要。 主要区别在于框架支持代码。 还需要努力学习该框架，但是对于更长的项目来说可以忽略不计。 在项目开始时需要进行此工作，例如sprint 1和sprint 2，此后与开发总成本相比，此固定成本将减少。 对于我设置的模型，我至少会忽略这一工作，因为我无法先验地衡量普通程序员学习特定框架所需的工作量。

因此，最终的非常简化的模型是将交付业务价值的代码量与配置和支持所选框架的代码量进行比较。 如何衡量呢？

我通常……嗯，不是通常。 选择框架不是日常工作。 我们上次在团队中进行选择的内容如下：

我们预先选择了五个可能的框架。 我们排除了其中一个，因为它并未广为人知和使用。 我们不想站在最前沿。 另一个过滤掉了，因为仔细检查表明该框架完全不适合我们的目的。 剩下三个。 之后，我们在GitHub上查找了使用其中一个框架的项目，每个框架至少有两个（不超过三个）。 我们查看了总共8个项目，并计算了将其分类为业务和框架代码行的行。 然后我们意识到这在人类一生中是做不到的，因此我们使其变得更简单。 我们开始根据类别的名称对类别进行分类。 有与某些业务数据相关的业务类，还有以某些业务功能命名的类。 其余部分视为框架支持的配置类。

最终结果是将其雕刻成一个很好的旧ppt演示文稿，我们将这两个幻灯片添加到其他幻灯片中，从而定性地分析了列出优点和缺点的三个框架。 毫不奇怪，最终结果是一致的：计算表明，无论如何，我们需要的框架需要更少的配置和支持的代码。

那么，增加值是多少？

进行度量时，我们必须审查项目，并且我们学到了很多有关框架的知识。 编码不多，而不仅仅是盯着营销材料。 我们接触了程序员在面对框架的实际问题和真实特征时创建的真实代码。 这也有助于评估人员获得更多知识，提供帮助并引导我们在哪里看，在尝试该框架时应尝试的方法。

决策过程对我们的影响也很小，这也是极其重要的结果。 如果结果恰好相反，那我们将陷入困境，这将使我们苦思冥想：为什么我们偏爱需要更多与业务无关代码的框架。 但事实并非如此。 结果很简单，具有常识。

我是否建议将此计算作为框架选择的唯一来源？ 绝对没有 但是，可以将Scrum团队烧掉两到三天，这可能是一个很好的补充，它还可以帮助您的团队将他们的指尖投入新技术中。

翻译自: https://www.javacodegeeks.com/2014/07/how-we-chose-framework.html