Project DAY 4 ~ 6

오늘 우리집에서 팀원들과 데이터를 주고받으면서 프로젝트에 어느정도 윤곽이 잡혔다.

Features

이제까지 한 것들을 정리해보면

• 로그인, 회원가입 (1~3일차까지)
• 상품 등록기능 view 구현, 상품 상세페이지 view 구현 (4~6일차 까지)
• models.py 수정

이렇게 적고 나니까 별로 한게 없어보이지만 .. 어떻게 짜야 최선인지에 대한 고민을 많이했다. 그리고

그 동안 이슈가 되었던 문제들을 소개해보려고 한다.

Bottle necks & How we solved them?

Bottle neck # 1 : product registry

• 상품 등록 구현하기 때문에 어려움이 있었다.
• 원래 배민문방구에서 상품 등록하기 기능은 없고, 상품을 노출하는 기능만 있기 때문에
• 상품을 자유자재로 집어넣기 위해서 프론트에서 admin 페이지를 만들어 간단하게 상품을 등록하는 기능을 추가하려고 했다.
• 하지만 이렇게하면 하나하나 직접 넣어야 하기 때문에 여러 상품을 집어넣는데 오래걸릴 것으로 판단되었다.

How to solve ?

• csv 파일로 상품정보를 전부 등록해 놓고 만들어놓은 view 에 python request 모듈로 파일을 한번에 집어넣기로 했다.
• 데이터의 양이 몇천 몇만개가 아니기 때문에, bulk insert 로 한번에 집어넣어지 않고 이미 만들어져 있는 view 에 for loop 로 csv 파일의 row 한줄 한줄 씩 집어넣기로 했다. 왜냐면 애초에 상품등록하는 view 를 짤 때 하나하나 씩 넣는 것을 목적으로 만들었기 때문이다.
• 만약 몇 천개 단위로 데이터를 넣어야 하면 bulk insert 가 가능하도록 view 를 설계했을 것이다.
• 경험담으로 키움증권 api 를 만들어서 기관매수정보를 가져오는 프로그램을 만들 때 100 일치 데이터를 한번에 db에 저장하는 경우가 생겼었는데, bulk insert 를 모르고 그냥 하나씩 for 문으로 저장했더니 너무 오래걸리는 것이였다. 코스피 종목 수는 3000개가 넘는데 한 종목당 O(n) 인 것 보다 bulk insert 로 O(1) 으로 만들어버리는 것이 시간면에서 훨씬 빨랐다.
• csv 파일은 시간이 되면 크롤링이 허용되는 특정 사이트에서 필요한 데이터만 모두 가져오기로 했다.
• 크롤링이 가능한지 자세한 여부를 보고싶으면

  http://some-site.com/robots.txt
  이런식으로 메인 라우터 뒤에 robots.txt 를 붙여보면 크롤링 가능한 정보 및 불가능한 정보가 나온다.

Bottle neck # 2 : models.py modification

• master 브랜치에 merge 를 하려면 PR approve 가 완료돼야한다.
• 다른 브랜치에서 작업하다가 models.py 에 아주 사소한 수정사항이 여러 번 생겼던 일이 비일비재했다.
• 그래서 master 에서 브랜치를 새로 파서 수정한 뒤, 그 기능이 master 에 merge 된 후 작업하던 브랜치로 가서 git merge master 를 해주어야 했다.
• 이 과정에서 시간이 좀 오래걸렸다.

How to solve ?

• 처음에 모델을 짤 때 신중하게 검토했지만 좀 더 공을 들여서 검토를 하고 또 보고 했어야 했다. 직접 페이지를 하나하나 다 보면서 기능에 대한 view 를 짠다고 생각해보고 모델을 짰으면 이런 일이 없었을텐데, 프로젝트가 2주이다 보니까 조금 급했던 감이 있다. 다음에는 모델링에 시간을 절대적으로 많이 쓰고 검토해서 이런일이 일어나지 않도록 해야겠다.

Bottle neck # 3 : git conflict resolve

