[WIL] 프리온보딩 두번째 과제 회고록 - 페이히어

두번째 과제는 페이히어의 과제였습니다.

과제 내용 

소비내역을 기록/관리하는 가계부를 만드는 과제였습니다. 

요구사항은 디테일하게 주어졌으며 기본적인 CRUD와 회원가입이 필요한 내용이었습니다.

• 1 . 고객은 이메일과 비밀번호 입력을 통해서 회원 가입을 할 수 있습니다.
  • 회원 가입 기능 : 이메일과 비밀번호를
  • Custom user model setting 필요 기존 username으로 되어있음
• 1. 고객은 회원 가입이후, 로그인과 로그아웃을 할 수 있습니다.
  • 로그인 로그아웃 기능
  • simple jwt이용하여 토큰 사용
• 1. 고객은 로그인 이후 가계부 관련 아래의 행동을 할 수 있습니다.
  a. 가계부에 오늘 사용한 돈의 금액과 관련된 메모를 남길 수 있습니다.
  • C
  b. 가계부에서 수정을 원하는 내역은 금액과 메모를 수정 할 수 있습니다.
  • U
  c. 가계부에서 삭제를 원하는 내역은 삭제 할 수 있습니다.
  • D → U : 삭제내용은 삭제된것으로 생각한다는 필드를 사용해야 함 (ex: is_active)
  d. 삭제한 내역은 언제든지 다시 복구 할 수 있어야 한다.
  • c 항목의 필드를 이용하여 복구 할 수 있게 구성
  • 삭제된 목록을 볼 수 있는 조회 기능을 만들고 이를 이용하여 복구를 생각 R
  e. 가계부에서 이제까지 기록한 가계부 리스트를 볼 수 있습니다.
  • R : ~lists/
  f. 가계부에서 상세한 세부 내역을 볼 수 있습니다.
  • R
  • url 분기를 할때 list/<id>
• 1. 로그인하지 않은 고객은 가계부 내역에 대한 접근 제한 처리가 되어야 합니다.
  • 장고 permission classes 사용
  • 로그인한 고객과 어드민 유저만 접근 가능하게 만드는 것과 같이 custom permission과 관련된 변주를 생각해 볼 수 있음

구현

• Docker 이용하여 배포
• DDL파일 소스 디렉토리 안에 넣을 것
• 테스트 케이스 작성
• lint와 formatting 맞출것 → 상의 필요
• 요구사항 없는 것은 자체적으로 판단해서 개발
• 토큰 사용 → simple jwt 사용 계획
• 프론트 불필요

 

** 여기에서 테스트 케이스 작성을 맡게 되었습니다.

진행 과정 

첫 번째 과제를 이미 한차례 같이 수행하였으나 lint와 formatter를 제대로 구성해놓지 않고 시작하였었기에 두 번째 과제에서는 해당 내용에 더욱 신경 썼습니다. 해당 내용은 구현 내용에 대 명시되어있는 내용이어서 어떤 기능들을 넣을지 상의해서 구성하였는데 해당 업무를 맡은 팀원분이 아주 멋지고 빠르게 구성하고 git에 내용을 올려주셔서 초기 세팅을 빠르게 끝내면서 시작하게 되었습니다.

 

기본적으로 보통의 로그인 기능 이외에 jwt 토큰을 사용하는 방식이었기 때문에 simple jwt 패키지를 받아와서 사용하는 방식으로 구성되게 되었고 해당 내용은 로그인을 할 때 access token과 refresh token을 요청해서 사용하는 방식으로 구성하게 되었으며 api는 명세표에 맞춰서 구성하게 되었습니다. 이 명세표 내용은 초기에 큰 틀을 잡아서 거의 초반 기획대로 구성하였지만 soft delete기능을 구현하면서 일부 url구조 변경이 있었습니다.

도커로 배포하는 내용에서는 AWS EC2 환경에서 서버를 올리는 것부터 시작해서 배포를 하고 이렇게 배포된 서버 위에서 Swager까지 돌아가게 설정을 하였습니다. 해당 내용에서는 static 파일을 도커로 올린 서버에서 찾지 못해서 문제가 되었었는데 이것을 팀원들이 포기하지 않고 해결하는 것을 확인하였습니다.

 

