배운 점들

print의 중요성

테스트하는 동안에는, 백엔드와 프론트엔드가 서로 주고받는 데이터를 정확하게 파악할 필요성이 있었다. 시야는 경험의 범위에서 나온다고, 경험의 범위 밖의 문제를 잡기 위해선 항상 주시하고 있어야 한다. 코딩도 마찬가지. 언제든지 내가 예상치 못한 변수가 생길 수 있기 때문에, 요청 내용 혹은 응답 내용을 터미널에 찍는 습관을 들이는게 좋을듯싶다.

이 print 결과 하나로 많은 걸(전제) 빠르게 유추할 수 있다. 요청이 제대로된 URI로 왔는지, 요청에 body가 담기기는 했는지, JSON 파싱이 가능한 데이터인지, 서로 약속한 변수명으로 왔는지, 데이터의 타입이나 내용이 약속한 것과 같은지를 알 수 있다.

그리고 코드가 길어지고 로직이 복잡해지면, 내가 쓴 코드가 날 잡아먹는 상황이 생긴다. 그걸 방지하고 흐름을 파악하려면 print는 필수.

이번 프로젝트에선 print를 300번정도 쓴 것 같다.

하나의 함수는 하나의 기능만

응답의 결과가 조건부로 달라진다면, 함수를 분리하는게 맞다.
POST방식인 함수에서, 경우에 따라 데이터를 생성하는 것이 아닌 수정을 해야 한다면, 아예 프론트쪽에서 조건부로 PATCH 요청을 따로 하고, 서버는 그에 맞게 응답해야 한다.

테이블별로 앱 분리.

위의 코드는 잘못된 방식이라고 생각한다.
RESTful API를 생각할 때, 테이블별로 앱을 쪼개는 것이 맞다. 모든 걸 하나의 앱으로 만든다면 처음에는 편할지 몰라도, 사이트가 커진다면 그런 앱 구조로는 RESTful API방식을 해칠 수 밖에 없다. Food 정보만 원하는데 URI는 restaurants로 시작하면 말이 안되지.

migration을 생각할 때에도 마찬가지. 한 테이블의 모델을 수정하는데, 다른 migration파일들까지 영향을 받을 수 있으니까.

MSA(microservice architecture). 테이블별로 앱을 쪼개게 되면 많은 사람이 일할 때 수월해진다고 한다.

파일이 나눠져있으니까 보기 편하다.

기능별 git branch 관리의 의미

branch를 기능별로 굳이 관리해야 하나?라는 생각을 많이 했다. 그리고 이유를 알게 됐다.
1. 문제 파악. 모든 코드를 merge했을 때의 코드에서 문제가 생긴다면, 그 문제가 어디에서 생겼는지, 즉 어떤 사람이 어떤 코드를 썼는지를 용이하게 알 수 있다.
2. 소통. 코드에 대해서 어떤 생각을 하는지 서로 생각을 주고받을 수 있다. 지금은 멘토님들만 코멘트를 달지만 나도 언젠가 남의 코드에 내 생각을 쓰겠지.

Meta class와 unique_together

한 쌍이 유일하도록 만드는 Model Field속성. (ForeignKey였나?)

Model을 떠나서, Meta 개념이 궁금해진다. 인스턴스의 스케일이 커지다보면 자주 볼 것 같다. 그리고 새삼 Class 개념을 이용해서 Model을 만드는 django 스타일이 맘에 든다. 틀을 짠다는 면에서 같으니까. 청사진?

class method

Class 자체도 배울 게 참 많았다.
그중에서, 인스턴스가 만들어질 때 자동으로 인자값을 검증하는 로직을 만들 때 쓴 @classmethod가 기억에 남는다.

annotate

