PM에서 백엔드 엔지니어

할때마다 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 나의 의견- 당연히 넣어야 한다! 돼지고기가게..

2차 프로젝트를 하다보니, 여러 종류의 미팅을 하는데, 그 미팅의 개념을 구분하고, 1차 프로젝트부터 도입했던 부분을 정리하기 위해. 프로젝트를 대하는 마인드 연습은 실전처럼, 실전은 연습처럼 회사에서 하듯. 스타트업에서 하듯 팀프로젝트 운영 방식 Sprint = 뛴다 *조깅이 아니라 Meeting 종류 1. Planning meeting : sprint 첫날 2. Daily standup meeting 아침마다 10-15분 동안 내가 오늘 다리가 아파, 뛰어야 하는데.. 이런 거 공유 / 뭘 도움 받아야 하는지 어떤 걸 할당해서 몇 퍼센트 진행햇꼬 진행 방해하는 요소가 blocker (방해요소) 인데, 그거를 멘토 /사수에 도움돼서 오늘 3시까지는 쳐 낼 수 잇을 거같습니다. 만약에 싱크 맞추는 작업 ..

보호되어 있는 글입니다.

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