배포 관련 경험은 몇번있지만 Docker를 새로 학습해서 진행하는 팀원분의 모습에 감탄했으며 다음에 배포를 맡게 되었을 때 조언을 구할 수 있지 않을까 하는 생각을 하고 있습니다.

 

마지막으로 제가 수행한 업무에 관해서 기술하자면 TDD작업 방식을 따라서 먼저 테스트 케이스를 만들어놓고 작업을 시작할 수 있게 선행작업을 하려 하였지만 API 구조가 어떻게 될지 뭔가 아무것도 없는 백지에 적으려고 하니 손이 움직이지 않는 그런 경험을 하게 되었습니다. 테스트 케이스 작성 또한 익숙하지 않은 업무이기 때문에 더더욱 그랬던 것 같고 이렇게 여러 학습자료를 보면서 학습을 하면서 시간을 소비하여 결과적으로 선행된 테스트 케이스를 만들고 이를 통과하기 위한 서비스를 만드는 것이 아닌 API를 보고 해당 API를 요청하고 응답 값을 확인하는 형식의 TESTCASE만을 작성하게 되어 많은 아쉬움을 남기게 되었습니다. 그리고 테스트의 방식 중 pytest가 유용한 것으로 이야기를 들어서 해당 기능을 사용해보기 위해서 패키지를 설치하고 관련 자료를 많이 찾아보았지만 이 또한 결과적으로 pytest.ini 파일을 이용한 pytest 커맨드를 이용한 것을 제외한 다른 기능을 제대로 써보지 못하고 기본적인  unittest만 작성하게 되어서 아쉬운 점이 많이 남았습니다.

 

향후 프로젝트 또는 개인프로젝트에서 TDD 작업 방식을 제대로 모방하여 프로젝트를 실행해보고 싶은 마음이 생겼으며 업무 배정 때 업무를 잘게 쪼개고 해당 내용에 대한 testcase를 담당자가 짜고 나서 api 기능 구현을 하면 좋지 않을까 하는 고민을 하게 되는 시간이었습니다.

배운 점 / 아쉬운 점 

배운점과 아쉬운 점은 진행과정에 엮어서 작성되어있어서 위 내용으로 가름하겠습니다.

 

 

과제를 완료한 소감 😁

2번째 과제 수행 소감에 대해서 말해보자면 다른 팀원들의 팀 업무 진행에 대해서는 정말 군더더기 없이 잘 소통되면서 구현 과제를 잘 수행하였다고 자축할 수 있지만 개인적인 업무수행에 대해서는 한마디로 "아쉬웠다."라고 표현할 수 있습니다.

처음 생각했던 pytest를 이용한 구현 + 해당 내용을 문서화, 그리고 TDD 방식처럼 testcase가 선행되고 api 구현을 이것에 맞춰서 하는 방식까지 이상적이고 이번 프로젝트에 적용해보고 싶었던 내용들을 전부 제대로 수행하지 못한 점에 큰 아쉬움을 느꼈으며 차후에라도 pytest 관련하여 추가 학습해서 다른 프로젝트에 적용해보고 싶은 마음입니다.

그리고 처음 잡을 배정받았을때 위의 이유로 한 가지 잡만을 받고도 묵묵히 수행했던 점이 있었는데 제대로 생각한 대로 작업이 진행되지 않으면서 업무의 범위가 너무 좁았던 것이 아닌가 하는 회고도 하였습니다.

 

그리고 추가적으로 TDD 작업 방식을 제대로 경험 해보고 싶은 생각이 듭니다.

 

 

결과물 💾

GIT 저장소

https://github.com/pre-onboarding-3rd-team-H/02_Payhere_TeamH

GitHub - pre-onboarding-3rd-team-H/02_Payhere_TeamH: 페이히어 기업과제 레포지토리입니다. 가계부를 생성하

 

과제 설명 노션

 

https://www.notion.so/fa0128e74291482fb103695f735f1d0a

페이히어 과제 페이지