포트폴리오 코드 리뷰를 하다가 DTO 클래스에 달린 @Data 어노테이션을 보고
'이게 위험할 수 있는 Annotation인 것은 알지만 아직 바꾸지 않았습니다'라고 했다.
정확히 뭐가 위험할 수 있는 것일까?
그러면 Lombok 자체가 위험한 것일까??
(Lombok을 구글에 검색하니 인도네시아의 섬만 나온다...)
Lombok의 가장 장점은 간편하다!
@Data로 예를 들자면 @Data 어노테이션 하나로 DTO나 VO의
Setter + Getter + ToString + Equals + HashCode 메소드를 다 만들어준다.
아니 그러면 '이렇게 심플하게 쓰는게 최고아닌가?' 싶지만 크게 2가지 문제가 있다.
- IDE(STS, IntelliJ 등)에서 별도의 플러그인이나 설정을 해줘야 함
- Annotation을 통해 자동 생성되는 Code에서 발생하는 문제
1번 문제의 경우는 좀 귀찮을 수는 있지만 해주면 된다.
의존성을 설정하고 플러그인을 설치한 후 IntelliJ의 경우
위와 같이 Setting에서 Check 해주면 된다.
- 설정 방법 참고
IntelliJ : https://siyoon210.tistory.com/23
STS : https://yunyoung1819.tistory.com/95
문제는 2번의 경우라고 생각한다.
개발자가 작성하지 않아 Code로 표현되고 있지 않기 때문에
Debugging의 BreakPoint를 설정 할 수도 없고
일단 Debugging을 해야하는 상황을 만드는 자체가 문제다.
위 3개의 Annotation이 가장 위험하다고 한다.
생성자를 자동으로 만들어줘서 나도 편하게 사용했는데
문제는 역시 자동으로 만들어 주기 때문에 개발자가 내부 동작을 놓칠 수 있는 것이다.
아래 코드는 이 글(https://kwonnam.pe.kr/wiki/java/lombok/pitfall)을 참고하여 만들어 보았다.
만약 누군가 비트코인 거래라는 Class를 만들고 Field를 위와 같이 설정했다고 하자.
사용하는 측에서는 이런 식으로 거래 정보를 생성하여 사용할 것이라 예를 들고
그런데 만약 위의 BitCoinTrade Class에서 sell이 buy보다 위에 있는 것이
마음에 안들어 둘의 순서를 바꾸는 Refactoring을 했다고 하자.
그러면 아래와 같은 대참사가 벌어질 수 있다...
비트코인이 떡상해서 팔아야지 하고 첫번째 인자에 sell할 수량을 입력하다가
오히려 그만큼을 buy하는 결과를 만든다. (크게 물린다...)
(그나마 IntelliJ라 인자의 name이라도 보여주지 다른 IDE면 인지하지도 못한다.)
위 글의 부분을 인용하여 설명하자면 Lombok은 Field의 선언 순서에 따라
생성자를 만들기 때문에 개발자의 의도와는 다른 순서로 생성자의 Parameter를 받게 될 수 있고
buy와 sell은 Type이 같은 int이기 때문에 실행시 Error도 발생하지 않는다.
@Getter의 경우는 크게 위험하지는 않을 수 있다고 하나(Open된 Data를 가져오는 정도라면)
@Setter의 경우 Data를 변경하는 것이라 문제가 될 수도 있고
(변경하지 않을 값까지 setter 생성)
내부에 조건문(if)을 사용할 수도 없어 자유도가 떨어지는 것 같다.
참고글 : https://velog.io/@rosa/Lombok-%EC%A7%80%EC%96%91%ED%95%B4%EC%95%BC-%ED%95%A0-annotation
예전에 유명 과학자(아인슈타인이었나?)가 과거에 열차 선로변경 담당자로 일한 적이 있었는데
알람을 믿고 잠 들었다가 탈선 사고가 날 뻔했다는 글을 읽은 기억이 있다.
확대 해석이긴하지만 자동화의 경우 편리할 수는 있으나 위의 경우처럼
나태로 인해 큰 사고로 이어질 수도 있고
생각지도 못한 경우로 뒤통수를 맞을 수 있다고 생각한다.
요즘은 IDE에서 반복적인 Code는 자동 생성해주니(이것도 자동화인가...?)
Lombok은 Toy 프로젝트 정도에서 사용하자는 의견이 맞다고 생각한다.
(@Slf4j 정도는 Log라 괜찮을 것 같다.)
