Lombok 사용은 옳은가 #5
Replies: 1 comment
-
|
발제: Lombok에 대한 생각
찬성 의견들
반대 의견들
팀에서 롬복 사용하는지콜/제: 사용 중. 생성자, getter 선언정도만 사용 → but 사용 원하지 않음 에: 사용 중. 필요에 의한 어노테이션만 사용 중 → 매우 만족 리: 쓰고 있다 → 안 써봤던 사람은 써보고 싶었다 어떤 근거로 롬복 도입을 했는지/안 했는지에버: 대.만.족. → 게터 / 생성자 / equalsandhashcode (id만 지정 가능) 클래스 단위에서 getter를 붙이는 게 setter를 주는 것과 다를 바가 없다 → 이런 단점이 getter를 사용했을 때의 장점보다 크지 않다 콜리: 보일러 플레이트 코드 좋다 → 이득이 많은 만큼 은닉된 부분이 많다 → 디버깅에 소모되는 리소스 많다 → 리비 : 디버깅이 어렵다는 문제는 공감하지만, 보일러 플레이트 코드를 쓰지 않아도 되는 것이 좋다. Getter를 취사선택할 수 있기에 Lombok을 부정할 근거가 되지는 않는다 진짜 중요한 핵심 도메인 로직이 파악되지 않을 수 있다 제리: 보일러 플레이트 줄이기가 설득할 만한 근거가 맞나? (난 설득됨^^) ㄴ 리비: 쓰는 사람뿐만 아니라 보는 사람도 편함 콜리: 오히려 더 시간을 들일 수도 있음 → 문법에 무지한 상황에서 코드 설명 불가능 보일러 플레이트 코드이더라도 의미를 담고 싶다면 커스텀이 가능해야함 → 예측 가능한 형태로 유동적인 코드 작성이 가능한가? 잘 모르겠다. 보일러 플레이트 코드를 심지어 직접 작성하지도 않음. 제리: 코드의 컴팩트함. 불필요한 코드가 없는 게 즐겁~^^ 리비: 롬복의 러닝커브가 크지 않음 ㄴ 콜리: 같은 타입의 필드가 들어왔을 때, 순서에 의존하는 생성자 변경을 놓칠 수 있음 콜리: 가장 큰 불만? → 효용 대비 큰 비용 | getter는 setter를 생성한 바와 다름 없다 리비: 핵심 로직에 대한 가독성 향상 ㄴ 에버: 동의 제리: 뜯어 보는 게 즐겁~^^ 학습이 즐겁~^^ 콜리: 제한적인 사용 (생성자와 getter 정도) → 이럴거면 사용하지 말자 | equalsandhashcode 사용 반대 리비: 특정 기술(JPA)에 의존? ㄴ 콜리: 의존이 아니라 제리: 매번 게터 추가가 불편 ㄴ 콜리: OOP스럽다 제리: 현실적으로 지키기 불가능하다. 타협해야 하는 순간이 온다. 리비: OOP가 강화될 수록 getter 사용이 많아질 수도 있다 → 도메인의 순수성에 너무 집중하다보면 상하차로 역할이 단순화될 수 있다 제리: 객체지향 사용 이유가 우수함이라고 생각하지 않는다. 협업에 적합한 형태이기 때문이다. 롬복은 협업에 유용한데 객체지향을 유지하기 위함은 근거가 되지 않는다. 콜리: 근거에 의한 도입이 아니라, 환경에 의한 도입으로 이어질 수 있다. But 환경이 근거가 될 수 없다. 명확한 답변 원함 결론리비 : 단 하나도 설득되지 못했다. 각각의 장단은 있지만 롬복 자체를 사용하지 않을 이유가 되지는 않는다 에버 : 롬복을 계속 사용할 것 같다. 실무에서 롬복 사용하면 못믿겠지만 백엔드 크루들을 믿는다. 사용 남발만 주의한다. → Data / Value 등등 제리: record와 다를 바 없다…. 노잼…ㅜ 빌더 최고! 빌더 짱! 콜리: 롬복에 대한 불편함을 느껴봐야 됨. ㄴ 제리: 결론이 롬복 사용 금지가 아닐 것임 ㄴ 리비: 어노테이션 다 구현할 거냐? ㄴ 콜리: 핵심을 벗어난 이야기다. ㄴ 리비: 언젠가 콜리도 롬복에 익숙해질 것이다. ㄴ 콜리: 너무 익숙해질 수 있다. 오용을 인지하지 못할 수 있다. |
Beta Was this translation helpful? Give feedback.
-
롬복은 편하다. 그렇다면 왜 롬복을 쓰지 말라고 하셨던 걸까? 단지 OOP를 위해서일까?
롬복의 단점을 알아보고 이야기 나눠보자
Beta Was this translation helpful? Give feedback.
All reactions