[django] 2nd sprint - review

🖥 1차 프로젝트 진행하면서 받은 피드백 정리

1차 프로젝트: fruitz_company
scope: 회원조회/pagination views.py

1-1
pull request는 항상 한 가지 기능만 포함
한 가지 기능이란 = 하나의 함수 (def post 1개, def get 1개 등등)
만약 get/post/delete 등을 한번에 해서 올리면, get은 ok했는데 post 쪽 코드가 이상하면 get은 다 완성이 됐는데도 계속 ok 안된 상태로 머물러 있어야
이렇게 해야만 코딩 리뷰 - 머지 과정의 생산성이 올라감

1-2
git conflict
git은 기본적으로 변경사항을 추적하는데, 그것을 위치로 파악한다
만약 하나의 클래스에 대해 get이 구현된 PR과 post가 구현된 PR을 올리면 반드시 conflict가 나게 되어 있음
-> 내가 feature/users-view를 작성하는 동안 다른 동기의 코드가 새롭게 main에 merge되어 PR 올렸더니 conflict 발생
-> main 브랜치로 옮겨서 먼저 git pull origin main
-> feature/users-view로 이동
-> git merge main, 그럼 conflict에 대한 메세지가 다시 뜸
-> code를 열어서 해당 내용 중 최신 버전(main 내용)으로 선택하고 나머지는 삭제함
-> git status, git diff로 변경사항 확인
-> git add, commit 진행 후 push origin 진행

최신 main을 pull받고 users-view 브랜치로 다시 이동하는 과정

conflict 해결 후 병합

2
git diff를 통해 항상 확인하고 PR 올릴 것
더 중요한 것은 내가 무엇을 수정했는가를 확인해서 PR 올려야 한다는 것 !

3
엔드포인트
프론트가 사용자에게 보여주는 url과 서버가 프론트에 보내는 url이 다르다.
서버가 보낼 때는, url을 항상 리소스 기준으로 정의 내린다
회원정보페이지라 치면, mypage -> users 로 바꿔야 함

4
모델링이 바뀌면 항상 migration을 해야 한다
column이 바뀌면 항상 migrate를 해줘야 에러가 발생하지 않고, 만약 발생했을 경우 통상적으로는 main에 있는 migration 파일을 펼쳐놓고 최신것부터 0001버전까지 타고 올라가서 수정해야 한다. (이런 경우에도 기존 데이터베이스를 같이 비교해가며 해야.. 이 과정이 매우 까다로움. 그리고 db 상에서도 django_migration을 통해 모든 버전을 기록하고 있음. 여러가지 이유로 일반적으로 주니어들한테 데이터베이스 관련해서 작업시키지 않음)

5
쿼리파라미터 에러
프론트로부터 category_id와 page_id 둘 다 받아야 한다고 할 때, page_id가 입력되어 있지 않아 발생하는 에러는 처리를 따로 하지 않음.
-> 프론트에서 무조건 양식대로 전달해줘야 하는 것이라 서버에서 고려해야 할 case가 아님

6
pagination할 때는 offset/limit 사용
만약 처음에 내가 아예 10개 이런식으로 잡아서 그 넘버를 받는 식으로 하면, 한 페이지에 10개가 아니라 개수를 다르게 받고 싶도록 변경할 때 변경하기 어려운 문제가 생김.
유동성을 위해서, offset/limit으로 써야 한다.
관련 library가 있긴 함 (하지만 사용하는 것은 현재 단계에서 비추)

offset은 시작점이고, Limit은 끝나는 지점
사용자 입장에서 생각해보면, 자동으로 1~50, 1~100까지 설정되어 보여지는 것을 알 수 있다. 그리고 2페이지로 넘어가면 51~100, 101~200 이런 식으로.
즉, slicing을 해줄 때 [offset:offset+limit]을 해야 위와 같이 정상 작동한다. 그리고 limit은 상수로 설정 (10개씩 보여줄거면 10).

만약 [offset:limit]으로 해버리면, 2페이지로 넘어갔을 때 51~100 이렇게 되는게 아니라 51~10이 되어 버린다.