PM과 BD, Backend 그 어느 사이

0. migration file과 erd diagram 비교 1. 맞게 추출됐는지 오류 없는지 2. varchar ( ) 몇글자일지, 왜 이게 varchar ? not null ? 이런 거 수정할 게 있을 지 1. Categories table api 만들면서, erd는 계속 수정될 수 있음 그러면 erd diagram과 migration file 모두 수정하고, 깃허브 push 후 팀원들도 모두 Pull 받아야 함. 이후 수정된 categories table 내가 맡은 User table 분석! 2. User table phone number는 not null 이어야 할 거 같다. database 에서 공백이면 -> null 인데, 위에서 공백이니까, 비어있어도 된다. 이후 수정된 users table..

이후 5일 차 standing meeting, Pull request review 이후 수정 Project 2 - 5일 차 (3): standing meeting- [프론트 엔드와 협의] 및 [회원가입 코드 분석] [회원가입] 필수 / 선택 입력값 데이터 - 필수 1)생년월일 프론트: YYYY-MM-DD 형식 백엔드: 생년월일 받아오고, db에 저장하는 코드만 치면 됨. 2) 휴대번호 프론트: 010-****-**** 형식 백엔드: 받아오고, pm-developer-justdoit.tistory.com Project 2 - 5일 차 (4): 내가 push 한 회원가입 함수 : standing meeting에서 수정할 부분 [standing meeting 에서 모두가 수정해야 할 부분] Project 2 ..

filtering/ordering/pagination/searching : database를 찾는거고, 실시간으로 하는 거고, index/searching은 검색의 효율화를 위한 설정이 그런거고, 미리 동적으로 걸어주는 게 Index, transaction 찾는게 다름. 1. Indexing = 검색 1-1. Linear Search 하나씩 대조해서, 이건 이름이 cold brew인가? 아니다 그럼 또 다음 열로 가서, 이것은 cold brew인가? 아니다 '맞다'가 될 때까지 하는 것. 직선으로 한 줄씩 간다고 해서 linear search인데, 그러면 최악의 경우, row 가 N개일 경우, N번하게 될 수가 있다. 그렇다면, 검색을 더 빨리 할 순 없을까? 있다 . => 정렬 1-2. Binary S..

0. 프론트엔드와의 짧은 sync 0-1. 상세페이지의 product image가 이동하는 것과, 썸네일 이미지들을 구현하는데 일정 내에는 어려울 수도 있는데, 프론트엔드만의 결정으로 진행할 수 없으니 백엔드에게 상의를 하러 오셨다. 백엔드 팀원들이 본인 의견을 각자 이야기 하였고, 우선은, 테크리더이자 Pm이 자리에 없는 상태였기에, po 로서 백엔드의 입장에서 정리를 하였다. " 백엔드에서는 'erd modeling'에서 썸네일 이미지 테이블만 따로 뺐다가, 마친 썸네일 이미지를 product image table에 하나로 모아 수정한 상태이고, 백엔드가 추가로 코드를 치는 작업보다 프론트엔드의 작업량과 작업시간으로 작업강도가 더 강하니, 프론트엔드가 가능하면 하고 부담스러우면 편하게 해도 된다. 단..

erd diagram으로 export 해서 dbmate 만들기 1차 프로젝트 때 직접 dbmate 생성을 해보았기에, 다른 방법을 시도하고, 효율성을 중시하는 방향으로 추출하기로 했다. 1. dev에 가서 pull 받는다 2. database 설정 dbmate 설정 파일을 migration 하여 팀원 모두 동일한 Database 설정을 가지도록 합니다. .env 의 DATABASE_URL=설정 DATABASE_URL="mysql://root:{root 비밀번호 - 설정하지 않았따면 콜론 채로 생략}@127.0.0.1:3306/ABCMartens" (각자 로컬에 다른 데이터베이스 이름을 설정해도 영향 받지 않는데, 추후에 통일해야 해서 추가하기로 했다) 우리팀의 데이터베이스 이름은, ABCMartens 3..

