우아한 테크코스) Lv4 [팀 프로젝트] 정리, 후기

Lv4 : 팀 프로젝트

-> https://github.com/eattogether/hey-together
-> 팀 위키

---

요구사항

• 지속적 통합 (모든 테스트 통과할때만 배포, 테스트 커버리지 80%, 품질 기준 통과(정적 분석 도구 이용))을 적용해 일정 기준이 넘는 환경으로 배포
• Spring Rest Docs를 이용해 API 문서화
• 프론트는 프레임워크를 사용하기보다 바닐라 JS 기반으로 개발하는게 어떨까?
• 인증은 OAuth2를 기반으로 하면 어떨까? 단 Spring Security 사용X
• 인증을 제외하고 최소 하나 이상의 외부 API와 연동
• 성능을 높이기 위해 자주 사용하지(변하지) 않는 데이터에 대해 (백엔드 부분에) Cache를 적용
• REST 원칙을 지키며 개발 (참고링크)
• Docker 경험
• 기능 구현보다 전체적인 프로세스를 경험해보자. 팀끼리 규칙을 정하고. CI 경험 등

팀 문화

• 이전 레벨2 프로젝트 때와 다른건, 모닝 데일리 미팅 뿐만 아니라 이브닝 데일리도 진행해봤다. 안그래도 기능구현만으로 부족한 시간이라 걱정이 되긴했지만, 지나고보니 꽤 괜찮았다. 모닝 데일리는 가볍게 오늘 뭐할지 계획 정도, 이브닝은 각종 코드와 설계 관련 논의 등 실질적인 기능을 했다.

개발 문화

• 이슈번호를 커밋 메시지 앞에 작성해, 이슈 추적을 좀더 쉽게 할 수 있었다.
• 레벨2때 못써봐서 아쉬웠던 ZenHub을 이번엔 써봤고, 이슈들을 에픽 단위로 묶으니 관리하기 더 좋았다 :)
• 세부 개발 컨벤션 : 다들 레벨2때 나와 비슷한 점을 느꼈는지, 최대한 컨벤션을 세부적으로 정하려 다들 노력했다.

---

팀 목표

다들 계속 해왔던 스프링 서버 기능 구현 외에, 부가적으로 경험해보고 싶은 목표들로 위와 같이 리스팅했다.
하지만 프로젝트 진척이 더뎌지며 이들 중 실제로 사용해본 것은 절반정도, 그것도 제대로 써봤다고 하려면 목표의 20%도 안되는 것 같아 아쉬움이 있다.

프로젝트에서 개인적인 목표

• 인프라 기술 경험해보기 (실패)

  • 프로젝트를 맨 처음 시작할 때, 내 욕심은 그저 도커와 젠킨스를 경험해보는 것이었다. 코스동안 이제까진 인프라보다 거의 코드쪽을 만져왔기 때문에.
  • 결과적으로 이번에도 인프라 기술을 경험해보진 못했다. 표면적인 이유는 당시 개인 역할 분배할 때, 내가 페어와 함께 도메인쪽을 한창 하고있어서 다른 팀원이 인프라 역할을 가져갔다.
  • 좀더 원론적으론, 프로젝트 전반적으로 계획 수립과 진행을 제대로 하지 못했고, 때문에 필수 기능을 구현하는 것만으로 시간이 지연되어 인프라 등의 부가 기술을 적용할 시간이 부족했다. 이와 관련해선 뒤에서 다시 기술.

• 기술 문서 공유 활발히 하기 (성공)

  • 이 부분은 레벨2 프로젝트때에 비해 좀더 만족스럽다. 초반부터 적극적으로 기술 문서를 작성하자고 어필했고, 먼저 작성해서 위키에 공유하니 다들 감사하게도 따라주시더라.
  • 결국 기술 문서를 공유하는 이유는, 남이 긴 시간을 들여 학습한 내용을 다른 사람은 좀더 빠른 시간에 흡수하기 위함이다. 프로젝트 기간이 좀더 충분했다면, 기술 문서 공유 뿐 아니라 '매일 코드리뷰 or Merge'하며 서로 구두로 이야기하는 시간이 더 많았으면 하는 아쉬움이 있긴하다.

그래서 경험한건?

구현하며 인상깊었던 부분들 + 삽질

인수테스트 디렉토리 분리 위키

• foo (커스텀 테스트 디렉토리)를 생성했다면 gradle.build에서 fooImplementation으로 dependency 추가 가능하다. <- 처음알았을때 컬쳐쇼크였다, testImplementation의 test가 그 test였다니..
• 의존성 주입을 깔끔하게 못했다. gradle 문법도 알아야하는듯..

Spring Rest Docs 위키 블로그

