PM과 BD, Backend 그 어느 사이

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

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

앞으로는 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할 떄 실수할까봐 ? - 성별구분 소셜로그인이 더 귀찮을 때도 있음 - 매번 카카오톡 연동에, - 차라리 한번 회원가입해서 아이디 비번 ..