Wecode - Project 1 (부트캠프)/Project 1 과정

Project 1 - 4일차 : 깃허브 branch 문제해결 [1차 시도]/ 코드 질문 / '본질에 집중'

JBS 12 2023. 9. 15. 07:25

내가 거의 깃허브 관리 담당이였다.

 

제대로 말하자면, 깃허브 branch에 분리해서 코드를 올리는 사람.

 

즉, 코드도 치고 올리는 사람.

 

팀원들이 코드를 주긴 하는데, 틀린 코드도 있고

실행하는 사람은 나이고

pr 후 commit 을 하는 사람은 나이고,

merge 후 복잡한 문제를 안고, branch copy /생성 후에 새로운 branch를 생성할 사람은 나 이기에,

문제를 꼼꼼히 보는 사람은 나였고,

결국 내가 처음부터 끝까지 하는 양상이였다. 

 

 

코드를 치는게 어려운 게 아니라, 

수정하고 commit하고

merge, merge 이후 수정 하는 것이 어려웠다.

늘 말하지만, 깃허브는 개발자의 편의를 위해 만들어지는 것이라고 들었는데.. 

개발자라면 push pull push 반복작업을 100번씩 하는 거라고. 귀찮겠지만. 

 

그리고 주니어는 코드가 제대로 되어 있다면 

conflict가 충돌이라 해서 말이 그렇지, 개발자라면 피할 수 없고

괜찮다고. 

 

코드는 고칠 수 있는데, 깃허브에서 충돌 난 것도 

이미 엎지러진 물로 고칠 수 없는지 알았는데

고칠 수 있다고.


연차이신 멘토님을 기다리며, 질문집을 작성한..
다음날 오셔서도 바쁘셔서, 질문 가능한 시간 여쭤보고,
그 시간 직전에 저 잊지 말아달라고 하는 
집요함! 
공부는 집요하게  끈질기게 해야지! 

 

 


문제1-1  초기세팅 Branch 에 user branch가 올라간 것

 

branch를 여러 개 쓸 때에는, 무조건 

 

main으로 돌아가서, 

 

main에서 출발해서 branch a, 다시 main으로 가서 branch b 

branch c 가고 싶으면 다시 main에서 출발하고 

그러면, 

여러 branch를 이용해도, 아무런 영향을 받지 않는다. 각자 독립적인 branch이기에.



초기세팅+ user는 어짜피 로그인 합쳐질꺼니까 괜찮은데, 



문제1-2  user Branch 에 post branch가 올라간 것

 


만약, 또 copy 하면 (입문자에겐 고행이지만, 단련)

그러면 post branch 에 post + [user (+ 초기세팅)] 다 있게 되는데… 

Post branch에 user service있는건, 후속이니까 괜찮은데 
User branch에 user + post branch 있는 건 아쉬움. 

그렇기에 branch 를 새로 생성 후에, 다시 push (1. 새로 만든 branch에 2. 초기화를 pull 받아서 3.거기에서 수정해서 다시 push ) 

(개발자는 원래 항상 push pull 반복) --> 용기 얻고 포기하려다가 다시 하게 됨

 

문제 2  merge 후에 미세하게 또 수정하고 싶다

 

—> (일단, 코드 백업/메모장에 넣고) 새로 branch 생성 후에, (올린 수정해야하는 코드) pull 받아서, 수정하고, 다시 push

현재 초기세팅 수정은 user branch에 들어가 있음.




만약, 모두가 다 하는 거였으면, 
Clone 받아서 
이미 팀원들이 했으면, merge 전이라면, 저 이거 해야 합니다 column 추가해주세요 라고


merge 후 수정 = branch 파서 

거기에 clone (pull) 받고 수정해서 다시 push 

- 다운 받아야할 부분은 초기화 부분만. 

 

그런데, 새로 clone 받을 때처?

 

만약 merge 전이면, 내가 alter 파일 추가 하면 되는데, merge 했기에, 

 


문제 3. Dbmate 수정법 

- 원래는 migration file에서 수정하면 안 됨
- 원래 수정하고자 할 때는 alter file 생성해서 올려줘야 함
- 깃허브에는 반영됐지만, myslq에는 없는 이유는, schema_migrations; 들어가보면 버전 관리가 나오는데, 이렇게 계속 버전이 DONE 된거는 반영 안됨
- dbmate가 mysql 가지 않고 입력하는 편의는 맞지만, pending에 해당 되는 것에 해당/ 만약, pending이 아니라, done인 거는 쳐다보지도 않음

 

이후 설명을 토대로 혼자 해보면서, 어려움에 다시 멘토님 도움 요청

 

Project 1: 5일 차 오후: 깃허브 branch 오류 해결 (체리픽까지 나옴)

[1] 초기화 세팅에 들어가서, user service 작업 한 뒤에, 싸그리 다 push 해 버림 처음에 나는 초기화세팅 branch를 판 상태에서 초기화세팅 작업을 한 뒤, commit-push-pr 했다. 그 초기화 세팅 branch에서 user

pm-developer-justdoit.tistory.com


이후는 코드에 대한 질문이다 .

문제 4 

 

- 로그인 후에 return.res.status(400) json(err)는 global error handling 하는 거 아니면, 필요함
- 실패에 대한 response 받아주는게 없으니까



문제 5-1. Port Number 변수화-> .env


깃허브는 공용공간이고 지나가던 개발자 아무나 볼 수 있는 곳이니까, 
깃허브에 올라가는  .env.sample  와 app.js 에는 port number 변수처리 하고 
깃허브에 안 올라가는 .env 파일은 8000이라고 portnumber 써주기

아무 portnumber 모두 다 변수처리로 가능하다느 뜻이 아님. 숨김처리 하는 것. 공용 공간에서. 


