회고록..이라는 거창한 이름 보다는 그동안 나는 뭐했나? 요런거..
개천절로 인해 월요일이 아닌 화요일부터 프로젝트를 시작하게 되었다.
주말동안 그간 했던 거 복습하고 월요일에는 이전 기수의 프로젝트 회고록을 봤다.
코드야 봐도 모르기 때문에 프로젝트를 하며 애로사항은 어떤거고,
미처 알았으면 했던것들 등을 보게 되었다.
저거는 내가 이전에 작성한것부터 프로젝트 시작하고 내용들을 담고 있다
전체 내용으로는
Daily Standup Meeting(매일 아침)
어제 내가 하기로 한 것
진행상황
안됐다면 완료 시기는 언제일지
어제에 대한 피드백 끝나면 오늘 할 것
존중(프론트는 화면뽑는 기계가 아니고, 백엔드는 데이터뽑는 기계가 아님)
솔직
협동
진행자 및 서기(노션에 각자 작성? 아니면 내가 작성해서 올리면 내가 올린 것 아래 제대로 된 내용 추가)
Planning Meeting(주 시작)
한주동안의 피드백
------------------------------------------------------------------------
구현 범위(세부사항까지.. 예를들어 비밀번호 정규식처럼 .. + 하루를 날린 상황에서 하기 때문에 현실적인 목표)
회원가입/로그인 + 수정/탈퇴/로그아웃 or 소셜로그인 / 유효성검사는 백엔드에서
게시글 작성/보기 + 답글 작성
댓글 등록/보기 + 대댓글 작성 or 평점
모델링(백+프 같이하고 만드는건 백엔드에서 / 홈페이지 같이보면서 / 필요 컬럼, Unique, Null)
변수명 설정
url(rest 설명 + 백엔드에서 설정)
branch 명 : feature/페이지이름(기능)
서버(항상 켜놓으려고 할 것이나, 혹여나 꺼놓을 수도 있음 / 그럴 때 끙끙대지 말고 켜달라고 하자)
————————————————————————————————————
requirements.txt : 프론트꺼도 함께
------------------------------------------------------------------------
엑셀에 기능/메소드/url/request data/response data
------------------------------------------------------------------------
db_uploader(백업) + 각자 기능별로 csv 파일
https://velog.io/@taeil77/%ED%8C%8C%EC%9D%B4%EC%8D%AC-%EA%B5%AC%EA%B8%80-%EC%8A%A4%ED%94%84%EB%A0%88%EB%93%9C-%EC%97%B0%EB%8F%99
https://towardsdatascience.com/generation-of-large-csv-data-using-python-faker-8cfcbedca7a7
------------------------------------------------------------------------
테스트(에러를 내야 함 / 백&프 서로 상반된 관점에서)
------------------------------------------------------------------------
Trello
앱 - 기능(메소드)
Backlog : 앞으로 해야 할 모든 일
This Week : 이번 주
In progress : 진행 중(날짜도 표기할건지)
Done : 끝(끝의 기준은 push? 코드 완성?)
백로깅
디스위크
인프로그레스
코드 완성
코드리뷰완료
푸쉬완료
백오더
돈
데일리 스탠드업 미팅에서 어떤 걸 해야하고, 팀원들과 지켜야할 약속에 대해 적고
진행 및 회의록도 어떻게 해야할지 생각해보게 되었다.
그리고 어떤 홈페이지를 클론할지는 모르겠지만 구현해야 할 기능과
현실적인 범위는 어떤 것이 있을지 이야기를 하는 게 좋을 것 같아서 적어뒀던 것 같다
그리고 requirements.txt 파일을 통해 버전관리를 할 수 있는데
pip install -r requirements.txt 를 하면
팀원 모두 같은 버전의 라이브러리들을 받을 수 있다.
이부분이 아쉬웠던게, 나는 프론트의 파일들도 같이 합쳐서 관리하는 줄 알았는데
이전 기수들 보니 프/백을 나눠서 깃을 관리하다보니 나눠진 게 아쉬웠다.
그리고 연동을 위해 데이터 변수명도 맞춰야 하기 때문에
기능/담당자/url/변수를 정리해두면 좋지 않을까란 생각이 들었다.
그래서 엑셀파일을 만들어 우리팀이 구현해야 될 사항과 맞춰야될 걸 한눈에 볼 수 있었다.
(다른 사람의 실명을 밝힐 수 없기에, 내 부분만 캡처)
내가 이전 직장에서 정말 진절머리나게 들었던 단어이다.
컨설턴트로서 고객의 요구사항을 듣고, 그에 맞게 개발자에게 작업 할당을 한 뒤
결과물이 나온 걸 내가 직접 테스트를 해서 이상 없어야 고객에게 시연을 하기 때문이다.
심지어 고객 앞에서 에러도 뜬적도 있어서 얼마나 난감했던지 ㅋㅋㅋ
그리고 나는 공급사의 입장이기 때문에, 내가 미쳐 놓친 부분도 고객사에서 연락이 온다.
어 이거 했더니 에러나요, 잘 안돼요 라고 전화/카톡이 오면
아 내가 이부분을 놓쳤구나.. 하고 또 테스트를 한다.
그렇다보니, 백엔드와 프론트엔드의 상반된 관점에서 테스트를 진행한 뒤,
에러를 발생시키는 게 좋다고 생각했다.
이건 아직 기간이 남고 각자 구현중에 있으니, 꼭 해보고 싶다.
이전 회사에서도 프로젝트 기간에 맞게 개발을 진행해야 하기 때문에
자사에서 직접 개발한 일정관리 시스템을 사용했었다.
트렐로의 기본적인 관리 카드는
Backlog : 앞으로 해야 할 모든 일
This Week : 금주내로 해야 할 모든 일
In progress : 진행중
Done : 끝
의 구성으로 이루어져 있다.
그런데 너무 범위들이 막연했고, 조금 더 상세하게 관리하고 싶었다.
이전 회사도 마찬가지로 개발자들은 직접 고객을 대면하지 않다보니
납기의 중요성을 잘 몰랐기 때문이다.
특히, 신입사원으로서 나보다 짬높고 나이많은 사람한테 뭐라하는 건 너무 힘들었다.
그래서 나눈 게
해야 할 일
이번 주내로 해야할 일
진행 중
Push완료
코드리뷰 완료
Backorder
Done
이다.
특히, 이번주까지라고 막연하게 하는 것 보다 날짜를 기입하여 정확한 날짜를
알기 위해 날짜를 작성하는 게 어떨까라는 생각이 들었다.
내가 PR을 올려서 멘토님이 봐주는 것도 진행중이기 때문에 진행중 하나만
놓고보기엔 진행상황 파악이 어려울 거라고 생각했다.
그래서 진행중-Push완료-코드리뷰완료 3단계로 나누게 되었다.
그리고 날짜를 작성했기 때문에, 날짜 내에 못하게 된 건 Backorder로 옮겨
진행상황 파악을 더 용이하게 할 수 있게 하였다.
10/6
images테이블 컬럼 수(완)
rest api
깃 물어보기(완)
categories_menus 물어보기 / get 까지
————————————————————————————————————————————————————
10/7
comments 테이블 product_id 필요성(수정은 ㄴㄴ)
제품 상세페이지에서 어떤 카테고리의 제품들 보여주고, 상세 제품은 어떤거 보여줄건지(현진)
url 및 프론트에서 값을 어떻게 아는가 물어보기(멘토님)
pagination - offset / limit(프론트에서 1000갱 이렇게 요청할 수 있으므로 일정 데이터 넘어가면 못 하게 백엔드에서 막아야 함)
————————————————————————————————————————————————————
10/8
모델링 변경 검토 -> 변경하면 커밋하는 사람이 하기 o
db변수명 다 소문자로 수정 o
q/f객체 사용 o
db_uploader 파일 만들었나 확인(만든사람있으면 이름 변경해야 함) o
카테고리, 메뉴 이런 것들은 데이터 다 만들어줘야 하나 물어보기 o
이미지30개 url 따서 저장 o
색상 필터(낼)
rest api o
프로젝트 모델링 o
————————————————————————————————————————————————————
10/9
메인페이지
색상 필터 o
리뷰 n건 ㅇ
페이징기법 (offset / limit) o
상세페이지
상품명 : name
상품가격 : price
색깔 : color (list형태)
사이즈 : size (list형태)
상품설명 : description
후기 작성자 : posting_writer
후기 제목 : posting_title
후기 내용 : posting_content
후기 이미지 : posting_image (list형태)
후기 작성일 : posting_date (yyyy-mm-dd형태)
댓글 작성자 : comment_writer
댓글 내용 : comment_content
댓글 작성일 : comment_date(yyyy-mm-dd형태)
상품이미지들 : image_list (list형태)
images 테이블에서 null=True를 해줘야 할 걸 안해줘서 수정작업이 필요했다.
또한 내가 위에서 작성한대로 url을 작성하기 위해 rest api에 대해
공부를 해야해서 써놨었다.
특히, url을 만드는 게 생각보다 너무 어려워서 멘토님께 물어봐야지 했던 것 같다
모델링 작업이 계속 진행되다보니 놓친 부분들이 많았다
굳이 없어도 될 컬럼인데 추가했다던가.. 그런..
또한 클론을 하되, 시연용은 따로 선정해야해서 프론트 담당자와 이야기해야겠다..
라고 생각을 했다.
마지막으로 너무 헷갈렸던게 id값을 프론트에 보내주지 않았는데,
어떻게 값을 보내줄것인가? 라는 물음이 너무 심오하게 다가왔다.
특히 페이징기법을 통해 값을 줘야하기 때문에 어떻게 줄까.. 했던 것 같다
그래서 다른 동기분들이나 멘토님들께 물어보며 나의 궁금증을 해결했던 것 같다
역시 집단지성!
모델링 최종 확정을 하는 날이었다.
프론트 세션 때 url에 대문자를 넣지 말라고 멘토님이 말씀하셨다고 하셔서
DB에 데이터를 넣을 때 소문자로 넣어야겠다(까먹을 수 있으니) 썼었다.
머리가 안좋아서;;
그리고 Q객체, F객체를 쓰기 애매하지만 한 번 써보고 싶었다
(이건 어거지로 써서 PR을 올렸다..ㅋㅋㅋ)
그리고 데이터 생성에 대해 정하는 것도 일이었다.
csv파일을 올리기 위한 db_uploader.py를
혹여나 같은 이름으로 만든 팀원이 있으면 수정해야 하기 때문에 확인을 해야 했고,
프론트와 연결할 때 데이터를 어느정도 보여줄지 각 페이지 담당자와 이야기했었다.
상품리스트를 조회한 뒤, 특정 상품을 누르면 이동하는 형태인데
상품리스트에서 색상필터를 해보기로 하여 get으로 보내줄 때 색상리스트도 추가해야 됐다.
리뷰도 건수를 보여주기 위해 데이터를 임시로 등록해야 됐고,
페이징기법도 offset과 limit을 사용한다고는 했지만 구현을 안해봐서
구현을 어떻게 했는지 찾아볼 필요가 있었다.
그런데 생각보다 되게 단순한;;거였고 쿼리파라미터로 url에 추가하여
개수가 나눠져 나오는 것도 확인할 수 있었다.
특히, 색상 필터의 경우, 나나 프론트 담당자나 어떻게 해야할지
계속 고민했었다.
한 제품의 여러색의 옷이 있으니, 색깔을 리스트로 보내면 되는 줄 알았는데,
그 부분을 프론트에서는 해본적이 없어서 색깔을 각 상품당 1개로 할지
이야기가 많이 이루어졌다.
상품의 색상은 상품상세페이지에서도 보여줘야 하기 때문에 한개로 할 수 없었고
리스트를 받아서 할 수 밖에 없는 상황이었는데..
프론트 담당자분이 10분만에 성공하여 색상 필터링 기능도 성공하게 되었다;;
역시 나는 팀운 최강의 사나이
이제 특정 상품을 누르면 나오는 상품상세페이지를 해야 하는데
여기서 생각을 잘못한 부분이 있었다.
상품의 정보와 후기리스트를 다르게 생각했는데, 후기도 상품 정보의 일부기 때문에
백엔드 담당자를 둘로 나눌 필요가 없었다.
후기 부분 담당자분에게 이 상황을 전달했고, 상품 페이지를 하기로 한 내가 한다고 했다.
그래서 나온 변수가 14개인데, 이미지가 문제였다
한 상품상세페이지에 이미지가 10개정도 있다보니 저장하는 게 너무 귀찮았다.
롤드컵도 봐야하기 때문에 오늘은 데이터만 저장하고 내일부터 작성하자고 마음을 먹었다
그럼 남은 기간 화이팅!