現在每個人都在談論擁有良好的開發者體驗是多麼重要，因為它會帶來很多好的副作用，例如但不限於：
開發速度/生產力
程式碼品質/維護
節省成本等等
然而，我們經常讓自己從事的專案在過去的某個時候添加了一小段程式碼來使專案更快，甚至修復某些東西，也許有人試圖使構建更快，甚至嘗試給工程師更好的開發體驗。這個故事就是這種情況。
幾年前，在我們工作的一個專案中（在我加入公司之前），發現了建構SBT、Scala 和play 框架的問題，在本地建置專案的編譯時間約為3至5 分鐘，具體取決於機器。已嘗試解決該問題。項目結構分為 2 部分，如下所示：
之前
之後
以下內容已加入 build.sbt 中
這樣做確實提高了編譯時間，只是在CI 管道上構建期間，我不確定它在開發階段是否有幫助，但是，它增加了一個新的可怕的錯誤，使開發人員浪費了數千小時工作的.
加入此行後，開發人員開始注意到只執行一個簡單的程式碼就需要多長時間
sbt 在本地運行，對於現在程式碼庫中的每一個更改，都需要完整的編譯。
根據 SBT 參考手冊 - 多項目中記錄
重要的是要注意聚合和依賴的兩個定義
聚合意味著在聚合項目上運行任務也會在聚合項目上運行
一個專案可能依賴另一個專案中的程式碼。這是透過新增 dependentOn 方法呼叫來完成的。例如，如果核心在其類別路徑上需要 util。
在花了一兩天閱讀文件並多次嘗試解決該問題後，我最終到達了這個Github - Spurious recompilation in multi-project build 這並不是修復本身，但是，在結束時給了我光明通過隧道了解問題確實與多項目設定有關。
更進一步，我明白髮生了什麼，現在我的 build.sbt 檔案就這麼簡單：
我們在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制作。
以上是千元一行错误 - SBT + PlayFramework的详细内容。更多信息请关注PHP中文网其他相关文章！
