23장. 여정 계속하기
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
책의 마지막에 도착했습니다. 여정에 함께 해주셔서 감사합니다. 저자들은 많은 훌륭한 개발자들과 함께 일하고 그들에게서 배울 수 있는 영광을 누렸고, 이제 여러분도 그 명단에 이름을 올리게 되었습니다. 몇 장을 건너뛰거나 이상한 리팩터링 도중에 멍해지더라도 대화할 사람이 있어서 좋았습니다. 트래블러 개선에 더는 함께할 수는 없지만 여행을 통해 무엇을 배울 수 있었나요?
O'Reilly에서 Kotlin에 대한 책을 쓰고 싶냐고 물었을 때, 우리는 무엇을 쓰고 싶은지, 충분한 사람들이 읽고 싶어할 만한 책이 무엇인지 생각해야 했습니다. 우리는 이 언어를 채택하는 여정을 해왔고 목적지에 익숙하다는 것을 알고 있었지만 우리의 출발점이 일반적인 Java 개발자와는 다르다는 것도 알고 있었습니다. 기존의 대부분의 책에서 Kotlin을 마치 적은 타이핑으로 많은 것을 얻을 수 있지만 접근 방식의 변화가 필요하지 않은 Java의 다른 구문인 것처럼 가르치는 것을 보았기 때문이죠. 저희의 경험과는 달리 Kotlin의 장점은 Java보다 더 기능적인 사고가 필요하다는 것을 알게 되었습니다. 하지만 Kotlin의 함수형 프로그래밍에 관한 책은 독자에게 객체를 사용한 프로그래밍에 대해 알고 있는 모든 것을 버리고 새로운 컬트에 가입하라고 요구하는 것 같습니다. 저희도 불편했습니다. 클래스와 객체는 특히 많은 함수형 숙어에 비해 인간적인 동작 표현 방법입니다. 공간이 충분한데 왜 상자에서 도구를 제거할까요? 그냥 더 많은 도구를 가지고 작업에 적합한 것을 선택하면 되지 않나요?
곡물
이러한 생각으로 Nat은 프로그래밍 언어에는 우리가 작성하는 프로그램의 디자인에 영향을 미치는 결이 있다는 은유를 떠올렸습니다. 결은 특정 디자인 스타일을 적용하기 쉽게 만들기도 하고 다른 스타일을 어렵거나 위험하게 만들기도 합니다.
Kotlin의 결은 Java의 결과 다릅니다. Java의 결은 구성 가능성과 유형 안전성을 희생하는 대신 변경 가능한 객체와 리플렉션을 선호합니다. Java에 비해 Kotlin은 변경 불가능한 값과 독립형 함수의 변환을 선호하며 눈에 거슬리지 않고 유용한 유형 시스템을 갖추고 있습니다. IntelliJ를 사용하면 Java를 Kotlin으로 변환하는 것은 쉽지만, 생각을 바꾸면 새로운 언어가 제공할 수 있는 모든 것을 활용하지 않고 Kotlin 구문에서 Java로 끝나는 결과를 낳게 됩니다.
Java와 Kotlin은 동일한 코드베이스에서 공존할 수 있으며 상호 운용 경계는 거의 완벽하지만, 엄격하게 유형화된 Kotlin의 세계에서 보다 느슨하게 유형화된 Java의 세계로 정보를 전달할 때 몇 가지 위험이 있습니다. 주의를 기울이면 가능한 경우 자동화된 리팩터링 도구를 사용하고 마지막 수단으로 텍스트를 편집하여 관용적인 Java에서 관용적인 Kotlin으로 코드를 작고 안전한 단계로 변환할 수 ...