토이프로젝트 시작..
- 바로 직전 프로젝트인 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로 형상 관리했다.
- 컨트롤, 서비스, 레포지토리로 이어지는 레이어를 느슨하게 결합했다.
나빴던 점
- 기간이 정해진 프로젝트라도, 실력이나 열정의 크기에 따라 기간이 크게 왔다갔다 하는 걸 느꼈다.
- 모르는 사람들과의 프로젝트는 나에게 독이란 걸 깨달았다.
- 이 팀원들과의 프로젝트 경험은
악몽이었다...
- 단위 기간 내 개발 해야 하는 요구사항이 지켜진 적이 없다.
개선 해야할 점
- 협업 프로세스 정립
- 컨벤션 관련 문서 제작 필요!
- 목적이 분명한 프로젝트에 참여할 것.
프로젝트 관련 정리 글
공부 한 것을 공유하는 블로그입니다.