PM에서 백엔드 엔지니어

앞으로는 restful api 엄격하게 add, create 가 들어가지 않게 리뷰해서 main branch에 들어가지 않게끔. main branch에는 엄격하게 지켜져야 함 호출할 때, 프론트가 json body에 담아서 가져가는게 아니라, 프론트가 보낼 때부터, 나는 뭐가 필요해 라고 객체의 key value에 담아놓고 보내면, 백엔드가 필요한 데이터만 골라서 보내줌 (graphQL) RPI ; Representational State Transfer Rest = 규칙 Restful api = 규칙을 잘 지킨 api 통신을 잘 하기 위해 의사소통 규칙 Http 통신은 statless 가 대표 상태(State)를 전달(Transfer)하는 것을 나타내는(Representation) 방법 “자원(=dat..

첫 주차의 1차 Sprint Meeting [1일차 진행 방식] 분석과 기능 구현, 티켓 제작 및 분배를 위해, 프론트엔드와 백엔드가 하루종일 함께 sprint meeting과 연이어 planning meeting을 했다. [그렇게 진행한 이유] pm 으로의 역할이기도 하지만, Pm 되기 전부터 이런 방식으로 리드했다. 아무래도 추석 연휴가 껴있고, 막판에 데드라인 앞에서 밤새거나 연휴에 모이는 불상사가 없기 위해서 초반부터 달렸다. 달리기만 한 게 아니라, 달리기 전에, 공통으로 해야 할 것, 백엔드가 할 것 프론트에 해야 할 것들을 리스팅하고 구조화하고, 추석 전에는 어디까지 해야하고, 2주차 화요일까진 어디까지 구현될 것인지 타임라인을 잡았다. 일정을 맞추기 위해 전반적인 흐름을 잡고 모든 팀원들이..

기업 분석 후, PET 작성 후 티켓 분배 순서는 로그인/회원가입과 상품상세를 먼저 만든다. 로그인/ 회원가입- 유진 (user table) 상품 상세페이지 (product table) -승원님 경재님 --> 하나씩 현진님 - 소셜 로그인, 결제 모듈 (외부 api 타는 것) + 손 모자르는 거 가져가는 서기 정해야 하고 나: Trello 티켓 생성 프론트 로그인 회원가입 (비회원은 추가,, 와꾸만 만들어놓고) - 종원님 상품 상세페이지 - 병우 소연님 프론트 백엔드는 메인, 주문, 결제는 추후에 정하고 일단 1주차에 저거 부터 하고 일반 로그인만 하고, 간편 로그인 티켓 구조 테이블 구조는 크게 두 개고 product table, user table 로그인/회원가입 = user table 상품 상세페이..

Project 2 하면서 kick off로 마켓컬리에 대해 같이 생각해봤던 Project 2 - Kick off : Business Modeling Product +ing = 비전공자 개발자 배출하면서 위코드에서 신입 소프트웨어 엔지니어가 전달 받고자 하는 철학, 가치관 = “Business Modeling” MVP Branding 제품 고객 기술 Product / End-User /Tech = PET 개발자의 pm-developer-justdoit.tistory.com 아래는 참고 자료 Product+ing 분석 | 마켓컬리 사이트 정보 링크 : https://www.wiselycompany.com/index.html 판매 품목 : 헤어케어, 면도용품, 스킨케어, 생리대, 영양제, 주방용품 등 메인 테..

목표와 방향을 제대로 이해하기 위해. 전체적 timeline 월요일 - 분석 기획(모델링은 오래 걸리고, 어느 기능까지 할지) 화요일 - - 소셜 로그인은 안 한다. (3차때, 대한항공, cgv 예약 기능과 함께---> 지역별 영화관, 매진 좌석, 예약가능 좌석 고려) - 비회원 로그인은 우선 순위 뒤로 >> 요청 시 "로그인 필요합니다 " 메세지로 >> 유저 정보 필요 없을 거기에, 인증 절차도 필요 없어질 것 - 휴대폰 간편 인증도 안하는 로그인 회원가입부터 주문결제까지의 과정에 집중 로그인, 회원가입, 주문페이지 결제페이지 상세페이지, 메인페이지, 장바구니 -> 데이터베이스에서 값이 와야해서 필요함 (외부 라이브러리 없음) 2차는 디자인 안함. 그러라고, clone 이미 디자인 나온거로. 추석 한 ..

우리팀은 닥터마틴스로 정했다. 나의 역할: 진행 모더레이팅 팀원들이 참여할 수 잇도록, 서기/ 한번 답변 기회 주고 서기가 백엔드라 , 프론트 의견 없으면 채우도록, 의견 묻고 회원가입 로그인 체크박스 가입 됏다는건 체크됏다는거니 데이터베이스에 저장 안해도 된 데이터베이스에 마케팅 정보 선택인데 체크햇냐 안햇냐 -->Y/N으로 구분 소셜 로그인, 휴대폰 인증도 미리 안해보면 또 3차에서 안 될테니 --> db 부터가 다른 성별 필수인 이유? --> 메인페이지를 여성 위주로 보여주고, 데이터를 빼줄 수 있으니, 굳이 필수? 어쩌피 선물하면 다른 성별꺼 살 수도 있으니 CS할 떄 실수할까봐 ? - 성별구분 소셜로그인이 더 귀찮을 때도 있음 - 매번 카카오톡 연동에, - 차라리 한번 회원가입해서 아이디 비번 ..

Project 2- 1일차: 1차 Sprint Meeting 첫 주차의 1차 Sprint Meeting [1일차 진행 방식] 분석과 기능 구현, 티켓 제작 및 분배를 위해, 프론트엔드와 백엔드가 하루종일 함께 sprint meeting과 연이어 planning meeting을 했다. [그렇게 진행한 이유] pm-developer-justdoit.tistory.com 멘토님께서 2차 프로젝트를 위한 기업/ product 선정을 위해 주신 11가지의 후보를 모두 분석해보기로 했다. 월요일 sprint meeting 겸 planning meeting으로 프론트엔드와 백엔드 모두 11개의 기업분석을 하였다. 1. 같은 사이트를 동시에 들어가 일단 각자 살핀다. 2. 한 명씩, 사이트를 보고 느끼는 점을 던진다...

project1- 2일차(3): 회원가입 기능 layered pattern project 1 복사 붙여놓기 복사본은 깃 반영 안 됨 ls- al 해서 .git 떠도 반영 안 된다. ls-al 해서 나오는 건 git 삭제 remote 연결 안 될 것 단방향에 따라서, 각 파일의 앞단에서 export로 내보낸거를 require pm-developer-justdoit.tistory.com Layered pattern 📍개요 🗣 특별한 구조 없이 한 파일에 모든 코드를 구현: 코드의 양이 많지 않을 때는 간단, but 코드의 양이 조금만 많아져도 오히려 코드 유지 보수가 어려워진다. 실제 기업의 시스템에서는 논리적으로 혹은 기능적으로 영역을 구분하여 코드를 관리하는 것이 좋다. 코드가 구성되어지는 아키텍처를 학..

비밀번호 암호화 -> 고객 데이터 소중 개인정보 보호 법령에 의거. 백엔드 개발자라고해서 고객의 비밀번호를 알 수 없음 . 단방향. 돌아갈 수 없음. -> 해쉬 함수 (한번 복호화 후에는 비밀번호를 볼 수 없음, 역함수 없음) (우리는 복호화 하는데, 이거를 풀려고 하는 사람이 있다. --> 해커들. 그렇기에 복잡하게 비밀번호 암호화 하는 것) 1. 설치 npm install bcrypt --save -dev package.json에서 확인 2. 쓸 수 있게 가져온다 const bycrypt = require("bcrypt") ; 3. 두개의 변수 선언 const bcrypt = require("bcrypt"); const password = 'password'; // 문자열 const saltRound..

Project 1- 5일차: 통신 완료! 마지막날 통신 하기 전에 실수 1. datasource 를 잘못 정의 했다. 2. 회원가입을 하고 나서, 토큰이 안 돼서 알고보니, 해쉬 함수가 로그인 함수에만 들어가는게 아니라, 회원가입 함수에서부터 해야 한다. 위 pm-developer-justdoit.tistory.com 위 포스팅에는 과정과 통신 직전 실수한 코드 리뷰가 있어서 Foundation Test를 성공했을 때와 마찬가지로, Foundation Test 제출 1. 서버 연결 Welcome to Y's server! 2. 회원가입 postman 통신 결과 userCreated! 3. 회원가입 mysql 데이터베이스에 잘 들어갔는지 4.로그인 postman 통신 결과 Login Success! 토큰까..