- 그런데, .env 는 깃허브에 안 올라가는데도, 연결되나? // 깃허브는 코드를 올리는 것일 뿐이고, 서버는 돌고 있다. 

 

문제 5-5-1 

기본값으로 portnumber 안 들어갔을경우 8000 준다는 뜻 . env에서 가져와야 하니 .env.port 

 

const portNumber process.env.PORT || 8000;
const start = async () => {
  try {
    server.listen(portNumber, () => console.log(`Server is listening on ${portNumber}`)); 
  } catch (err) {
    console.error(err);
  }

 

문제 5-5-2 백팁 (option + ₩ )

server.listen(portNumber, () => console.log(`Server is listening on ${portNumber}`)); 

여기에 백팁 들어감 

 

 

문제 5-2-1. 토큰의 signature 이전엔 문자열 넣었는데, 

const token = jwt.sign({ id: existingUser[0].id }, env.TYPEORM_JWT); 

Env 파일에 tyeporm Jwt 가져와줘야 함 

이것 또한 signature key를 문자열이 아닌, 

Env. 파일에서 가져오는 이유는 / 숨겨주는 / 깃허브 공용 공간이니까

 

 

문제 5-2-2. 토큰의 signature 에 이렇게 쓰려면, TYPEORM 을 .env에 또 정의해야 함


문제 6-1. 아무 데이터 없을 때 빈 배열 가져오는 것은


If 으로 error handling도 하고, 
mysql에서도 NULL 로 이중장치 해줘야 좋음

보통은 if에 에러핸들링만 있는데, 둘다 해주는게 좋음 (unique처럼) 


문제 6-2. 포스팅 목록 조회는 read 인데


데이터를 왜 mysql의 create table에서 가져오느냐? Read table 이라는 거 따로 있어야 하는 거 아니냐?
 
Create table은 테이블 생성하는 sql 명령어인거고, 
별개. 



문제 6-3.  Threads read 목록 가져올 때,  select 구문에서 user_nickname을 가져오는지, user_id 를 가져오는지?


Mysql의 DB data에서 우리를 모두 가져다 쓸 수 있다.  
그렇기에, nickname을 가져와도 되고, userid를 가져와도 되는데, 
둘다 가져오는 것을 추천한다. 늘 둘다 하는 게 좋다. 


문제 6-4  보통 포스팅에서 목록 조회 하면 title이 나오는데, 

threads는 상품 특성 상, contents 인 것이냐?


기획하는 것에 따라 달라지는데, 위코드에서 그냥 편하게 ‘contents’ 로 주어진 것 
title도 모두 넣어도 무관하다. 

 

문제 6-5  inner join 뜻 

 

<FROM threads INNER JOIN users >

ON <threads.user_id = users.id> —> where 써도



문제 7. 우리가 맞는코드인지 확인하는 방법. 


과제에서 우리가 할 때는 postman에 프론트인척 get 한 뒤에, body에 우리가 정보를 쓰고, send한 뒤에
다시 백엔드가 하는 post, send 했는데

지금 이렇게 프론트랑 같이 하는데 
우리가 임의로 정보를 넣어서 테스트 해도 되느냐? 


--> 테스트하는거니까 괜찮다.



7번까지! 내가 준비한 질문은 악착같이 달라붙어서 다 했다! 다 알고 넘어가야 직성이 풀린다. 

그리고 잠시 3분만 주실 수 있느냐 해서, 상담도 했다.

 

1. 내가 branch 관리하고 분리해서 업로드 하는 게 맞는데

동기들이 모두 통신에만 목메고 

 

2. 제가 멘토님처럼 분석하고 뜯어보고, 구조를 이해하고 본질을 중요시하고 집중하는 스타일인데,

복기 복습 혼자 공부하는 시간도 없이

팀이 진도를 빼니,

어떻게 해야할지. 

 

코드도 깃허브에 올라온 다른 팀 보면, 

1) 다들 branch 분리 없이 통째로 올리고

2) 코드가 다 다르고, 틀린 것도 있고, 빠진 것도 있다. 

3) 그래서, 내가 잘하고 있는건데, 가치관이 다르다보니, 그들은 기능 구현과 통신에만 급급한데, 내가 본질에 집중해야 한다고 하면, 하기 싫어하는 사람처럼 비추어진다 

 

-->멘토님께서, 그래서 오늘 말했듯이 많이 쓰고 있는 본인이 쓰는 app.use가 어떤 뜻인지도 모른 채 쓰고 있는 거라고. 

중간에서 중심을 잘 잡아주고 

내가 무언가 안하는 거 같이 느껴진다 싶으면, 내가 팀을 위해서 가장 중요한 branch와 git 관리를 하고 있다고 어필하고

 

팀으로 인해,  
개인공부가 부족하다고 생각이 들고, 그렇다 싶으면 

잘 치고 빠지는 것도. 

 

다들 개발 처음해보니까
Api 기능 구현 신나겠지만, 

주니어 개발자들이 많이 하는 실수. 

본질에 집중
자주 쓰는 이게 뭔지도 모른채 그러는 것보다. 

 

모래 위에 세워진 누각이라는 '사상누각'이라는 말처럼,

기초가 튼튼하지 못하면 곧 무너지고 만다는 것. 

 

(내가 생각하는 바와 같아서,

내가 잘하고 있음에 

마음이 놓였다. 동기들에 영향 받지 않기로, ) 

 

3. 깃허브에 다른 사람들 코드 보면서 공부하는 건 괜찮음
대신, 그대로 베껴서 가져오기보다,

수업시간에 말한 거처럼,

내가 이 한 줄을 이해 못하면, 죽을 거처럼 코드 이해하고자 노력해야.

한줄 한줄