Lombok에서 지원하는 @Builder를 사용하다보면, 필수 값을 빼먹어서 곤란했던 적이 있을 것이다. 그래서 나는 솔직히 Builder를 안티패턴 취급하며, 협업에서는 지양해야 한다고, 혼자 마음 속으로 생각하고 있었다. (필수 값을 만들 수 있다는 것을 알기 전까지...) 빌더는 어떤 상황에서 유리할까? 빌더패턴가 좋은 상황은 정말 간단하다. 생성자를 만드는데, 매개변수가 너무 많이 필요한 상황이다. public A(String name, int classNumber, String hobby, String favoriteBook, String favoriteFood, String favoritePerson){ 값 삽입... } new A("이창보", 3113, "축구", 19, "EFFECTIVE ..

주변 사람들이 언제부턴가 "생성자 쓰지마! 정적 팩토리 메서드(이하 정팩메)가 최고야!"라고 말하기 시작했다. 사실 나는 정팩메를 싫어한다. 이유는 정말 단순했다. 생성자에 굳이굳이 메서드를 한 번 더 감싸기 때문에 코드가 더 늘어나기 때문이다. 그리고 new 라는 키워드가 눈에 훨씬 잘 들어와서, 객체를 생성한다는 것을 잘 보여준다고 느껴졌다. 그러나 나도 이펙티브 자바를 읽고자 마음을 먹었고, 책을 펼치자, "생성자 대신 정적 팩터리 메서드를 고려하라" 라는 말이 눈에 들어왔다. (드디어 찾았다! 범인!) 정적 팩토리 메서드의 장단점 정적 팩토리 메서드는 장점이 많다. 장점 1. 이름을 가질 수 있다. 생성자는 넘기는 매개변수와 생성자 그 자체로는 어떤 객체가 생성될 지 판단 해야하는데 이 과정은 명..

나는 부마위키라는 부산소프트웨어마이스터고등학교의 위키 서비스를 개발하고 있다. 2021년 부마위키에서 느껴질 정도로 문제가 됐던 동시성 이슈가 있다. 동시성 이슈라고 하기엔 동시에 일어나지 않아도 되서 동시성 이슈라고 불러도 되는지 모르겠다 ㅋㅋ 문서 수정자가 문서 수정을 요청하면, DB에 저장된 현재 문서 내용을 전달하고 수정 후 내용을 저장하는 형태이다. 문서 수정자 1, 2가 같은 버전의 문서에서 수정을 시작후, 문서 수정자 1이 수정 내용을 저장하고, 문서 수정자 2가 수정 내용을 저장한다면, 문서 수정자 1이 추가 혹은 삭제한 내용을 사라지게 된다. 자신이 수정한 것을 문서 내역에서 다시 볼 수 있긴하지만, 결국 사용자의 행동을 늘리는 것이기 때문에 개발을 추가로 해야겠다고 생각했다. 나무위키는..

이번에 Java로 새로운 프로젝트를 진행하면서 코드 컨벤션을 맞추는 것에 대해서 고민을 많이 했습니다. 코드 컨벤션을 맞춰주는 도구를 Lint 혹은 Linter라고 칭하는 것을 알게 되었습니다. 코틀린은 ktlint가 국룰로 잡혀있기 때문에 린트 선정에 고민이 없지만, 자바는 국룰이 없는 것 같았습니다. 그래서 내가 어떤 Lint을 원하는가 고민을 많이 했습니다. - 린트 적용이 강제여야한다. - 린트 적용이 안되어 있는 부분이 있다면 쉽게 알려주어야한다. - 린트가 적용이 안되어 있는 부분이 있다면, 간단하게 단축키 혹은 gradle task로 수정되어야 한다. 크게 다음과 같은 세가지 요구사항이 있다는 것을 알게되었습니다. 그래서 찾아보던 중 sonarLint와 checkStyle이 있다는 것을 알게..

Repository를 사용하지 않을 것을 추천하는 하이버네이트 하이버네이트 진영은 Repository를 사용하지 않을 것을 추천합니다. 그 이유를 한 번 알아봅시다. https://docs.jboss.org/hibernate/orm/6.3/introduction/html_single/Hibernate_Introduction.html#hello-jpa 하이버네이트를 래핑하는 프레임워크는 하이버네이트가 제공하는 세밀한 데이터 제어를 못 하게 한다. JDBC와 하이버네이트는 큰 차이가 있기 때문에 하이버네이트에서 JDBC로 돌아갈 일은 없다. Repository는 스택트레이스를 더 힘들게 하고 디버깅을 힘들게 한다. 대부분의 쿼리는 여러 곳에서 재사용되지 않으므로, 비즈니스 로직에 EntityManager를 ..

최근에 구현 레이어의 역할이라는 유튜브 영상과 지속 성장 가능한 소프트웨어를 만들어가는 방법이라는 제목의 블로그를 읽었다. 두 개 모두 Gemini Kim 개발자님의 글이고, 나는 영상과 블로그를 통해서 지속 가능한 소프트웨어를 만드는 법에 대해서 좋은 인사이트를 얻을 수 있었다. Business Logic, Layer, Module을 통해서 지속 가능한 소프트웨어에 대해서 설명하셨고, Business Logic과 Layer에서 알려주신 방법을 직접 내 코드에 적용해보면서 어떤 것을 배웠고, 어떤 것을 느꼈는가에 대해서 이야기 해보고자 한다. Business Logic 리팩토링 먼저 이러한 작업을 하는 목적은 전적으로 유지 보수성 때문이라는 생각이 들었다. 그래서 유지 보수를 할 필요가 없는 소프트웨어이..