주니어 개발자로 실무 프로젝트, 토이 프로젝트를 진행할 때 고민 했던 것들을 정리해보았다.
-
도메인형과 계층형 패키지 - 계층형 구조는 클래스가 많아지면 알아보기가 너무 힘들다.
실무에서는 프로젝트가 추가될 때마다 service, controller, repository 등 추가되는 파일이 있는데 쌓여가다 보면 가독성이 정말 떨어지는 디렉토리 구조를 갖게 된다. 규모가 작은 프로젝트에서는 굳이 그럴 필요성이 없지만 규모가 커지면 내가 작업하는 부분에 모든 파일들이 모여있기 때문에 훨씬 편하다.
-
DTO 관리 패턴 - DTO 갯수가 너무 많아진다.
Product 도메인이라고 하더라도 이를 그대로 결과값으로 노출할 수 없기 때문에 API에 맞게 구성이 필요하다. 이럴 때 Product에 해당하는 DTO 파일이 많아지는데 관리 패턴을 활용하면 조금 더 깔끔하게 관리가 가능하다.
-
Logging - 지난 API 요청을 쫓아가려면 로깅이 중요하구나.
실무에서 스카우터를 보고 레드포인트를 찾아 오류를 해결한다. 실무에서 오류 로그 파일을 따로 저장조차 하지 않고있어서 log4j.xml 파일에서 직접 로그 관련한 설정을 해서 오류가 남도록 수정한 경험이 있다. 서버에 들어가서 API 로그 파일 더미를 열심히 찾다보면 참 비효율적이라는 생각이 든다.
-
ResponseEntity의 포맷화 - 응답 값이 포맷화가 잘 되어있으면 가독성이 좋고 클라이언트에서도 편리하겠다.
-
예외 처리 관리 - 예외, 오류만 보고 예측할 수 있도록하여 빠르게 대응할 수 있도록 커스텀하면 어떨까
이슈 대응은 예외 처리와 오류 메세지가 얼마나 섬세하냐에 따라 대응 속도가 달라질 것 같다. 친절한 예외, 오류 메세지를 만들자. -
JPA 연관관계 설정 - JPA 활용 시 DB의 테이블에는 FK를 걸지 않아도 괜찮을까?
-
Git 브랜치 전략 - 실무에서는 어떤 Git Branch 전략을 사용할까? 어떤 커밋 메세지 컨벤션이 있을까?
실무에서 svn을 사용하고 있다. 그런데 검증/운영을 구분 없이 사용하고 있다. 검증에는 이미 배포를 하고 svn에는 커밋을 하지 않아 검증 재기동 시 오류가 발생하기도 한다. 이런 현상이 운영에서도 일어난다면..?
-
OOP - Service와 ServiceImpl을 나누는 이유는 무엇일까? 필드주입이 아닌 생성자 주입을 사용하는 이유가 뭘까?
-
Validation - Request 객체를 검증하자
운영에서 오류를 해결하다 보면 널포인터 오류나 클라이언트에서 값이 제대로 전달되지 않아 발생하는 오류가 종종 있다. 서비스 단까지 흘러들어오기 전 spring validation으로 유효성을 검사할 수 있다. 도메인의 필드 부분에 어노테이션으로 간단하게 설정할 수 있다. 또 유효성에 대한 메세지 커스텀도 가능하다.
