Kotlin이 훌륭하지만 그래도 Java를 계속 사용해야 하는 이유

어느 그룹에 속해 있든, 다음과 같은 이유가 있습니다. Java. 그리고 여러분을 탓하는 것이 아닙니다. 전 세계에서 가장 발전되고 보편적이며 완벽한 에코시스템을 갖추고 있습니다. 엔터프라이즈 세계. 이 언어는 너무 많은 기능과 너무 적은 기능 사이의 적절한 영역에서 적절하게 조정된 기능 세트를 갖추고 있습니다. 또한 새로운 기능이 느리지만 꾸준히 추가되고 있어 프로그래밍 세계의 최신 트렌드를 대부분 따라잡고 있습니다.

알고 계십니까? 롬복 아직 안 하셨나요? 그렇지 않다면 시도해 보시길 적극 추천합니다. 마음에 드신다면 제가 여러분을 위해 준비한 것이 있습니다. 롬복어를 쓸모없게 만드는 완전히 새로운 언어입니다. 이 언어는 Kotlin.

Kotlin? 안드로이드 언어를 말하는 건가요?

Android용 Kotlin은 사실상 플랫폼의 표준 언어가 될 정도로 Google 자체의 축복을 받았습니다. 이 글에서 집중적으로 다룰 내용은 아니지만, 실제로 Android는 제가 Kotlin을 처음 만난 곳입니다.

당시 제 직장 동료가 앱을 개발 중이었습니다. 프로젝트를 혼자서 만들었습니다. 하지만 마감일이 빠르게 다가오고 있었기 때문에 마감일을 맞추는 것을 도와달라는 위임을 받았습니다. 이제 그 순간으로 시간을 되돌려 보겠습니다. 아아 그리고... 으악! 왜 그가 이상한 언어를 사용하는 걸까요? 케첩 브랜드!? 끔찍해 보여요!

왜 모든 기능 앞에 '재미'라고 쓰여 있나요? 아직 뭔지 모르는 것처럼요. 또한, 저는 이미 재미 와 함께 Java 어쨌든. 반환 유형은 어디에 있나요? 마지막에요? 미쳤어요? 함수에 뭔가를 할당하는 건가요? 말이 안 되잖아요! 모든 것이 다음과 같이 보입니다. 추가 단계가 있는 Java! 잠깐만요, 이 메서드가 속한 클래스가 어디죠? 이 케첩 같은 놈아, 어디 숨겼어? Java 프로그래밍 언어의 변명을 모방하는 건가요? 아니야 아니, 그렇지 않아요. 저거 글로벌 함수인가요? 됐어, 다 끝났어 경찰에 신고할 거야.

스포일러 경고: 저는 경찰을 부르지 않았습니다. 좋든 싫든 다른 언어에 적응하기 위해 자바 중심의 사고방식을 조정해야 했습니다. 그래도 그렇게 나쁘지는 않겠죠? 여전히 JVM 언어이고, 확실히 다른 언어일 뿐이죠. Java. 멋진 추가 기능도 추가할 수 있을까요? 마지못해 프로젝트 작업을 시작했습니다.

추가 단계가 있는 Java

Java가 그렇게 훌륭하다면 왜 Java 2는 없을까요? 농담은 제쳐두고, 저도 그렇게 생각했습니다. 새로운 구문도 있지만 프로젝트를 완료할 수 있을 만큼만 배우면 되니 그냥 Kotlin이 Java 2라고 생각하면 되겠지. 제가 틀렸습니다.

하루나 이틀만 사용해 본 결과, Kotlin과 Java 는 그다지 탄력적이지 않습니다. 서로를 향해 구부리려고 하면 필연적으로 둘 중 하나가 반으로 갈라지는 것으로 끝납니다. Kotlin은 그 자체로 하나의 도구이며, 프로그래머의 관점에서 볼 때 JVM에서 작동한다는 사실은 거의 아무 의미가 없다는 것이 분명해졌습니다. (여담으로, Kotlin은 다음과 같이 변환할 수도 있습니다. JavaScript를 사용하거나 네이티브 바이너리로 컴파일해야 합니다).