• 인수테스트 디렉토리 분리와 함께, 첫 주차에 다른 조들 사이에서 가장 먼저 적용하고 이를 기술문서로 공유해, 다른 팀들에게 도움을 줄 수 있어 좋았다.
• Spring MVC + WebTestClient 조합에서 bindToApplicationContext() or bindToServer()의 이슈가 발생했다.
  • 여전히 의문. bindToApplicationContext()가 안되야하는데 왜 됬던 걸까 ?_?

ATDD와 섣부른 관계 매핑 & 복잡한 도메인 블로그

• 문제점 1. 가장 크고 복잡한 도메인 Article을 가장 먼저 구현하려 했던 점
• 문제점 2. Article과 관련한 엔티티들을 너무 빨리 관계매핑하려했던 점

@OneToMany List<?> 상황에서 LazyInitializationException 예외와 해결방안 블로그

• OSIV 설정을 꺼놔서 터진것이었다. 다시 스프링부트 기본값인 true로 바꿔 해결할수있었고, 추가로 OSIV를 꺼도 문제가 발생하지않도록 DTO를 사용해 노출하기로 결정했다.

JPA 양방향 순환참조 문제 블로그

• 당시엔 Json관련 어노테이션을 붙여 순환참조를 끊어 문제를 해결했다가, 이후 DTO를 사용하는 방식으로 변경해 애초의 원인 해결.

OneToMany와 양방향 남용 블로그

• 도메인 관계매핑의 복잡성과 함께 프로젝트를 지연시켰던 주된 이슈들 중 다수는 일대다 관계와 양방향에서 비롯된 경우가 많았다. 프로젝트 중반을 넘긴 시점에 이들을 모두 해제하고 구조를 변경했더니, 이후로 이슈가 줄어들었고 코드도 깔끔해질 수 있었다.
• 쓰지말라는건 왜 쓰지말아야하는지, best practice가 왜 존재하는지 몸으로 느낄 수 있었다.;;

---

정리 : 그래서 우리는 왜 실패했는가?

• 팀원들의 개인사정으로 인한 초반 부재
  • 초반에 각자 개인사로 너무 많이 (돌아가며) 빠졌다. (사실상 5주중에서 2주가 날아가버렸다) 아쉽지만 어쩔수없었던 것 같다.
• 특정 기능에 대해 한 사람이 담당했던 것
  • 프론트를 한사람에게 맡겼더니, 그 사람에게 일이 생겨 작업이 지연될 때 다른사람이 대체하기 어려웠다.
  • 다음엔 한 부분에 최소한 2명이상 분배해, 백업 멤버를 두자.
• 핵심 도메인 모델 구축의 지연
  • ATDD와 익숙하지 않은 점 + JPA 관계매핑의 복잡도로, 가장 핵심이 되는 도메인 모델들이 삽질과 변경을 계속하다 뒤늦게 정착됬다.
  • 핵심이 되는 부분인 만큼, 다들 각자 역할이 있어도 이를 우선순위로 올리고 초반에 다함께 해결했어야 했다.
• 불분명한 요구사항 확립 + 마일스톤을 적절히 세우지 못했다
  • 처음에 개발주제와 세부 요구사항에 대한 이야기를 충분히 하지 못했다. 이를 문서화하지도 못했다. -> 레벨2 프로젝트때와 비교해, 애초에 주제가 불분명해 충분한 이야기를 나눠야 했었음
  • 초반에 팀원들이 모이지 못한것과 관련
  • 그리고 애초에 짧은 기간에 과한 목표를 잡았다. 기본 서비스 기능 구현 외에, 팀원들의 목표였던 비기능 기술들까지 다루려면, 처음써보는 뷰는 포기해야했음. 차라리 슬랙봇 프로젝트처럼.
• 의욕 불충분
  • 취업과 프로젝트 지속성X으로 팀원들의 사기 저하
  • 개인에게 있어서 프로젝트의 우선순위가 밀렸다 -> 규율 위의 자율이 필요했음, 리더의 부재로 각자의 책임이 불분명

기타 : 사소한 것들

• 인텔리제이 문제로 커스텀 테스트 디렉토리를 인식하지못해, mark as로 명시적으로 테스트 폴더로 바꿔줘야 했다.
• 공식 Docs가 시키는대로 하자. 다른 경로가 아닌 src/docs/asciidoc/example.adoc의 경로에 adoc 파일을 생성해야한다.
• 블로그 : TIL - JPA 'GenerationType.AUTO'와 Mockito 등
• 회고의 중요성 : 프로젝트가 끝날 즈음, 최종 회고를 했다. 서로 마음을 털어놓고 감정을 공유하며, 서로를 좀더 이해할 수 있었다. 속도 시원했다.

팀 차원에서 새롭게 도입해본 기술들

• 인수테스트 디렉토리 분리
• Spring Rest Docs
• JWT 인증
• Vue.js

우리도 도입해볼만했던 다른 팀의 기술 및 정책

• AOP 로깅
• 프로젝트 모듈화
• SonarQube
• 로젠트리, https://docs.sentry.io/
• DbUnit