본문 바로가기
프로젝트/DailycluB

[회고] Pre Project를 마치고

by 넬준 2022. 9. 10.

 드디어 Main Project 들어가기 전에 진행한 Pre Project가 끝났다.

 

 전반적으로 재밌게 진행했다.

 

 프로젝트 초반에는 머릿속에 그림이 그려지지 않아서 헤매기도 하고 고민도 많았다. 하지만 점점 진행하면서 정리가 되어 팀원들과 같은 그림을 공유하면서 프로젝트를 진행할 수 있어서 프로젝트의 재미를 느낄 수 있었다.

 

 완성하지 못하거나, 시도도 못해본 기능들이 여럿 있지만 메인 프로젝트 때 최대한 완성도 높은 프로젝트를 만들고 싶다. 팀원들보다 한 발자국만 먼저 가면서 프로젝트를 올바른 방향으로 이끌어 보고 싶다.

 

개인 회고

좋았던 부분

  • 서버 환경 구성하면서 포트 포워딩, DMZ 설정을 경험할 수 있었고, 네트워크에 대한 전반적인 이해를 할 수 있었다.
  • AWS 배포 환경을 처음부터 끝까지 설정하면서 AWS와 배포에 대한 막연한 두려움이 없어졌다.
  • 프론트엔드 개발자와 어떤 내용으로, 어떤 방식으로 소통해야 하는지 조금은 알 수 있었다.
  • 쿠키/세션을 이용한 로그인 구현에는 실패했지만, 덕분에 깊은 학습을 할 수 있었다.

아쉬웠던 부분

  • 학습했던 Rest Docs를 활용해야 한다는 생각에 다른 대안을 크게 고민하지 않았다. Rest Docs를 작성하면서 MockBean을 활용한 Slice Test에 익숙해질 수 있었다. 하지만 그러다 보니 초반에 API 문서를 작성하는데 시간이 많이 들었다. 그리고 프로젝트 중간에 바뀌는 API 스펙을 곧바로 업데이트 하기가 부담스러웠다. 그러다 보니 자꾸 우선순위가 밀리게 되고, API 문서가 업데이트 되지 않아서 프론트엔드와 이중, 삼중으로 의사소통할 수 밖에 없었다.
  • 로컬 환경에서 테스트 서버 구성이 막막해 미루다가 프로젝트 후반에 오픈했다. 그래서 프론트엔드 분들이 그 전까지 API 통신하는데 어려움이 있었다.
  • 결국 로그인 구현을 완성하지 못했다.
  • 유효성 검사, 예외 처리 등 완성하지 못한 기능들이 있다.
  • Java, Spring, JPA와 같은 기술적인 부분과 DB, 네트워크와 같은 CS 부분에서 헷갈리거나 완벽하게 이해하지 못한 개념들이 있었다.

개선할 부분

  • Swagger로 API 문서를 작성할 생각이다. API 작성하기가 훨씬 수월하다는 피드백을 듣고서 이번엔 Swagger로 변경 사항을 바로 업데이트하여 프론트엔드 / 백엔드 의사소통에 어려움이 없도록 한다.
  • 시간을 쪼개 기능 구현 중 필요한 개념에 대해 학습하는 시간을 좀 더 가질 생각이다.
  • 에러 핸들링 등과 같은 기록을 Main Project 부터는 남길 생각이다.
  • 인증/인가에 관해 좀 더 공부하여 Spring Security를 적용할 생각이다.

 

팀 회고

1. 분석/설계

- 요구 사항 정의서, 화면 정의서, 테이블 명세서, api 명세서

 

아쉬웠던 부분

  • 화면 정의서를 구체적으로 작성하지 않아서 화면 동작에 대한 생각이 조금씩 달랐다.
  • API 업데이트 변경 사항을 문서에 즉각적으로 반영하지 못했다.
  • API 스펙을 구체적으로 정하지 않아서 2중, 3중으로 의사소통이 진행되었다.

개선할 부분

  • 화면 정의서를 작성할 때, 모든 페이지에서 필요한 정보와 동작에 대한 설명을 자세하게 작성한다.
  • API 명세서 작성 시, 구체적으로 스펙을 정하고, 변경 사항 있을 시 곧바로 업데이트 후 공유한다.

 

2. 구현(개발)

아쉬웠던 부분

  • Git Branch 전략 - fork 해서 하다 보니 개인 repo를 작업 브랜치처럼 사용했다.
  • 코드 리뷰 과정이 부족했다.
  • 테스트 서버를 이용할 수 있는 기간이 짧았다. (프로젝트 후반)
  • 일정 관리
  • 이슈 / 칸반 보드를 더 적극적으로 활용하지 못했다. - to do list 정도로만 사용했다.
  • Commit 메시지, Branch 네이밍을 통일성 있게 유지하지 못했다.

개선할 부분

  • Git Branch 전략 : fork 하지 않고 메인 repository에서 진행, 브랜치는 개인 혹은 기능 별로 생성한다.
  • 코드 리뷰 : 프론트엔드 / 백엔드 각자 나눠서 진행한 후 merge 한다.
  • 프로젝트 초반부터 테스트 서버 환경을 유지한다. (AWS, 로컬 서버)
  • 일정 관리 : 기능 별로 기간을 정해 좀 더 세부적으로 일정을 관리한다.
  • 라벨, 마일즈 스톤 등을 사용해 좀 더 프로젝트를 tracking 하는 데 적극적으로 사용한다.

 

백엔드 회고

1. API 문서 작업

→ Rest Docs로 작업을 하니 속도가 느렸고, 변경 사항을 반영하려면 테스트 코드를 또 작성해야 해서 반영하기가 어려웠다. → 초반에 API 문서 작성에 시간을 많이 쓰게 되었다.

개선 : Rest Docs → Swagger로 문서화 작업 진행

 

2. API 스펙

→ 요청 / 응답 API 스펙을 정할 때 구체적으로 정하지 않아서 비효율적이었다.

→ 초반에 로그인을 염두에 두지 않고 API 스펙을 정했다.

개선 : 화면 정의서 작성 시 구체적으로 API 스펙 정하기
          초반부터 로그인 고려하기

 

3. 로그인 구현을 완성하지 못함 + OAuth

→ 쿠키/세션으로만 진행했는데 여러 이슈로 마무리 하지 못함

개선 : JWT 방식으로 적용 + 더 나아가 Spring Security 학습 후 적용 + OAuth 학습 후 적용

 

4. 테스트 코드 작성 필요

 

5. 유효성 검사 적용 x

→ 회원가입, 로그인, 글 작성 등등 다양한 상황에서의 유효성 검사를 진행하지 않음

개선 : 적용해보기!

 

6. 예외 처리 x

→ 예외 처리를 구체적으로 진행하지 않음

개선 : AOP를 이용해 예외 공통 처리하기

 

7. 삭제 이슈

→ 단방향 연관 관계일 때, 삭제 시 foreign key 가지고 있는 엔티티 삭제 진행 필요하다. (CASCADE REMOVE 보통 양방향 연관 관계일 때만 적용이 됨)

개선 : 양방향 연관 관계, CACADE 관련 개념 보충 + 삭제 로직 보강 필요

 

8. ID 자료형 Long/long 혼용함

개선 : 어떤 경우에 Long/long을 써야 하는지 파악 후 통일성 있게 적용하기

 

9. CI/CD

개선 : CI/CD Github Actions로 시도해보기

 

10. 더미데이터

개선 : 전체 더미 데이터 Query문 작성해서 테스트 시 데이터 입력할 필요 없게 끔 한다.

댓글