• 아무래도 혼자 작업하는게 아니고 다른 팀원 분(다민님) 과 같이 작업하는 것이기 때문에 같은 파일에 서로 다른 기능을 작성하는 한 git conflict 가 날 수 밖에 없었다.
• 나는 ProductView 의 post 를 작성하고, 다민님은 같은 뷰 클래스의 get 을 작성했기 때문에 내 브랜치가 마스터에 머지된 후 다민님의 브랜치를 master 에 merge 하려고 하면 conflict 가 날 수 밖에 없었다.

How to solve ?

• git conflict resolve 를 했는데, github 자체에서 하지 않고
• 먼저 master 브랜치에서 git pull origin master 로 최신화를 시켜놓고
• 충돌이 난 브랜치로 checkout 해서 git merge master 를 한다.
• 그러면 충돌이 나는 상황이 재현되는데, 거기서 incoming changes 랑 current changes 를 비교해 가면서 코드를 수정한다.
• 수정한 뒤 master 브랜치로 merge 를 하면 되는데 이 때 마스터 브랜치가 다시 또 업데이트 되어있으면 안된다 !

Bottle neck # 4 : django migration clashes

• django 에서 makemigrations 와 migrate 를 할 때 db 가 꼬여서 충돌이 난 적이 한 두번이 아니다.
• makemigrations 오류는 models.py 를 수정할 때 새로운 컬럼이 추가되거나, data type 이 변경되거나 할 때 django 가 오류를 뱉었다.
• migrate 오류는 현재 장고의 migrate history 에 있는 db 의 형태와 실제 내 db 의 형태가 다를 때 발생했다.
• 예를들어 내 db 에는 stock 이라는 컬럼이 이미 있는데, django 에서 migrate 를 하려고 할 때 stock 이라는 컬럼을 만들려고 할 때가 그 예시이다.

How to solve ?

• 일단 지양해야 할 것은 app.migration 파일을 통째로 날리는 것이다. 물론 초기 단계에서만 가능한 이야기다.
• migration 에는 이제까지의 모든 db 수정사항이 다 들어있는 폴더인데, 이걸 날리면 .. 안된다.
• 컬럼을 추가할 때 생기는 conflict 는 default 값을 형식에 맞게 넣어주면 해결된다. 이것도 넣어 둔 데이터가 별로 없을 때만 가능한 방법이다. 이렇게 안해주고 데이터 형식 막 집어넣으면 type 에러가 나기 때문에 귀찮아진다.
• db 를 직접 수정하는 방법은 아주 안좋은 방법이기 때문에 하지 말아야 했는데, 초기 단계라서 귀찮아서 그렇게 했지만 앞으로는 다음에 소개할 방법대로 할 예정이다.

migration Tips from mentors

• 마이그레이션 되어 있는 기존 테이블을 다루는 건 아주 조심스럽게 해야한다.

• python manage.py migrate {{앱이름}} {{마이그레이션 번호}} -> 이렇게 해서 마이그레이션 롤백한다.
• 해당 마이그레이션 파일을 삭제 한다.
• python manage.py makemigration 해서 새로운 마이그레이션 파일을 생성한다.
• python manage.py migrate 으로 마이그레이션 한다.
• 이런 방식으로 주로 한 두개의 마이그레이션 파일만 수정해야한다.

추가로 도움이 되는 명령어들
적절하게 써가면서 해당 마이그레이션의 상태 파악 및 히스토리 관리를 명확하게 하면 좋다.

• python manage.py migrate {{앱 이름}} {{마이그레이션 번호}} --fake 등의 페이크 마이그레이션
• python manage.py showmigrations : 현재 적용된 마이그레이션 (db에 마이그레이션 번호와 파일 마이그레이션 비교)
• python manage.py sqlmigration {{앱 이름}} {{마이그레이션 번호}} (–backward) mysql 스크립트 코드 출력

아직 소개된 팁을 적용해본 적은 없지만 아주 유용한 팁일 것 같아서 적어보았다.

Things to do for next week

• order 기능 구현
• 장바구니 기능 구현
• 찜 목록 구현
• url 을 RESTFUL 하게 구현