千元一行錯誤 - SBT + PlayFramework-java教程-PHP中文網

千元一行錯誤 - SBT + PlayFramework

PHPz

發布： 2024-07-17 16:05:23

原創

327 人瀏覽過

The thousand dollars one line mistake - SBT + PlayFramework

現在每個人都在談論擁有良好的開發者體驗是多麼重要，因為它會帶來很多好的副作用，例如但不限於：

開發速度/生產力
程式碼品質/維護
節省成本等

但是，我們經常在過去的某個時間從事項目，添加一小段程式碼以使專案更快，甚至修復某些問題，也許有人試圖使構建更快，或者甚至試圖給工程師更好的開發體驗。這個故事就是這種情況。

幾年前，在我們工作的一個專案中（在我加入公司之前），發現了建立SBT、Scala 和play 框架的問題，其中本地建置專案的編譯時間很長大約3 到5 分鐘，具體取決於機器。已嘗試解決該問題。項目結構分為 2 部分，如下所示：
之前

ProjectA
  /api
 /core
 /app

登入後複製

之後

ProjectA
 /core
 /app

ProjectApi
  /api

登入後複製

以下內容已新增至 build.sbt

lazy val projectA = (project in file("."))
  .enablePlugins(...)
  .settings(commonSettings)
  .aggregate(api)
  .dependsOn(api)

lazy val api = project.settings(commonSettings)

登入後複製

透過這樣做，它確實提高了編譯時間，只是在CI 管道上建置期間，我不確定它在開發階段是否有幫助，但是，它增加了一個新的可怕的錯誤，使開發人員浪費了數千美元工作時間。

加入此行後，開發人員開始注意到運行一個簡單的程式碼需要多長時間
sbt 在本地運行，對於現在程式碼庫中的每一個更改，都需要完整的編譯。

理解問題的旅程

根據 SBT 參考手冊 - 多項目中的記錄

重要的是要注意聚合的兩個定義，並且取決於

聚合表示在聚合項目上執行任務也會在聚合項目上執行

一個專案可能依賴另一個專案中的程式碼。這是透過新增 dependentOn 方法呼叫來完成的。例如，如果核心在其類別路徑上需要 util。

花了一兩天閱讀文件並多次嘗試解決問題後，我最終到達了這個Github - Spurious recompilation in multi-project build 這並不是修復本身，但是，最終給了我光明了解問題確實與多項目設定有關。

更進一步，我明白髮生了什麼，現在我的 build.sbt 檔案就這麼簡單：

lazy val projectA = (project in file("."))
  .enablePlugins(...)
  .settings(commonSettings)
  .dependsOn(api)

lazy val api = (project in file("api"))
  .settings(commonSettings)

登入後複製

我們在 SBT 中設定項目 A 的方式有問題。我們告訴 SBT 包含專案的 API（這是正確的），但 API 定義指向整個專案根。這意味著：

每當API需要編譯時，SBT也會嘗試編譯projectA本身。
由於projectA需要API進行編譯，因此會觸發另一個API編譯。
這造成了無限循環，迫使開發人員終止 SBT，並為每次程式碼更改手動清理和編譯所有內容。
用更簡單的術語來說，這是發生的事情：

我們告訴 SBT 包含該項目的 API。
API定義指向整個專案。
編譯 API 觸發了完整的專案編譯（再次包含 API）。
這個循環使得 SBT 非常緩慢並且讓開發者感到沮喪。

團隊已經為這個問題工作了至少 4 年......

後果 - 解決問題

當我對我的隊友說我已經在master上合併了一個令人驚訝的功能後，人們不明白發生了什麼，但是，我想看到他們臉上的幸福，我告訴整個團隊將master拉入任何他們中的一些人在第一次嘗試時沒有註意到任何事情，另一些人開始注意到在更改程式碼庫中的任何程式碼後，它只在幾秒鐘內編譯受影響的文件，而不是像以前那樣幾分鐘。最令人驚訝的是，一名隊友注意到了這一點，並在辦公室大聲說。