千ドル一行の間違い - SBT + PlayFramework-＆＃＆チュートリアル-php.cn

千ドル一行の間違い - SBT + PlayFramework

PHPz

リリース： 2024-07-17 16:05:23

オリジナル

373 人が閲覧しました

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 リファレンスマニュアル - マルチプロジェクトに記載されているとおり

集約の 2 つの定義に注意することが重要です。

集約とは、集約プロジェクトでタスクを実行すると、そのタスクが集約プロジェクトでも実行されることを意味します

プロジェクトは別のプロジェクトのコードに依存している場合があります。これは、dependsOn メソッド呼び出しを追加することで実行されます。たとえば、コアのクラスパスに util が必要な場合。

1 ～ 2 日かけてドキュメントを読み、問題を解決しようと何度も挫折した結果、最終的にこの Github - マルチプロジェクトビルドにおける偽の再コンパイルにたどり着きました。これは修正そのものではありませんでしたが、最後には明るい気分になりました。トンネルの詳細を調べて、問題が実際にマルチプロジェクト設定にあったことを理解しました。

さらに、何が起こっているのかを理解し、build.sbt ファイルは次のように単純になりました。

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

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

ログイン後にコピー

SBT での projectA の設定方法に問題がありました。私たちは SBT にプロジェクトの API を含めるように指示しましたが (これは正しかったです)、API 定義はプロジェクトルート全体を指していました。これは次のことを意味します:

API のコンパイルが必要になるたびに、SBT は projectA 自体もコンパイルしようとします。
projectA は API をコンパイルする必要があるため、別の API コンパイルがトリガーされます。
これにより無限ループが生じ、開発者は SBT を強制終了し、コードを変更するたびにすべてを手動でクリーンアップしてコンパイルする必要がありました。
何が起こったのかを簡単に説明すると次のとおりです。

私たちは SBT にプロジェクトの API を含めるよう指示しました。
API 定義はプロジェクト全体を指していました。
API をコンパイルすると、プロジェクト全体のコンパイルがトリガーされました (再び API を含む)。
このループにより、SBT は非常に遅くなり、開発者にとってイライラするものになりました。

チームは少なくとも 4 年間この問題に取り組んできました...

余波 - 問題の修正

チームメイトに、サプライズ機能がすでにマスターに統合されていると話した後、人々は何が起こっているのか理解していませんでしたが、私は彼らの喜ぶ顔が見たかったので、チーム全体にマスターを任意の機能に引き込むように言いました。彼らは、最初の試行では何も気付かなかった人もいましたが、コードベース内のコードを変更した後、影響を受けたファイルだけが以前のように数分ではなく数秒でコンパイルされることに気づき始めた人もいました。そして一番の驚きは、チームメイトの一人がそれに気づき、オフィスで大声で言ったことです。

ガスト ...コンパイルループの問題は修正されましたか?私はここで何かに取り組んでおり、コードの変更について即座にフィードバックを受け取ります。

当時、私は認めなければならなかったので、他のエンジニア全員にこのニュースを共有しましたが、今ではこのプロジェクトに楽しく取り組むことができ、プロジェクトの完全なコンパイルを長時間待つ必要がなくなり、エンジニアとしてより幸せになりました。 .

何かが私たちのやり方だと感じたら、いつでも、何をしていても、それを改善するチャンスがあることを思い出してください。自分が始めたことを決して忘れないでください。

この記事を読んで気に入った場合、またはもっと内容を増やしたい場合は、コメント欄でお知らせください。この旅についてさらに詳しく共有させていただきます。

お読みいただきありがとうございます。

プロジェクトからのいくつかの統計:

プロジェクトの開始:

約 4,000 個の Java ファイル
約 300 個の Twirl テンプレート
コードの変更による改善前のコンパイル時間は 3 ～ 5 分
改善後のコンパイル時間は完全コンパイルで平均 1 分 20 秒
改善後のコンパイル時間は、即時フィードバックによる変更の平均 5 ～ 10 秒 (最も費やされる時間は、Playframework が HTTP サーバーを再起動する時間です)

AI によって作成されたカバー画像。

以上が千ドル一行の間違い - SBT + PlayFrameworkの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。