글래너 프로젝트로 배운 것

JooHeon·2022년 2월 3일
0

글래너 프로젝트 노션

🖊 문제 발생 및 해결

상속 관계 엔티티 처리 및 연관되는 서비스, 컨트롤러 중복 제거

EX) 게시판에 자유게시판, 공지게시판이 있다고 가정했을 때.

엔티티 : 자유, 공지의 컬럼 중복을 제거하기 위해 게시판 엔티티를 만들고 DTYPE으로 구분했다.
컨트롤러 : 컨트롤러의 CRUD가 게시판 마다 존재하기 때문에 DTO를 제네릭으로 게시판 컨트롤러를 만들고 자유, 공지 게시판은 이를 상속받고 일부 기능을 오버라이딩으로 중복을 제거했다.
서비스 : 서비스도 마찬가지로 게시판 서비스를 만들고 자유, 공지 게시판만의 특수 로직은 서비스를 따로 상속받지 않고 만들었다.
리포지토리 : 페이지 리스트를 받아오는 중복되는 쿼리같은 경우에는 중복 제거의 방법을 찾지 못하고 각 리포지토리마다 쿼리 메소드를 만들었다.

CASCADE의 N + 1 문제

EX) A엔티티에 CASCADE.ALL로 연결된 B 리스트가 있는 상황에서 A를 삭제했을 때.

바로 밑의 포스트에 적긴 했는데, 지울 때 N + 1 문제가 생겨서 CASCADE를 PERSIST로 가져가고 삭제시에는 DELETE WHERE IN 쿼리를 작성했다.

🖊 스웨거의 필요성 실감

혼자 개발할 때는 내가 내 기능을 다 아니까 그냥 단순하게 생각했다. 프로젝트를 진행 하면서 ec2 서버에 도커 컨테이너를 빌드 배포를 완료했었다. 이 시점부터 연동 작업을 해보면서 부랴부랴 스웨거를 달았다. 컨트롤러 이름과 들어가는 파라미터의 이름을 보고 대충 무슨 기능인지는 알 수 있는 기능이 있고 그렇지 않은 기능이 있어, 프론트 선생님들이 이건 무슨 기능이냐고 많이 물어봤었다. 이래서 api 문서를 상세하게 적어둬야하구나 스웨거를 이래서 쓰는구나 실감했다.

🖊 테스트 주도 개발

처음에 테스트 설계 방법을 어떻게 가져갈지 고민을 많이 했다. 프로젝트는 1달이라는 제한 시간이 정해져있지만, 서로 경험이 없는 주니어끼리 모여있어, 변경이 매우 빈번하리라고 생각했다. 이런 상황에 정보를 찾아봤고 테스트 주도 개발 방법이 적합하다고 생각했다. 결과는 솔직히 유효했다고 생각하지는 않는다. 테스트 주도 개발 방법의 장점으로 신뢰성있는 코드를 얻고, 단점으로 개발 시간이 길어진다라고 봤었는데 도입 결과 단점만 남지 않았나 싶다. 프로젝트 시간 자체가 짧아서 프로젝트 구조자체가 복잡하지가 않았던 거 같고 그래서 그런지 장점을 체감하지 못했다.

🖊 효율적인 테스트 자동화

단위 테스트를 강조하는 글을 많이 봤었다. 그래서 나는 만든 모든 기능을 단위테스트 하고자 했는데 내가 했던 방법은 다음과 같다. 서비스 기능을 하나 만들고자 한다면,
1. 서비스 테스트 클래스를 만들고 테스트 코드를 작성한다.
2. 거기에 넣어야하는 리포지토리 메서드를 빈 객체로 생성한다.
3. 생성한 메서드의 테스트를 만든다.
4. 테스트 코드를 작성하고 메서드를 구현 후 검증한다.
5. 이 과정을 반복해서 서비스 테스트 코드를 완성한다.
6. 서비스를 검증하고 코드를 복사해서 실제 서비스 객체를 생성 후 붙여넣었다.
이게 단위 테스트인가? 난 제대로 테스트하는 게 맞나? 라는 생각이 들었다.
서비스 테스트에는 여러개의 리포지토리, 엔티티 메소드 호출로 이루어지게 되었는데
반면에 리포지토리는 실제 객체를 호출해서 검증하는 형태를 보이고 있었다.
서비스 코드와 테스트 서비스 코드는 100% 중복이었고 이렇게 해서 실제 서비스를 운용했더니 오류가 발생했었다. 뒤늦게 이거는 아닌 것 같다고 느껴서 검증을 위한 코드를 실제 객체에 넣고 테스트 코드는 서비스를 호출해서 검증만하는 방식으로 바꿨는데 아마 이게 통합테스트일 것이다. 중복이 없어서 일이 많이 줄었고 검증해보니 오류가 잡혔었다. 프로젝트가 끝나고 더 나은 테스트 방법을 찾아야겠다는 생각이 들었다.

🖊 관점의 변화

처음에는 단순하게 내가 배운 기술을 써먹어보고 싶다는 생각으로 프로젝트를 했다. 근데 점점 시간이 지나면서 이 기능엔 어떤 기술이 필요할 거 같다라는 식으로 관점이 점점 변하더라. 이게 맞는 거 같긴하다 프로젝트 시작 전에는 극단적으로 "이 기술이 쓰고싶어서 이 기능을 만들었다"고 볼 수 있으니 내가 생각해도 바뀌길 잘한 것 같다.

1개의 댓글

comment-user-thumbnail
2022년 3월 1일

안녕하세요 주현(?)님! 좋은글 작성해주셔서 감사합니다!
다름이 아니오라 제가 현재 진행을 하고 있는 프로젝트 관련해서 이렇게 연락을 남깁니다.
따로 연락을 드리고 싶은데 제가 velog는 처음이라 연락 기능을 못찾는것인지, 아님 없는건지 모르겠네요..
실례인줄은 알지만 이 글 댓글로나마 연락처를 남깁니다.
혹시 팀원이 있고 규모가 있는 프로젝트에 관심있으시다면 ymk961028@naver.com으로 연락주시면 감사하겠습니다!
(이렇게 댓글창에 남기게되어 다시한번 죄송하다는 말씀드립니다)

답글 달기