Backend/Spring Framework

[Spring Boot] 주관적인 스프링 부트 + 코틀린 장단점

mopil 2022. 8. 12. 23:51
반응형

신규 프로젝트를 진행하면서 기존 자바 + 스프링 부트에서 코틀린 + 스프링 부트로 프로젝트를 작성해 봤다.

이를 통해서 직접 느낀 코틀린의 장단점(매우 주관적임!!)을 기록하고 공유하고자 한다.

 

# 장점

코틀린 언어 차원에서 얻는 장점이 매우 많다.

 

1. 함수 파라미터에 디폴트 값 지정가능

2. 문자열 변수 연산자 $ 의 존재

3. 널 세이프 연산자들 (?, !!, ?.let 등)

4. 람다식, 함수형 프로그래밍 적극 지원 -> 함수를 일급 객체로 사용할 수 있는 점, let, apply 등 스코프 함수의 존재, 코틀린 DSL (덤으로 인텔리제이가 람다함수를 하이라이트 해주는 기능도 너무 좋다.)

6. static은 없지만, 클래스 외부에 함수 선언 가능 (사실상 static 이 필요없다.)

7. when 문 (==자바 13의 개선된 switch 표현식) - when 문 결과값을 바로 변수에 할당 가능 

8. 하나의 코틀린 파일에 여러개의 클래스 선언 가능 with data class (DTO 제작에 매우 용이) - 개인적으로 생각하는 최대 장점

9. 세미콜론 안 붙혀도 됨

 

널 세이프 연산자들과 data class 를 활용한 DTO 제작, 스코프 함수 및 람다식 적극 지원으로 오는 비즈니스 로직의 간결성 이 세 가지가 코틀린을 사용하면서 얻을 수 있는 최대 장점이라고 생각한다.

 

# 단점

1. JPA Entity 제작시 setter를 막을 방법이 없음

Entity는 프로젝트 규모가 커질수록 어디서 변경이 이루어졌는지 추적하기 쉽게 하기 위해서 setter 사용을 지양하는 (거의 금지)하는 방식으로 제작해야 한다.

 

자바에서는 그냥 @Setter 롬복을 제외하면 되는데, 코틀린에서는 이를 막을 방법이 없다.

 

https://multifrontgarden.tistory.com/272

 

kotlin(+JPA) entity 에서 setter 를 막을 수 있을까

처음 자바를 배울때만해도 getter, setter 는 객체지향 언어인 java 의 캡슐화의 산물이었다. 하지만 개발자로써 경험을 하고, 공부해오면서 getter, setter 로는 충분한 캡슐화를 제공하기 어렵고, 특히

multifrontgarden.tistory.com

자세한 내용은 위 글을 참조하면 좋을 것 같다.

 

 

2. jackson ObjectMapper 사용시 주의점이 존재함

jackson - 코틀린 조합이 안 좋은 것 같다.. 이유는 모르겠으나, isNotice나 isXXX 으로 변수를 만들어서, JSON 파싱을 진행해보면 되질 않는다. 그래서 특별한 조치를 취해줘야 한다. 자세한건 다음 블로그 글을 참조할 것.

https://sinna94.tistory.com/entry/Kotlin-jackson-%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-%EA%B0%9D%EC%B2%B4%EB%A5%BC-json-%EC%9C%BC%EB%A1%9C-%EB%B3%80%ED%99%98%ED%95%A0-%EB%95%8C-%EC%A3%BC%EC%9D%98%EC%A0%90

 

Kotlin - jackson 을 이용하여 객체를 json 으로 변환할 때 주의점

import com.fasterxml.jackson.databind.ObjectMapper import com.fasterxml.jackson.module.kotlin.KotlinModule fun main(args: Array ) { val testData = TestData("name", "code", false) println(testData) v..

sinna94.tistory.com

 

 

# 결론

개인적으로 크게 와닿았던 장점들은 DTO 클래스를 제작할 때 하나의 코틀린 파일에 여러 클래스를 작성할 수 있는 점과, 함수를 클래스 밖에 선언할 수 있는 점이 이었던 것 같다.

 

하지만 단점도 명확한데, 아직 규모가 큰 프로젝트를 경험해보지 못해서 실감은 안 나지만, JPA setter 문제가 심각한 것 같다. 팀원끼리 상의하에 사용을 지양하면 되긴하나... 사람 문제는 코드 에러보다 더 잡기 힘든게 아니겠는가?

 

반응형