천 달러짜리 한 줄 실수 - SBT + PlayFramework

요즘에는 모두가 좋은 개발자 경험을 갖는 것이 얼마나 중요한지 이야기합니다. 왜냐하면 좋은 개발자 경험에는 다음과 같은 많은 좋은 부작용이 있기 때문입니다.

• 개발 속도 / 생산성

• 코드 품질/유지관리

• 비용 절감 등

그러나 우리는 과거 어느 시점에 프로젝트 속도를 높이기 위해 작은 코드 조각을 추가하거나 심지어 무언가를 수정하기 위해 프로젝트를 진행하는 경우가 많습니다. 누군가가 빌드 속도를 높이려고 했을 수도 있습니다. 심지어 엔지니어들에게 더 나은 개발 경험을 제공하려고 노력합니다. 이번 이야기도 그랬습니다.

몇 년 전, (제가 회사에 합류하기 전에) 우리가 작업했던 프로젝트에서 SBT, Scala 및 플레이 프레임워크 구축과 관련된 문제가 확인되었으며, 로컬에서 프로젝트를 구축하는 데 컴파일 시간이 소요되었습니다. 기계에 따라 약 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 참조 매뉴얼에 설명된 대로 - 다중 프로젝트

집계의 두 가지 정의를 알아두는 것이 중요하며

집계는 집계 프로젝트에서 작업을 실행하면 집계된 프로젝트에서도 해당 작업이 실행됨을 의미합니다

프로젝트는 다른 프로젝트의 코드에 따라 달라질 수 있습니다. 이 작업은 presentsOn 메소드 호출을 추가하여 수행됩니다. 예를 들어 코어의 클래스 경로에 util이 필요한 경우입니다.

하루나 이틀 동안 문서를 읽고 문제를 해결하기 위해 여러 번 좌절한 끝에 이 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년 동안 노력했습니다...

여파 - 문제 해결

내가 이미 마스터에 놀라운 기능을 병합했다고 팀원들에게 말한 후 사람들은 무슨 일이 일어나고 있는지 이해하지 못했습니다. 그러나 나는 그들의 얼굴에서 행복한 모습을 보고 싶었고 팀 전체에게 마스터를 어떤 작업에든 끌어들이라고 말했습니다. 일부는 첫 번째 시도에서 아무 것도 알아차리지 못했고, 다른 일부는 코드베이스의 코드를 변경한 후 이전처럼 몇 분이 아니라 몇 초 만에 영향을 받은 파일만 컴파일하고 있다는 사실을 알아차리기 시작했습니다. 그리고 가장 놀랐던 점은 사무실에서 팀원 중 한 명이 이를 발견하고 큰 소리로 말했다는 것입니다.

Gust... 컴파일 루프 문제를 해결하셨나요? 저는 여기서 뭔가 작업을 하고 있는데 코드 변경 사항에 대한 즉각적인 피드백을 받습니다.

그 당시 저는 인정해야 했고 다른 모든 엔지니어들과 이 소식을 공유했습니다. 덕분에 저는 더 행복한 엔지니어가 되었습니다. 이제 이 프로젝트에 참여하는 것이 행복하고 프로젝트 전체가 편집되기까지 오랜 시간을 기다리지 않아도 됩니다. .

뭔가가 우리 방식이라고 생각된다면, 언제, 무엇을 하든 그것을 더 좋게 만들 수 있는 기회가 있다는 것을 기억하고, 시작한 일을 절대 잊지 마세요.

이 기사가 마음에 들었거나 더 많은 콘텐츠를 원하시면 댓글로 알려주시기 바랍니다. 이 여행에 대해 더 많은 정보를 공유하게 되어 기쁩니다.

읽어주셔서 감사합니다.

프로젝트의 몇 가지 통계:

프로젝트 시작:

• Java 파일 약 4,000개

• 약 300개의 Twirl 템플릿

• 코드 변경 시 개선 전 컴파일 시간 3~5분

• 전체 컴파일 평균 1분 20초 개선 후 컴파일 시간

• 개선 후 컴파일 시간은 즉각적인 피드백이 포함된 모든 변경 사항에 대해 평균 5~10초입니다(가장 소요되는 시간은 Playframework가 HTTP 서버를 다시 시작하는 데 소요됩니다)

AI가 만든 표지 이미지.

위 내용은 천 달러짜리 한 줄 실수 - SBT + PlayFramework의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!