일주일 동안 기억에 남는 일

• 새로운 프로젝트 시작 (create101)
• Postman API document
• unit test

🔎️새로운 프로젝트 시작

이번주부터 새로운 팀들을 만나고 2주짜리 프로젝트를 시작했습니다. 저희는 class 101 clone project를 맡았고 이 사이트는 유로로 원하는 것을 수강할 수 있으면 클래스를 직접 개설할 수 있는 사이트였습니다. 1차 프로젝트와 다른 점은 client가 직접 클래스를 게시할 수 있다는 것이었습니다. 팀원들과 공통적으로 느낀 생각은 정말 기능들이 많아서 목표 설정이 중요하다고 느꼈습니다.

첫 번째 계획

• 카카오 api 로그인
• 검색 기능
  • 실시간 검색어 순위
  • 검색한 내역
• 카테고리 api
• 리스트 api
  • 카테고리 별 분류
  • 정렬
• 마이 페이지
  • 좋아요 누른 클래스 목록
  • detail page까지 들어간 클래스 목록
• creater 페이지
  • 유저가 creater로 등록
  • creater인 유저가 class 등록
• 등록된 class 펀딩(응원하기) 기능
• 이벤트 목록
• 할인 쿠폰

두 번째 프로젝트는 달라야 된다는 욕심이 조금 들어간 계획을 세웠습니다. 멘토분들이 저희 팀의 계획을 보고 기준을 다시 잡게 해주었습니다.
1. 여러 기능을 써보는 것보다 한 기능을 집중적으로 하는 것이 좋다.
2. 새로운 것을 배우는 것도 중요하지만 기존에 해왔던 로직을 보완하고 효율적으로 구현하는 과정도 중요하다.
3. unit test, 베포까지 하기 때문에 생각보다 진행이 더딜 수 있다.

두 번째 계획

• 카카오 api 로그인
• 검색 기능
  • 실시간 검색어 순위
• 카테고리 api
• 리스트 api
  • 카테고리 별 분류
  • 정렬
• 마이 페이지
  • 좋아요 누른 클래스 목록
  • detail page까지 들어간 클래스 목록
• creater
  • 유저가 class 등록
• 할인 쿠폰

• 검색 기능에서 따로 DB를 만들지 않고 단지 filter만 하는 기능으로 바꾸었습니다.
• creater를 만들면 프론트에서 웹을 하나 더 만드는 것과 같기 때문에 유저가 바로 class를 등록할 수 있는 방향으로 바꿨습니다.
• 이벤트는 빼고 할인 쿠폰도 각 클래스 마다 적용되는 쿠폰이 아닌 유저가 가진 쿠폰으로 모든 클래스에 적용가능한 방법으로 바꾸었습니다.

🔎️Postman API document

postman을 왜 쓰고 유용한지 알게되었습니다.
postman을 알았을 때 다른 분들이 아주 편리하다고 말은 해줬지만 저는 localhost에 연결해서 api를 사용하고 싶었는데 이 방법을 몰라 제대로 사용하지 못했습니다...(ubuntu에 postman을 다운받기만 하면 해결되는 문제)
postman을 다운로드하고 사용하니 이렇게 편한걸 지금 알았나 싶을 정도로 지금은 자주 사용하고 body, path parameter, query parameter를 자유롭게 사용하고 있습니다.
api를 문서화할 수 있는 큰 장점이 있습니다.
문서화하는 방법을 몰랐을 때는 프론트 분들과 api를 연결할 때 json 형식을 맞추기 위해서 직접 찾아가서 얘기하거나 trello에 json 형식을 공유하는 리스트를 만들었습니다. postman api document 작성하는 방법을 배우고 api document의 링크를 공유하여 엔드포인트, json 형식, parameter값을 공유할 수 있었습니다.
create101 API Document

🔎️Unit Test

내가 작성한코드의 가장 작은 단위인 함수를 테스트하는 메소드

지금까지 프로젝트를 진행하는 과정은 models -> views -> urls 순서로 작성했습니다. 이 과정에서 내가 구현한 코드가 잘 작동하는지 테스트 해볼 때는 크롬브라우저에 직접 실행해서 결과를 확인하거나 postman을 통한 테스트를 했습니다.(Integration test)
하지만 이러한 방법은 엔드포인트가 여러개를 test할 때 여러 번 직접 실행하면서 확인해야 하기 때문에 엔드포인트가 많아질 수록 시간이 많이 소요되는 단점이 있습니다.
이러한 방법을 개선하기 위해 코드를 위한 테스트 코드를 작성하는 방법을 알아보겠습니다.
unit test는 엔드포인트 여러개를 테스트하는 코드를 작성하는 것 입니다. 코드를 작성할 때 시간소요가 생기겠지만 장기적으로 봤을 때 작성해놓고 test하는 방법이 효율적인 방법이라고 생각합니다.
지금까지 작성한 프로젝트에 unittest를 추가하면서 고민이었던 부분은 unit을 어떻게 나누어야 되는지에 대한 부분이었습니다.
예를 들어 상품 리스트 api를 구현했을 때 이 api에는 여러가지 기능들이 있습니다.

• 모든 리스트 반환
• 카테고리 별 리스트 반환
• 정렬 후 반환
• pagination(페이지 단위로 반환)
  이 기능들은 모두 한 view에 작성되기 때문에 test 함수를 하나만 작성하면 되는 줄 알았습니다.
  이런 상황일 때는 view 하나당 test class를 작성하고 내부에 독립적인 로직별로 test 함수를 작성하면 되었습니다.

class ListViewTest(TestCase):
	def setUp(self):
    	# ...
    	def tearDown(self):
    	# ...
        
    	def test_list_by_category_success(self):
    
    	def test_list_by_category_invalid_value(self):
    
        def test_list_by_sub_category_invalid_value(self):

        def test_sorted_list_success(self):

        def test_sorted_list_invalid_value(self):

        def test_pagination_success(self):

정확한 방법은 아니지만 위 처럼 성공할 때만 test하는 것이 아닌 error가 나거나 예외가 있을 경우에도 test하는 함수를 구현해주어야 합니다.

🤔️회고

포트폴리오를 위한 개발 -> 나를 위한 개발

1차 프로젝트도 해봤으니 이번엔 새로운 기능들을 구현해보고 전보다 화려한 프로젝트를 완성해야지!

라는 생각으로 1주일을 시작했지만 그렇게 좋은 목표는 아니었던 것 같습니다. 아직 배운 내용들도 정리가 확실히 안되있고 단순히 로직 구현과 화려하고 많은 기능들을 목표로 했을 땐 내가 사용하는 코드에 확실한 이해도 되어 있지 않고 보다 효율적인 방법을 찾을 수 없기 때문입니다.
아직 프로젝트 베포, unittest, postman API document 등 배워야 하는 내용들이 많기 때문에 구현에 너무 성급하지 않고 배운 내용들을 내것으로 만드는데 충분한 시간을 갖는 것이 중요할 것 같습니다.
2차 스프린트 때는 내가 앞으로 배울 내용들을 단순히 사용했다에 멈추지 않고 더 괜찮은 방법은 없을까 고민하는 시간을 갖고 정리하면서 프로젝트를 성공적으로 마무리하는 것이 목표입니다.

지금 구현한 기능들을 보안하고 배운 내용들은 정리하자!