그럼 차선책을 마련하세요. 사실, 언어에 대해 알아보세요. 노련한 Java 프로그래머도 처음 문서를 읽으면 등골이 오싹해집니다. 예를 들어
- 앞서 언급한 최상위 수준 일명 글로벌 컨텍스트
- 마지막에 지정된 매개변수 및 함수 반환 유형

fun sum(a: Int, b: Int): Int {
   반환 a + b
}

함수 본문은 표현식이 될 수 있습니다(등호 사용).

 fun sum(a: Int, b: Int) = a + b

IF 문이 결과를 제공할 수 있는 경우

 val y = if (x == 1) {
 "one"
 } else if (x == 2) {
 "two"
 } else {
 "other"
 }

좋아요, 익숙해지면 되겠네요. 구문만 다를 뿐이죠. 코틀린 씨, 또 다른 제안이 있나요?

 value?.method() // null이 아니면 실행합니다.

오, 좋아, 제거 if (value == null)를 클릭하세요. 또 뭐가 있나요?

fun check(list: List, alternative: Boolean) = when {}
 list는 LinkedList -> print("linked")
 alternative -> print("alternative")
 list.size > 50 -> print("big")
 else -> print("other")
 }

좋네요, 다른 차단을 피할 수 있어 편리하긴 하지만 여전히 속임수처럼 보입니다.

 객체 SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "more" else "less"
 }

좋아요, 실제로 유용해 보이는데요, 마음에 듭니다! 반면에 Java로도 싱글톤을 만들 수 있습니다. 이렇게 우아하지는 않겠지만 새로운 것은 아닙니다. 다른 비장의 무기는 없나요? 진짜 강타자 같은 거요?

 var s: 문자열 = null // 컴파일되지 않음, 널이 아닌 유형

잠깐만요... 뭐라고요?

10억 달러의 실수

널 안전성에 대해 걱정할 필요가 없는 코드베이스를 상상해 보세요. 모든 참조에 실제로 의미 있는 내용이 포함되어 있다는 것을 당연하게 여긴다고 상상해 보세요. 모든 널 관련 문제가 사전에 처리된다고 확신한다고 상상해 보세요.
더 이상 상상하지 마세요. Kotlin의 모든 참조는 기본적으로 무효화할 수 없습니다. 참조를 무효화하려면 다음을 수행해야 합니다. 의식적으로 그 결정을 내리고 명시적으로 에 명시하고 코드:

 var s: 문자열? = null

이 시점에서 전체 아이디어에 회의적일 수 있다는 것을 이해합니다. 여러분은 무효화 가능한 참조에 익숙합니다. 코딩하는 동안 머릿속으로만 기억하고 계실 겁니다. 어디를 조심해야 하는지 알게 되었군요. 제 생각이 맞습니다. 출처 Java처음에는 정말 이상하게 느껴졌습니다. 무슨 소용이 있을까? 모든 관련 문제가 마술처럼 사라지진 않겠죠. 그냥 여기저기 "?"를 추가하기만 하면 되잖아요.

하지만 저는 언어에 대해 깊이 파고들기로 결정했죠? 마음대로 하세요, 아저씨 Kotlin. 저는 가능한 한 많은 널 변수, 필드, 매개변수를 제거하기 위해 노력하기 시작했습니다. 단계적으로 세이프 콜 "?" 연산자, 엘비스 "?:" 연산자, 위임된 속성, "let" 메서드 등 널러블 참조를 쉽게 제거할 수 있는 언어 기능을 사용하는 방법을 배웠습니다.

