PM과 BD, Backend 그 어느 사이

할때마다 commit 하라고 해서, git add . git commit -m 기능별로 commit을 하라는건, push까지 해야 한다는 뜻. m pr: 큰 기능에, feature branch의 마감 commit message에 어떤 기능별로 오면, 그거만 보면 되는데, 한번에 보면 보는 사람이 피곤함. 132줄 짜리 코드를 우선, signup branch push pull request 버튼을 누르면, 4가지를 체크해야 한다. 1. base 위치 / compare branch 2. reviewers 3. assignees 4. commit 내역 1. branch 설정 잘 돼 있는지 우리 팀은 바로 main에 merge 하지 않고, dev에 하기로 했다. main 은 정말 최종의 깔끔한 코드만 갈 수 있..

내가 작성한 const express = require('express'); const morgan = require('morgan'); const cors = require('cors'); require('dotenv').config(); const app = express(); app.set('port', process.env.PORT || 8000); app.use(cors()); app.use(morgan('dev')); app.use(express.json()); app.use(express.urlencoded({ extended: true })); app.use((req, _, next) => { const error = new Error(`${req.method} ${req.url} 라우터가..

다 불러와주면 됨 이미지 제목 내용 product option - > size , quantity재고, price, sale price, [index] [router] 상세페이지로 가고 싶어 라고 호출 url 경로를 준다. 일로 들어오면 해결하게 해줄게 detai에서 id로 들어오면 이렇게 받을 거야. :id 이기 때문에 parameter 숫자가 들어오면 그건 product id에 해당되는걸 말해주는 거 [controller] productController --> 받은 req값을 어떻게 처리할지 요청이나 응답만 처리한다. = 나는 어떻게 선언을 할 거야. 그럼 그 뒷단에서 다 그렇게 처리 parameter로 받을 것을 안다 const { generateToken, throwError } = requir..

기획 3 by 4로 가로 3개로 한 페이지에 12개 들어남 더보기 누르면, 페이지 늘어나는게 자동으로 늘어느냐 첫 페이지 무조건 12개 나오고, 페이지마다 12개씩 나오는 거. mock data로 보여드리면, 메인페이지로 하기로 했으니, 처음 들어가면, sale로 맨 앞으로 오게 하고. 메인페이지의 정의 우리가 선택한 상품인, 닥터마틴의 경우 [메인페이지] 홈에 들어가면 나오는 화면 = 상품 목록 페이지로 함 메인페이지에서, 카테고리의 - 세부카테고리를 들어가면, 다음과 같이 나온다. 이렇게 전체 목록 리스트로 나오는 것을 우리는 '전체 페이지' 이자 '전체 목록 페이지'로 하기로 했고, 이 목록 페이지 중 상품 하나를 클릭 시 나오는 페이지를 '상세페이지'로 프론트엔드와, 백엔드 내부적으로도 다시 sy..

standing meeting에서 프론트엔드와 함께, 메인페이지, 전체페이지, 상세페이지에 대한 align을 한 뒤 백엔드끼리, 구조화를 해보기로 했다. 메인페이지가 생각보다 기능의 난이도가 상당히 높기에. 그리고, 나의 경우에는 회원가입과 로그인만 맡아서 다른 기능 구현을 팀 프로젝트 단위로 하는 만큼, 함께 해보고 싶어서.!! 그래서, 상세페이지를 다 했다고 하는 팀원의 코드 리뷰도 하기로 한 거고! 일단, 상세페이지를 담당하는 분의 고민부터! 1. product 의 'option table'에서 size를 넣어야 할까? 기술테크 pm의 의견 - 닥터마틴은 신발 가게이다. 사이즈가 들어가야하고, 사람의 사이즈 범위가 무제한이 아니기에, 어렵지 않다! po 나의 의견- 당연히 넣어야 한다! 돼지고기가게..

보호되어 있는 글입니다.

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

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