본문 바로가기

생존신고 하기/위코드 프리온보딩

위코드 프리온보딩 백엔드 과정 - 회고 1주차 2회 (프레시코드)

이번 과제에서는 Api 개발, 리팩토링, QA, DevOps(라고 할것도 없지만...) 역할을 담당했다.

 

요구사항

  • Database RDBMS
  • JWT 인증방식 사용
  • 서비스 실행 시 데이터베이스 또는 In Memory 상에 유저와 상품 최소한 5개를 미리 생성
  • Request시 Header에 Authorization 키를 체크
  • Authorization 키의 값이 없거나 인증 실패시 적절한 Error Handling
  • 상품 추가/수정/삭제는 admin 권한을 가진 사용자만 이용 가능
  • 상품 조회는 하나 또는 전체목록을 조회할 수 있으며, 전체목록은 페이징 기능 존재
  • 한 페이지 당 아이템 수 5개
  • 사용자는 상품 조회만 가능
  • 관리자만 상품 추가/수정/삭제
  • 상품 관리 API 개발시 적절한 Error Handling
  • 유닛 테스트 구현

과정

원래 이번 과제는 팀이 두 그룹으로 나눠서 각각 두개의 과제를 다 하는거였는데, 다행히 한 팀이 합쳐서 하나의 과제만 하는 것으로 바꿔주셨다. 이번은 기한이 꽤나 여유롭다고 생각했었기에 많은 시도를 할 수 있었다.

 

 이전 과제의 코드를 베이스로 모듈화, Code Smell과 Technical Debt 제거 등등의 리팩토링을 한 채로 작업하기로 결정했다. 

반복되는 에러처리부분들을 독립된 에러 모듈로 재사용이 가능하도록 모듈화하였고, 더러웠던 코드 스타일, 주석등등을 전부 다듬었다. 모듈들의 Responsibility를 최대한 줄이고 잘못 나눠진 폴더 구조들도 정리했다. 그 덕에 완벽하지는 않지만 꽤나 깔끔한 코드베이스를 얻을 수 있었던 것 같다 :D

 

 DB, API 설계가 끝나고 본격적으로 작업을 시작하면서, 저번에 제대로 못했던 페어 프로그래밍을 제대로 시도해봤다.

인원과 역할분배의 문제로 Navigator인 내가 혼자 Driver 2명과 작업하게 되었는데, 확실히 페어 프로그래밍이 서로의 단점을 줄여준다는걸 깊이 느낄 수 있었다. 내가 생각못한 에러케이스를 Driver분이 짚어주시고, 반대로 Driver분의 실수들을 내가 잡아내는? 그런 흥미로운 모습이 많이 나온듯하다.

 

다른 팀원분들은 이번에 Jest를 이용한 유닛테스트와 통합테스트도 도전해봤다. 아쉽게도 통합테스트는 완성을 못했지만, 코드만 봐도 테스트에 들인 노력이 아주....어마무시한것 같다 :O

 

 

얻게 된 것들

- 리팩토링을 하는 과정에서, 팀원분의 도움으로 DTO, DAO, Entity라는 개념을 익힐 수 있었다. 아쉽게도 이번 과제에는 적용을 못했지만, 앞으로 생각해볼만한 개념인 것 같다.

 

 

- 개발과 Doc에 도움을 주는 라이브러리와 기능들...

Postman의 Documentation기능이나 prettier, sonarLint 등등의 참 재미있는 도구들을 많이 알게되었다.

Postman Documentation

아쉬움

- 이번엔 저번과는 정 반대의 아쉬움이 남았는데... 욕심을 너무 많이 부려서 생각보다 훨--씬 시간이 많이들었다는 것? 

 

분명 작업 전에는 금방 끝낼 것 같았는데 예상보다 3배 이상의 시간이 든걸 보니, 프로젝트 작업기간은 자기 생각의 2.5배 이상은 둬야한다는 말이 이해가 가는 것 같다 :-(

 

- 이번에도 역시 과제의 조건이 모호한 부분이 많았다. 아무래도 이 모호한 명세 내에서 얼마나 기업의 의도를 잘 캐치하는지도 보는 듯 싶은데...그래서 Use Case위주의, Why? 를 알려주는걸 일부러 지양한 듯 싶다.

 

- CI 경험이 있어서, Jenkins까지는 아니어도 GitHub Action + SonarQube 정도는 도입을 해보고도 싶었는데, 한번에 너무 많은 욕심을 부린것 같다. 다음에 시간이 난다면 해보기로...