PM에서 백엔드 엔지니어

내가 거의 깃허브 관리 담당이였다. 제대로 말하자면, 깃허브 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..

깃허브가 아니라, vscode에서 하는 것 app.js가 들어있는 폴더에, services라는 폴더를 만들고, 1. 그 안에 userService 파일 만든다. 이제 이 userService 파일 안에, 1-1. 회원가입 함수를 넣을 건데, app.post("/users", async (req, res) => { try { // 1. user 정보를 frontend로부터 받는다. (프론트가 사용자 정보를 가지고, 요청을 보낸다) const me = req.body; console.log(me); // 2. DATABASE 정보 저장. const { password, email } = me; //구조분해할당 (위랑 같은 거) // const password = req.body.password // emai..

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차 프로젝트에 시간이 많아서, 2차 프로젝트를 위한 준비를 하라는 거 같아서. 공부를! ngrok - 방화벽을 넘어서 외부에서 로컬 환경 (서버)에 접속을 가능하게 하는 터널 프로그램 Authtoken - 진행방식 팀 별 웹 서비스 선택 프로젝트를 위한 웹 서비스는 멘토진이 제시한 다양한 웹 서비스 중 하나를 선택하게 됩니다. 팀원 간 충분한 토의를 거쳐, 월요일 각자 기업 분석을 해 본 뒤, 선정한 기업에 대한 pet 분석을 노션에 제출 웹 서비스 선정 기준 설문 결과를 바탕으로 프로젝트에서 진행할 웹 서비스가 선정됩니다. 프로젝트는 웹 서비스의 다채로운 특징을 지니며 팀별 기획하에 새로운 기능을 담아낼 수 있는 사이트입니다. 준비 사항 발표 이후 팀원들끼리 해당 웹 서비스에 대한 충분한 토의를 하여..