PM에서 백엔드 엔지니어

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..

각자 1시간씩 생각해보고 그려보고 테이블과 관계성을 고려하기로 했다. 나는 일단 erd 관계, modelling 툴을 사용하지 않고, 먼저 손으로 그리면서 하기로 했다. 쇼핑몰 erd 검색해서 나오는 table name, column https://velog.io/@1afterwon/%EC%87%BC%ED%95%91%EB%AA%B0-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EC%87%BC%ED%95%91%EB%AA%B0-ERD-%EC%84%A4%EA%B3%84 Table list 어떤 테이블들이 필요할 지 table name부터 정해보았다 이때 내가 잘못했던 점 - 회원가입과 로그인은 'user' table - 메인페이지와 상세페이지는 'product' 'product detail'로 하나의 ..

[진행 방식] 1. pk, fk 협의 (pk 빼고는 다 fk) 2. 화살표 어떻게 갈지 최대한 완벽하게 설계해도 결국엔 수정할 게 나와서 일단 넘어가도 됨 수요일 오전 dbmate 만들고 목금, mvp 하고 (추가 기능은 현진님) 사실상 1주로 끝. 2주째에는 통신만 데이터베이스는 일단 다 해놓고, 프론트와 나중에 협희 후 빼기로 [팀 논의] user table에 주소를 넣을지 ? user:주소 = 1:1 (유저가 하나의 주소 , 주소가 한개만 가능하고) 로 생각했는데 다른 사람에게 주문하는 경우 고려해서 1: 다 로 수정 user table email, passowrd, nickname, 전화번호 , profile image, 제공자 (소셜로그인- 네이버 같은 거) email, id 는 unique 값..

1,2일차 부여된(추가된) 나의 역할 내가 PO 역할도 맡지만 (상황정리, 방향성 파악) 1차 프로젝트 때 깃허브를 제대로 branch로 구분하고 관리했기에, 백엔드 팀원 중 pm을 제외하고 유일하게, pull request (pr)을 해본 사람이였기에, 깃허브 관리를 서포트 하는 역할을 했다. pm이 branch 올리면, 바로 확인해서 review하는 것 Merge 하는 법 깃허브 들어가면 알람 뜬다 add your review 버튼 누르면 버튼을 누르면, comment : 댓글 approve: reviewer가 승인 해줘야 merge가능 (이것도 없이 comment 가능할때도 있음) request changes: 수정해야할 거 같다 그러면 바로 실시간으로 이렇게 바뀐다. 그리고 작성자가, merge ..