当前位置：首页 > 文章列表 > 文章 > java教程 > 千元一行错误 - SBT + PlayFramework

千元一行错误 - SBT + PlayFramework

来源：dev.to 2024-07-09 17:48:59 0浏览收藏

对于一个文章开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《千元一行错误 - SBT + PlayFramework》，主要介绍了，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

现在每个人都在谈论拥有良好的开发者体验是多么重要，因为它会带来很多好的副作用，例如但不限于：

开发速度/生产力
代码质量/维护
节省成本等等

然而，我们经常让自己从事的项目在过去的某个时间添加了一小段代码来使项目更快，甚至修复某些东西，也许有人试图使构建更快，甚至尝试给工程师更好的开发体验。这个故事就是这种情况。

几年前，在我们从事的一个项目中（在我加入公司之前），发现了构建 SBT、Scala 和 play 框架的问题，在本地构建项目的编译时间约为 3至 5 分钟，具体取决于机器。已尝试解决该问题。项目结构分为 2 部分，如下所示：
之前

项目A
  /api
 /核
 /应用程序

之后

项目A
 /核
 /应用程序

项目API
  /api

以下内容已添加到 build.sbt 中

lazy val projectA =（文件中的项目（“.”））
  .enablePlugins(...)
  .settings(通用设置)
  .aggregate(api)
  .dependsOn(api)

惰性 val api = project.settings(commonSettings)

这样做确实提高了编译时间，只是在 CI 管道的构建过程中，我不确定它在开发阶段是否有帮助，但是，它增加了一个新的可怕的错误，让开发人员浪费了数千个小时工作的.

添加此行后，开发人员开始注意到仅运行一个简单的代码就需要多长时间
sbt 在本地运行，对于现在代码库中的每一个更改，都需要完整的编译。

理解问题的旅程

根据 SBT 参考手册 - 多项目中记录

重要的是要注意聚合和依赖的两个定义

聚合意味着在聚合项目上运行任务也会在聚合项目上运行

一个项目可能依赖于另一个项目中的代码。这是通过添加 dependentOn 方法调用来完成的。例如，如果核心在其类路径上需要 util。

花了一两天的时间阅读文档并多次尝试解决该问题，但最终我到达了这个 Github - Spurious recompilation in multi-project build 这并不是修复本身，但是，在最后给了我光明通过隧道了解问题确实与多项目设置有关。

更进一步，我明白发生了什么，现在我的 build.sbt 文件就这么简单：

lazy val projectA =（文件中的项目（“.”））
  .enablePlugins(...)
  .settings(通用设置)
  .dependsOn(api)

惰性 val api =（文件中的项目（“api”））
  .settings(通用设置)

我们在SBT中设置projectA的方式出现了问题。我们告诉 SBT 包含项目的 API（这是正确的），但 API 定义指向整个项目根。这意味着：

每当API需要编译时，SBT也会尝试编译projectA本身。
由于projectA需要API来编译，因此会触发另一个API编译。
这造成了无限循环，迫使开发人员终止 SBT，并为每次代码更改手动清理和编译所有内容。
简而言之，这是发生的事情：

我们告诉 SBT 包含该项目的 API。
API定义指向整个项目。
编译 API 触发了完整的项目编译（再次包括 API）。
这个循环使得 SBT 非常慢并且让开发者感到沮丧。

团队已经为这个问题工作了至少 4 年......

后果 - 解决问题

当我对我的队友说我已经在 master 上合并了一个令人惊讶的功能后，人们不明白发生了什么，但是，我想看到他们脸上的幸福，我告诉整个团队将 master 拉到任何分支他们正在研究，其中一些人在第一次尝试时没有注意到任何事情，其他人开始注意到在更改代码库中的任何代码后，它在几秒钟内仅编译受影响的文件，而不是像以前那样几分钟。最令人惊讶的是，其中一位队友注意到并在办公室大声说道。