PM과 BD, Backend 그 어느 사이

우리팀이 오전에 회의 및 협업 없어서, 개인공부하다가 다른 팀 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 뜨면서 목록 다 뜸 돼지만 카테고리이지만, 우리는 백엔드니까 데이터만 생각. 내용은, 눈에 보이는 ..

팀원들과 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 값..

2차 팀프로젝트는 MVP가 목표인데 그게 어떻게 가능한 것인가? 1차 때 1주 동안, 가장 기본적인 기능만 만들어서 내보내고, 2차 때 추가해서, 기능 만든다는 것. 바로 1차, 2차 sprint meeting 이 있는 이유였다. 우리팀의 말로는, 일단 와꾸만 만들어놓고, 추가 한다는 것. 만약, 클릭하면 '준비 중입니다' 메세지 나오는 것. 이렇게 실시간과 연결되는 것. standup meeting 이기에, 1차 프로젝트와 다르게, 2차 프로젝트에는 정말 짧게 해보기로 했다. 지각하신 분이 계셔서 예정시간인 10시보다 10분 늦은 10시 10분이 시작을 했는데, 팀원들 모두 10시 전에 와서 자리 잡고 각자 할일을 하고 있었어서, 영향이 없었다. 마지막에 오신 팀원분이 짐을 풀고 숨을 고르신 뒤, 먼저..

첫 주차의 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 상품 상세페이..

우리팀은 닥터마틴스로 정했다. 나의 역할: 진행 모더레이팅 팀원들이 참여할 수 잇도록, 서기/ 한번 답변 기회 주고 서기가 백엔드라 , 프론트 의견 없으면 채우도록, 의견 묻고 회원가입 로그인 체크박스 가입 됏다는건 체크됏다는거니 데이터베이스에 저장 안해도 된 데이터베이스에 마케팅 정보 선택인데 체크햇냐 안햇냐 -->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. 한 명씩, 사이트를 보고 느끼는 점을 던진다...