现在每个人都在谈论拥有良好的开发者体验是多么重要，因为它会带来很多好的副作用，例如但不限于：
开发速度/生产力
代码质量/维护
节省成本等等
然而，我们经常让自己从事的项目在过去的某个时间添加了一小段代码来使项目更快，甚至修复某些东西，也许有人试图使构建更快，甚至尝试给工程师更好的开发体验。这个故事就是这种情况。
几年前，在我们从事的一个项目中（在我加入公司之前），发现了构建 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 拉到任何分支他们正在研究，其中一些人在第一次尝试时没有注意到任何事情，其他人开始注意到在更改代码库中的任何代码后，它在几秒钟内仅编译受影响的文件，而不是像以前那样几分钟。最令人惊讶的是，其中一位队友注意到并在办公室大声说道。
Gust ...你修复了编译循环问题吗？我正在这里工作，并且我会收到有关代码中任何更改的即时反馈。
当时我不得不承认，并与所有其他工程师分享这个消息，这让我成为一个更快乐的工程师，因为现在我很高兴在这个项目上工作，而不是等待很长时间来完成我们项目的完整编译。
如果你觉得某件事是我们的方式，无论何时，无论你在做什么，请记住你有机会让它变得更好，永远不要忘记你已经开始的事情。
如果您喜欢阅读这篇文章或希望它有更多内容，请在评论中告诉我，我很乐意分享更多有关此旅程的信息。
感谢您的阅读。
该项目的一些统计数据：
项目启动：
大约 4000 个 Java 文件
大约 300 个旋转模板
对于代码的任何更改，改进前的编译时间为 3 到 5 分钟
改进后的编译时间完整编译平均为 1 分 20 秒
改进后的编译时间平均为 5 到 10 秒，任何更改都有即时反馈（花费最多的时间是 Playframework 重新启动 HTTP Server）
封面图片由AI制作。