시간이 지나면서 일부 클래스에는 널이 아닌 필드와 메서드 매개변수만 포함하도록 만들 수 있었습니다. 기본적으로 클래스가 성공적으로 인스턴스화되면 메서드 바디의 널 가능성은 거의 잊을 수 있다는 것을 알고 있었습니다. 정말 행복했습니다. 시간이 지날수록 저는 이 점을 점점 더 높이 평가했습니다. 하지만 궁극적으로 저는 이 기능을 킬러 기능으로 생각하지 않았습니다, Java 여전히 집처럼 느껴졌습니다. 하지만...

컴백

프로젝트가 막바지에 다다르고 있었습니다. Kotlin에 대해 점점 더 많이 알게 되면서 코드가 점점 더 깔끔하고 가독성이 높으며 간결해졌습니다. 커밋 기록에서 개선 사항을 육안으로 확인할 수 있었습니다. 하지만 드디어 때가 왔습니다. 새로운 언어에 대한 예상치 못한 좋은 추억을 안고 이제 작별을 고하고 다음과 같은 달콤한 안락함으로 돌아갈 시간이었습니다. Java. 또는 그렇게 생각했습니다.

무언가가 사라진 바로 그 순간에 고마움을 느끼기 시작할 때 어떤 느낌이 드는지 아시나요? 더 이상 사용할 수 없을 때까지 무언가에 얼마나 의존하고 있는지 깨닫지 못할 때요? 제 인생에서 그런 느낌을 가장 잘 느낄 수 있었던 순간이었어요.

다시 코드를 작성하면서 Java일부 기능이 부족해서 거의 겁에 질릴 뻔했습니다. 마치 무의식적으로 Kotlin 기능을 Java에 잘못 끼워 맞춘 것 같았죠. 실제로 무언가를 구현하기 시작했는데 이 언어에서는 작동하지 않는다는 것을 깨닫는 상황을 경험하기도 했습니다. 가장 좋은 경우는 Kotlin처럼 작성할 수 있지만, 부피가 커지거나 가독성이 떨어지거나 상용구가 너무 많이 필요한 경우입니다.

물론 제가 가장 그리워했던 기능은 널 안전성이었습니다. 하지만 명명된 매개변수, 게터와 세터 대신 프로퍼티, 같음의 "==" 및 참조 같음의 "===", 한정된 "this", 확장 함수, 암시적 단수 람다 매개변수, 사용하지 않는 람다 매개변수의 "_", 데이터 클래스, 범위 함수, 기타 Kotlin stdlib 함수, 연산자 등 얼마나 많은 작은 것들이 저에게 자연스러워지는지 놀랐던 것이죠. 그리고 이 모든 것이 서로 잘 맞습니다. 이에 비해 Java는... 원시적인 느낌이 들었습니다.

사실 너무 아쉬워서 아예 Kotlin으로 전환하는 것을 고려하기 시작했습니다. 이론적으로는 Java와 완전히 상호 운용이 가능하므로 기존 프로젝트에 Kotlin 지원을 추가하고 새 클래스를 작성하기만 하면 됩니다. Kotlin은 Java와 '대화'하는 방법을 알고 있고, Java는 다른 언어와 '대화'하고 있다는 사실조차 모릅니다. 그리고 바이트코드로 컴파일한 후에는 JVM에 실제로 어떤 차이도 발생하지 않습니다.

현실 점검

그래서 뭘 망설이고 계신가요? 말처럼 좋은 언어라면 그냥 사용하세요! 물론 기존 프로젝트에서는 상호 운용이 가능해야 하지만, 서로 다른 두 가지 언어를 섞는 것은 보기 흉하게 들릴 수도 있습니다.

자, 새 모듈의 경우 Kotlin이 맞습니다. 아니면 그렇지 않나요? 여러분은 팀. 그들과 상담하고 이 새로운 언어의 위대함에 대해 설득해야 합니다. 왜요? 싫어하나요? 배우려는 노력을 기울이고 싶지 않은 것 같네요. 당신도 처음에는 회의적이었으니 그들을 탓할 수는 없겠죠.

