dev-meeting-study 토이프로젝트 회고글

토이프로젝트 시작..

• 바로 직전 프로젝트인 corsmarket 프로젝트에서, 프로젝트 리더를 했었다.
• 내가 프로젝트 리더로써, 부족한 점이 많다고 생각해서 괜찮은 리더와 함께하는 팀원으로써 토이프로젝트에 합류하고 싶어졌다.
• 일전에 자료구조나 알고리즘을 열심히 공부했지만 내가 원하는 교육 과정에 들어가지 못했기 때문에 실망감이 커서 멘탈적으로도 흔들렸었다.
• 그래서 오키에서 토이프로젝트 모집 글을 보고 참여했다.

참여.. 설계

• 리더가 자신이 설계한 ERD(Entity-Relationship model Diagram)나 mock design을 보여줬고, 은근히 재밌어보여 열심히 해보기로 작정했다.
• 지금에서야 생각하건데, 좀 더 확실한 목표가 있었어야 했다..!
• 4년차 PHP 개발 경력자라 많이 믿고 배워야겠다는 마음을 가졌었다.
• 리더는 프로젝트의 초반부에는 릴리즈 단계를 거치며 프로젝트를 발전 시켜나가겠다는 포부를 밝히며 애초부터 조그마한 기능부터 개발해 나갔다.
• 분명 처음에는, 스터디 모집부터 일정관리까지 할 수 있는 플랫폼 개발을 목표로 했다!
• ERD에서 미흡한 점이 있어, 여러가지 컬럼 추가 및 삭제를 진행했다
• spring security 및 Exception 정책에 대한 부분은 코드에 녹여져 있었다.
• 하지만 깃 컨벤션, 코드 컨벤션, API 문서 등에 대한 부분은 하나도 정해져 있지 않았다.
• 리더는 이런 것들이 중요하다고 생각하지 않는 모양이었다.
• 내가 열심히 주장해서 깃 컨벤션은 적용했고, API 문서는 임시로 작성하되 Swagger로 운영하기로 했다. 코드 컨벤션에 관해서는 그 때 당시에는 생각하지 못해 적용하지 못했다.

프로젝트 진행

개발 서버 통일

• 나는 docker-compose로 nginx, nodejs, springboot를 통합하여 개발 서버 컨테이너 이미지를 제공했다.
• windows와 mac OS 등 각 개발자들간의 운영체제가 서로 다르고, 네트워크 환경이 다르기 때문에 그런 불상사를 미연에 방지하기 위함이었다.
• docker-compose 관련 문서를 팀원들에게 제공하였고, 성공적으로 팀원이 사용할 수 있었다.

CORS 관련 해결

• 인증이 존재하는 Http Request 관련해서도, Single Origin Policy와 Cross-Origin Resource Sharing을 생각하며, 서버에서 관련 Response Header를 명시하고, Preflight Request에 대해 인증에 대한 요청을 허용함으로써 정상적으로 해결하였다.
• 관련 링크 : CORS 에러 해결

중도 리더 탈주

• 굉장히 화가나는 일이었지만 내가 팀원을 책임지고 끝까지 요구사항까지는 개발하기로 마음 먹었다.

클린코드 지향

• 코드 리뷰를 진행할 수 있는 팀원이 존재하지 않아서 스스로 제약을 걸어 코드를 작성하였다.
  1. 메서드는 15줄 이내로 작성할 것
  2. 각 서비스, 컨트롤러에서의 필드는 interface로 주입 받을 것
  3. 각 Entity는 분리된 하나의 도메인으로 볼 것.
  4. 모든 상태 값들은 (예를 들어 엔티티의 Status, 즉 Deletion 등) Enum으로 실수를 최소화.
  5. 메서드의 파라미터의 갯수는 2개 이내로 제한 할 것.
  

Enum Validation AOP 처리

• HTTP Request에서, 파라미터를 DTO 필드에 주입시 Enum은 따로 Validation을 제공하지 않으므로 annotation을 따로 작성해서 Validation 처리

Facade 패턴 적용

• 각 도메인을 느슨하게 결합하여 Study에 관련된 인터페이스의 모음인 StudyFacade를 작성했다.
• 어플리케이션단의 통합 트랜잭션 구성으로 스터디 생성, 스터디 수정(replace에 가깝다), 스터디 삭제 등의 인터페이스를 제공했다.

Controller에서의 return DTO

• API로 제공되는 JSON에 Entity를 그대로 사용하지 않기 위해서 DTO를 사용했고, 해당 컨트롤러에 의존적인 DTO를 생성하는 static method를 작성했다.
• 컨트롤러에서 DTO 변환 로직의 코드량을 극도로 줄일 수 있었다.

공통 Exception 처리

• 모든 Exception은 @ControllerAdvice에서 처리하여 공통 Error ResponseDTO를 JSON으로 Client에게 제공할 수 있도록 했다.

통합테스트(Controller) MockMVC로 Test 코드 작성..

• 아직 많이 미흡해서 제대로 된 테스트가 아니었지만, 사용법 정도는 익혔다...고 생각하며 더 나아가 테스트에 대해서 생각해 볼 수 있는 계기가 되었다.

좋았던 점

• 테스트 코드 작성을 해본 점..
• 개발 서버를 docker 이미지 배포에서 docker-compose로 형상 관리했다.
• 컨트롤, 서비스, 레포지토리로 이어지는 레이어를 느슨하게 결합했다.

나빴던 점

• 기간이 정해진 프로젝트라도, 실력이나 열정의 크기에 따라 기간이 크게 왔다갔다 하는 걸 느꼈다.
• 모르는 사람들과의 프로젝트는 나에게 독이란 걸 깨달았다.
• 이 팀원들과의 프로젝트 경험은 악몽이었다...
  - 단위 기간 내 개발 해야 하는 요구사항이 지켜진 적이 없다.

개선 해야할 점

• 협업 프로세스 정립
• 컨벤션 관련 문서 제작 필요!
• 목적이 분명한 프로젝트에 참여할 것.

프로젝트 관련 정리 글

• docker-compose cache 없이 빌드하기
• Querydsl 의존성 추가 후 테스트 코드 작성시 Q class에서 cannot find symbol 에러 해결 방법
• WSL, Intellij 관련 PropertySource 주입 문제
• swagger-ui NumberFormatException 해결
• WSL 캐리지 리턴 버그