엑셀처럼, 어떤 QuerySet을 가져올 때 아예 column을 만들어서 가져오는 개념. 왜 쓰냐면, 쿼리문의 횟수를 줄일 수 있기 때문이다. 이 코드 이전에는 all을 1번 쓰고 filter함수를 5번 썼다. 쿼리문을 7개에서 1개로 줄인 셈. 
속도의 차이는 잘 모르겠지만, 일단 코드가 깔끔해져서 좋다. 그리고 DB 클라우드 컴퓨터에 부담이 덜 가지 않을까? 부담이 덜 간다는 건 곧 아마존한테 쓸 돈을 아낀다는 거.

status code

서버쪽에서는 단순한 숫자이지만, 프론트단에서 볼 때엔 대략적인 에러의 종류를 알려주는 귀중한 정보다!

exp : 토큰 유효기간 설정

흠. 모르겠다. 깊이 생각을 안 했다.
애초에 팀원들과 상의를 덜 한 부분. 사이트의 토큰 유효기간이 얼마정도면 적당한지 자체에 대한 고민이 없었다.

아쉬운 점들

• 프로젝트가 아닌 진짜 사이트라고 생각하면, 부족한 부분들이 너무 많다.
• 리스트와 스토리 모델 구조 : 망고 플레이트의 핵심은 식당 정보와 소셜 네트워크의 개념을 합친 데에 있다고 생각한다. 유저들이 직접 만드는 레스토랑 리스트, 스토리가 핵심이라고 생각한다. 그리고 무한 파도타기 구조. 한 리스트에 들어가면, 레스토랑 상세 페이지 밑에서 해당 리스트에 속한 다른 레스토랑을 추천한다.
• 상세 페이지의 리뷰 인스타 : 음식 사진을 눌렀을 때 인스타그램처럼 리뷰내용이 나오는 부분. 탐난다.
• 앱 쪼개기 : 사이트가 커진다면 현재의 앱 구조로는 RESTful API방식을 해칠 수 밖에 없다.
  Food 정보만 원하는데 URI는 restaurants로 시작하면 말이 안되지.
• 검색어 추천 검색어와 자동완성 기능
• EAT딜 : 수익 구조가 여기서 생기는 것 같다. 광고가 따로 없으니.
• 태그 모델 구조 : 주제에 따라서 레스토랑을 구분하고 보게 하고 싶다.
• 레스토랑의 조회수, 리뷰 수, 가고싶다 수
• CRUD관점 : 에서, 레스토랑의 CUD, 유저의 UD, 음식의 CUD가 없다.
  사이트가 커진다면 관리자 페이지 혹은 사장님 페이지가 따로 생겨야 하지 않을까?
• 소셜 로그인 (API)
• 지도 API (주변 맛집 추천!)
• 리스트, 모델
• Q (전반적으로 SQL문)
• subquery
• try else
• status code 다듬기

협업에 있어서 느낀 점들

역할을 확실하게.

처음 프로젝트를 기획할 때, 추상적인 목표들을 최대한 구체적으로 풀어보려고 했어야 한다. 그러면 나중에 서로 꼬일 일 없이 수월하게 진행되었을 것.

또한 기능이 중복되는 함수나 코드의 경우에, 서로 진행상황을 바로바로 공유하면서 나아갔다면, 훨씬 진행이 빨랐을거라 생각한다.

프론트와 백은 서로 알면 알수록 좋다.

생각보다 쓰는 단어가 달랐다. 누구는 인치로 재고 있는데 누구는 센치로 재고 있다. 그러니 같은 1을 말해도 아웃풋이 달라지지. 요청 URI를 브라우저 URL과 혼동하는 경우도 있다.

프론트엔드는 ERD(모델 구조)와 응답결과를, 백엔드는 최소한 사이트의 대략적인 레이아웃과 fetch, component 흐름을 알고 있으면 좋겠다고 생각.

자발적으로.

새로운 길을 열거나, 현재의 선택지 중에서 책임감을 갖고 방향을 제시해본 역할을 해본 적이 없다는 걸 알게 됐다. 그러니까 수동적으로, 내가 처하게 되는 상황에 불평만 하는 사람이 되고 있었다.

프로젝트에 대한 의견을 나서서 말하는 태도를 갖자. 그런 목소리들이 모여서 좋은 프로젝트를 만든다고 생각한다.