프로젝트 매니저! 예! 그는 Kotlin이 우리 팀에 얼마나 큰 가치를 가져다줄지 분명히 이해할 것입니다. 오, 앞으로 다가올 위대함!
-아니요
-잠깐만요, 왜요?
-팀도 모릅니다.
-배우게 될 것입니다!
-학습하고 싶지 않습니다.
-만들 수 있습니다!
-학습할 필요가 없습니다.
-하지만 가능성을 생각해 보세요!
-네, 문제점에 대해 먼저 생각해 보는 건 어떨까요?

전설에 따르면 어떤 프로젝트가 존재한다고 합니다. 크고 복잡하지만 모든 부분이 훌륭하게 작성된 프로젝트. 모든 개발자가 한마음으로 중고 솔루션에 대해 논의하는 프로젝트. 프로그래머의 키보드에서 새로운 기능이 매끄럽게 흘러나오는 곳. 버그가 드물고 수정하기 쉬운 프로젝트.

그런 프로젝트를 본 적이 있나요? 못 봤습니다. 몇몇은 비슷하지만 대부분은 레거시 코드가 엉망진창입니다. 그리고 그렇지 않더라도 언젠가는 그렇게 될 것입니다. 이제 여기에 다른 언어가 추가된다고 상상해 보세요. 실수할 수 있는 새로운 방법이 생겨납니다. 개발자는 자신이 무엇을 하고 있는지 알아야 합니다. 한마디로 위험천만한 일입니다.

이제 개발자 로테이션도 고려하세요. 사람들은 왔다 갔다 합니다. 모든 신규 개발자에게 완전히 새로운 언어를 배우게 할까요? 이는 비생산적입니다. 처음부터 Kotlin 개발자를 채용할 건가요? 좋은 Java 개발자를 고용하는 것도 충분히 어려운 일입니다.

사람들은 시도해 보았습니다. 저는 그 기사에 나온 대부분의 주장에 동의하지 않는다고 말해야 합니다. 일부 타당한 비판이 있긴 하지만, 실제로 'Kotlin 방식'을 이해할 만큼 Kotlin을 충분히 사용하지 않았다고 생각합니다. 해당 기사의 많은 댓글 작성자들도 비슷한 생각을 하는 것 같습니다.

하지만 그건 중요하지 않습니다. 여러분의 프로젝트에서도 이런 일이 일어날 것입니다. "해봤는데 마음에 들지 않아". 더 많은 시간을 할애하게 만들지 않을 것입니다. 다시 시도하게 만들지 않을 것입니다. 다른 기회를 주지 않을 것입니다. 실용적인 관점에서 보면 그 말이 맞을 수도 있습니다. Java 는 너무 인기가 많아서 JVM에서 다른 것을 사용하는 것이 중복되는 것처럼 보입니다.

그렇다면 왜 이 글일까요?

방금 상당한 시간을 들여 글을 썼는데 아무 의미가 없는 것 같습니다. 어차피 아무 소용이 없는데 왜 언어를 배우려고 하겠어요?

글쎄요, 무의미하다고 생각하지 않아요. 저는 여전히 Kotlin이 훌륭하다고 생각합니다. 저는 여전히 실제로 사용하고 싶고 실제로 개인 프로젝트에 사용하고 있습니다. 그럴 수만 있다면 코틀린으로 전환하고 Java의 한계를 잊고 싶어요. 하지만 현재 현실은 그럴 수 없다는 것을 말해줍니다. 그리고 저는 그것을 바꾸고 싶어요.

독자 여러분, 제 의도는 적어도 아늑한 Java의 안전 지대에서 벗어날 수 있는 가능성을 열어드리는 것입니다. 어쩌면, 어쩌면 여러분도 저만큼이나 Kotlin을 사랑하게 될지도 모르니까요. 그렇게 된다면 Kotlin을 잘 아는 개발자가 한 명 더 늘어나는 것이니까요. 시장.

자세히 읽어보세요:

Java를 위한 최고의 프로젝트 유형

스타트업을 위한 소프트웨어 제품 개발의 3가지 공통 과제

최고의 Java 개발자를 찾는 올바른 방법