Java에서 Kotlin으로

2장. Java에서 Kotlin 프로젝트까지

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

순수 Java에서 혼합 코드베이스로, 그리고 점점 더 Kotlin 코드베이스로 전환하는 여정의 첫 번째 단계는 무엇인가요?

전략

Nat과 Duncan이 처음 Java 코드베이스에 Kotlin을 도입했을 때 우리는 6명의 개발자로 구성된 소규모 팀의 일원으로 비교적 신생 프로젝트를 구축하고 있었습니다. 우리는 이미 일부 웹 애플리케이션을 Kotlin으로 배포했지만 엔터프라이즈 아키텍트는 새 시스템을 Java 8로 작성해야 한다고 주장했습니다. 이 시기는 Kotlin 1.0이 출시된 직후였지만 Google이 Kotlin을 Android의 공식 언어로 발표하기 전이어서 아키텍트들은 수십 년 동안 사용할 전략적 시스템을 위해 미래가 불확실한 언어를 사용하는 것을 당연히 경계했었죠.

Java에서는 핵심 애플리케이션 도메인 모델을 파이프라인에 의해 변환되는 불변 데이터 유형으로 설계하는 기능적 접근 방식에 의존했습니다. 하지만 불변 값 유형을 구현하는 데 필요한 장황함, 기본 유형과 참조 유형의 구분, 널 참조, 일반적인 고차 함수가 없는 스트림 등 Java의 한계에 계속 부딪혔습니다. 한편 업계 전반과 회사 내부에서도 Kotlin을 채택하는 비율이 점점 높아지고 있는 것을 볼 수 있었고, Google의 발표를 보고 Java를 Kotlin으로 전환하기로 결심했습니다.

핵심 도메인 모델에서 시작하면 가장 큰 효과를 얻을 수 있을 것으로 판단했습니다. Kotlin의 데이터 클래스는 코드를 크게 줄였고, 경우에 따라 수백 줄의 코드를 단일 선언으로 대체했습니다. 우리는 신중하게 시작하여 IntelliJ를 사용하여 표준 라이브러리에 있는 클래스 외에 다른 클래스에 대한 종속성이 없는 작은 값 클래스를 변환하고 이것이 나머지 Java 코드베이스에 어떤 영향을 미치는지 조사했습니다. 전혀 영향을 미치지 않았습니다! 이 성공에 용기를 얻은 우리는 속도를 높였습니다. 새로운 기능을 위해 Java 도메인 모델 클래스를 변경해야 할 때마다 먼저 Kotlin 데이터 클래스로 변환하고, 변환을 커밋한 다음 기능을 구현했습니다.

더 많은 도메인 모델 로직이 순수 Kotlin이 되면서 Kotlin 기능을 더 잘 활용할 수 있었습니다. 예를 들어 컬렉션과 시퀀스에서 Stream API 호출을 Kotlin의 표준 함수로 대체했습니다. 하지만 가장 큰 개선 사항은 Java의 Optional 유형 사용을 널 가능 참조로 대체한 것입니다. 이를 통해 코드가 단순해지고 널 안전성에 대한 확신을 더 갖게 되었죠.

회사의 다른 프로젝트에서는 다른 이유로 Kotlin을 채택했습니다. 종속성 주입 프레임워크에 구축된 성숙한 Java 시스템을 보유하고 있었습니다. 개발자들은 프레임워크의 리플렉션 및 주석 사용으로 인해 IDE에서 코드를 이해하고 탐색하기 어렵다는 것을 알게 되었습니다. Kotlin의 경량 클로저 ...