우리팀이 오전에 회의 및 협업 없어서, 개인공부하다가 다른 팀 API 공부 및 연구하는 미팅에 청강 들었다 그 팀은 pm이 팀원들 공부하듯이 하기에. 혼자 연습해보았다. 다른팀의 페이지와 우리팀의 페이지로 비교해서 api는 각자 팀의 ERD에 따라 다르다. - cart는 user에 있을 수도. User/ User/log-in User/order User/product (User/order) 이런 식으로 뻗어나간다. API분석 예시 detail datasource에서, ? Query 넣을 거야 (찾는다는 뜻) Product 칼럼 Desc 상세페이지 product id 가 저거다. 쇼핑하기 누르면, /list 뜨면서 목록 다 뜸 돼지만 카테고리이지만, 우리는 백엔드니까 데이터만 생각. 내용은, 눈에 보이는 ..

index는 정적인 거 , 미리 걸어놓는거 transaction은 commit하나라도 안 되면 안 되는 거 검색을 효율적으로 하게 하는 거. Project 2 - 2일차 : [Restful API] 세션 (path부터 다시)** 앞으로는 restful api 엄격하게 add, create 가 들어가지 않게 리뷰해서 main branch에 들어가지 않게끔. main branch에는 엄격하게 지켜져야 함 호출할 때, 프론트가 json body에 담아서 가져가는게 아니라, 프 pm-developer-justdoit.tistory.com Project 2- 2일 차: [API]세션(1) Path parameter Project 2 - 2일차 : [Restful API] 세션 (path부터 다시)** 앞으로는 r..

Project 2 - 2일차 : [Restful API] 세션 (path부터 다시)** 앞으로는 restful api 엄격하게 add, create 가 들어가지 않게 리뷰해서 main branch에 들어가지 않게끔. main branch에는 엄격하게 지켜져야 함 호출할 때, 프론트가 json body에 담아서 가져가는게 아니라, 프 pm-developer-justdoit.tistory.com Project 2- 2일 차: [API]세션(2) Query Parameter (정렬부터 다시)** Query Parameter 1. query parameter란? url에서 특정한 조건을 주고 싶을 때 사용하는 매개변수 유형 같은 API를 호출한다고 해도, 서로 다른 조건으로 나열하는 것이 필요한 상황에 사용 U..

2일 차 내용만 적고 게시한 뒤, 이후 4,5일 차도 추가했기에, 날짜가 2일 차 날짜로 업로드 되어있습니다 :) 2일 차, 다른 팀 Pm과 대화 1일 차 어땠는지 팀원들 어떤지 어떻게 진행 중인지 pm 고충 공유하고 좋았다. 우리팀에 연장자들이 있는데도 불구하고 내가 이렇게 주도하고 리드해도 되는지 모르겠다고 하니, 그 pm은 나에게 "에이 나이가 뭐가 중요해 그런 게 어딨어, 그렇게 해야해, 그렇게 분위기를 잡아야 해 잘하고 있네~ 3차 프로젝트엔 같은 팀 되고 싶다 " 라고 말해줘서 응원이 되었다. 그리고, 프론트에게 api를 빠르게 주기 위해 mvp 는 팀원 3명이, 추가기능 + 주문 결제는 pm이 하기로 해서 이번주 내로 1주라고 생각하고 다 끝내기로. 그리고 2주차에는 내내 통신하는데에 쓰기로..

팀원들과 layered pattern을 하면서 어려웠던 점을 공유하며, 다시 복기 했다. 공통적으로 어려웠던 점 - 어떤 걸 app.js에 남겨야 하는지 어떤걸 넘겨야 하는지 (연결 부분) - import, export연결 (우리는 import 안하고,require로 ) middlewear - 에러 담당 middlewear로 가기에 - error를 다 선언 하지 않아도 됨 - error하는 함수 자체를 다 빼서 하는거 utility안에 함수 middlewear는 next 를 갖고 있는 함수 일반 middlewear는 res,req,next 3개 받는데, error 전용 middlewear는 req가 아니라 err, res req, next 4개 그래서 모든 router에 error처리 없이 넘기면됨 ne..