PM과 BD, Backend 그 어느 사이

내가 거의 깃허브 관리 담당이였다. 제대로 말하자면, 깃허브 branch에 분리해서 코드를 올리는 사람. 즉, 코드도 치고 올리는 사람. 팀원들이 코드를 주긴 하는데, 틀린 코드도 있고 실행하는 사람은 나이고 pr 후 commit 을 하는 사람은 나이고, merge 후 복잡한 문제를 안고, branch copy /생성 후에 새로운 branch를 생성할 사람은 나 이기에, 문제를 꼼꼼히 보는 사람은 나였고, 결국 내가 처음부터 끝까지 하는 양상이였다. 코드를 치는게 어려운 게 아니라, 수정하고 commit하고 merge, merge 이후 수정 하는 것이 어려웠다. 늘 말하지만, 깃허브는 개발자의 편의를 위해 만들어지는 것이라고 들었는데.. 개발자라면 push pull push 반복작업을 100번씩 하는 거..

const { DataSource } = require('typeorm') const dotenv = require('dotenv') const jwt = require('jsonwebtoken') dotenv.config() // const myDataSource = new DataSource({ type : process.env.DB_TYPE, host : process.env.DB_HOST, port : process.env.DB_PORT, username : process.env.DB_USER, password : process.env.DB_PASSWORD, database : process.env.DB_NAME }) myDataSource.initialize() .then(() => { cons..

프로그래밍은 이해와 적용이다. 무슨 함수를 쓰는지 뜯어보아야 한다. 어떤 변수를 쓰는지 보아야 한다. 궁금해 하고. (그리고, 코드가 완벽하면 통신할 때 오류가 날 확률이 적은데 주니어의 경우는 대부분 코드의 문제이기에, 더욱 더 코드를 이해하고 분석해야 한다.) 수학 공식처럼, 함수를 만든 사람이 그렇게 하기로 약속을 하고 공식문서에 넣었기 때문에, 공식 문서에 가서 왜 쓰는지, 어디에 쓰는지 알아야 한다. 자, 이제 app.js를 시작해보자. const http = require("http"); --> http를 가져온다 const jwt = require("jsonwebtoken"); const userServices = require('./Services/userServices.js') const..

코드 분리를 이미 만든 한 파일에서 해보고, 한 branch에 올렸는데, 그 이후 바로 처음부터 여러 branch에 올리니 app.post("/login", 로 써야 할지, const signup. 으로 써야할지 연결하는 함수는 어디에 들어가야할지 헷갈렸다. 그래서 우선, 깃허브에 올라온 이전 팀의 동기 코드가 로그인 성공했다고 해서 참고했다. 일단, 나는 내 로컬에서 여러 branch를 다 올리기에 분업한 후 merge 하는 팀과는 방식이 달랐다. // 동기 -userservice (연두색 부분은 나에게 없던 것/ const { DataSource } = require('typeorm') const dotenv = require('dotenv') const jwt = require('jsonwebtok..

1. stand meeting 원래 10시에 하기로 했는데, 프론트분들이 늦게 오시거나 안 오셔서 점심 이후 2시에 했다. 어짜피 위워크에 있을 거니까 "아무때나 아무곳에서 보시죠" 라는 방식으로는, 나의 업무 우선순위와 계획에 어려웠다. 이동 동선도. "저 지금 1층에 있으니, 1층 오시죠 되실때." 로 하면 안 된다. 팀원들이 언제 어디로 움직일지 모르고, 나 또한 기다리고만 있는 처지가 되었다. 움직일 수가 없고. 그러기에, 시간 약속이 중요함을 깨달았다. 1-1. 장소는 몰라도, 시간을 꼭 정해놓을 것. 그래서 헤어지기 전에, "내일은 몇시에?"로 2시로 정해두었다. 구두로 얼굴 보고 약속을 정해두었으니 모든 팀원들이 지켜야지! 안 지킬 때 할 말이 있다. 1-2. 하지만, 10시에 standin..

이튿날: 대략적으로 한 것 어제 초기화 세팅을 완료, push 후 pr 했던 https://pm-developer-justdoit.tistory.com/85 초기화 세팅 pr 리뷰 및 commit, close , main에 merge와 로그인, 회원가입 함수를 담은 'userservices' branch 깃허브에 추가 생성 후, push, pr 요청까지 하였다. pr 리뷰 처음 해보았다. 주말에 foundation test로 깃허브 복습과 깃허브에 branch 생성 후 clone, push 하는 거까지는 했었다. Project1- 1. 초기세팅 PR 후 commit (1) --------------------- npm install express 하고나서는, 계속 npm install mysql mysq..

branch 가 push 하기 전까진, remote 깃허브에 안 나오고, 그렇다면, branch가 로컬에만 있고, 로컬에 있는 branch를 확인하기 위한 방법: ls -al 왜냐, 폴더, 파일은 안 나오지 않게 때문에 db에 필수 , 선택 다 구현해도 어짜피 프론트가 정보 안 주면 null 로 나올테니 db에는 칼럼 만들어져 있어도 됨 db에는 키 snake로 언더바로 하고, 프론트에 영향 없음. app.js 파일에서만 그 후에 pr 하는 방법은, new pull request가 아니라, 가장 아래로 내려서, commit 하면 (첫 push 이후 또 push) 아래에 1번 처럼 달리고, 2번처럼, 라벨을 달면 리뷰해주시는 분이 보고 해주실 수 있다. 2번째 push 후! (첫 commit 이후) 초기환..

팀 레포지토리에 초기세팅 branch 생성 후, push , pr 요청 후 pr리뷰를 받았다. 1. dependencies 설치npm install express 하고나서는, 계속 npm install mysql mysql2 typeorm cors bcrypt dotenv --save-dev 똑같이 해도 된다 설치 후엔 package.json에 무조건 들어왔는지 확인하면서! 2. 이메일의 중복 기입을 막을 수 있게 수정하여주세요! --> mysql 데이터베이스 속성 활용1) 이메일이 중복되지 않기 위해서, 데이터베이스에도 user 테이블에 email에 unique를 추가해야한다. CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, nickname VARCH..

[[ 프로젝트 초기 세팅 체크리스트를 하면서, 배운 것들]] 1. root 폴더 | 초기세팅시 진행사항 pull_request_template.md 상세하게 작성 .gitignore 에 다음의 자동생성 사이트를 이용하여 vim, macOS, node, linux, visualStudioCode, dotenv 등 포함 동일한 과정 [Express] .gitignore 생성 지금은 멘토님이 만들어주신 .gitignore 으로 들어가지 않아도 될 파일을 하는데, 프로젝트 할 때부터는 내가 직접 새로 .gitignore 생성해야하니. https://www.notion.so/wecode/Git-gitignore-24c8a014f7344c3a8899dd4e65 pm-developer-justdoit.tistory...

초기화 세팅 하면서 필요했던 과정 https://pm-developer-justdoit.tistory.com/85 dbmate 배경 테이블 만들 때, 데이터베이스 들어가서 만드는데, mysa데이터베이스 만들다가 문법 에러나거나 다시 수정해야 하면, 다시 처음부터 해야 하는데, 지금은 sql 문법에 익숙해져야 해서 그런건데, 귀찮음. 그것을 파일로 관리하는 방법이 있음. 테이블 100개를 만들 때, 데이터베이스에 들어가서 테이블 100개를 만들어놓으면 관리가 안 되니, 어떤 테이블을 어떻게 만들지 파일에 미리 정리를 해놓을 것! 예시. create table을 할 건데, users table을 만들 거고, id integar, name varchar, email varchar로 not null이다. 이 s..