Today 요약

1. 자바스크립트 강의
2. 발표 준비
3. Git Flow와 코드리뷰

1. What I did?

1.1 발표 준비

주특기 팀이 정해지고 CTO로 정해지고 난 뒤에, 정기 팀회의에서 발표할 주제들을 정하고 날짜도 정했다. 이런 건 그냥 의논하기보다는 어느 정도 주도하에해야 빠르게 진행될 것 같아서, 내가 대부분 정했다. 그렇게 어제 정하고나서 아무래도 내가 CTO니까 먼저 발표를 시작해야 할 것 같아서 시작했고, 주제 같은 경우에 큰 분류에 대해서는 슈퍼코딩에서 어느 정도 정해주었기에, 나 같은 경우 GIt Flow와 코드리뷰에 대해서 조사해보고 발표하면 되는 것이었다. 그래서 오늘 거의 하루종일? 오전 11시분터 오후 4시까지 발표준비 하느라 분주했다.

그런데 그렇게 하면서 느낀 건, 확실히 시간을 오래 걸리지만 그냥 단순하게 구글링하고 넘기는 것보다는 머릿 속에 잘 들어오는 것 같았다. 아무래도 내가 다른 사람들한테 발표를 해야하는 입장이니까 좀 더 청중을 쉽게 이해시키려면 내가 제대로 확실하게 이해해야 하기 때문일 것이다.

하루 만에 엄청 퀄리티 있는 발표를 할 수는 없겠지만, 그래도 나름 청중을 고려해서 능력 껏 잘해보자. 지금은 실패를 많이 해봐야한다. 결국 주 무대는 취업 이후인데, 여기서 못한다고 해서 주눅들 필요도 없고 뭐가 잘못되는 것도 없다. 그러니 기회가 될 때 많이 도전해보자.

2. What I Learned?

2.1 자바스크립트 강의

함수

• 함수 선언문은 문이기 때문에 변수에 할당할 수 없다. 하지만 함수 표현식을 보면 문이 변수에 할당되는 것처럼 보인다. 이는 { } 코드블록이 문맥에 따라 자바스크립트 엔진이 다르게 해석하기 때문에 가능한 일이다. { } 코드블록을 해석 할 때, 함수 선언문으로만 선언되어 있으면 문으로 판단하고 함수 표현식으로 선언되어 있으면 변수에 할당할 수 있도록 해석한다.

  • 함수 선언문은 코드가 실행되기 전에 호이스팅되며, 변수에 할당되지 않는다. 함수 이름과 함수 본문이 함께 존재하며, 이를 통해 어디서든지 함수를 호출할 수 있다.
  • 함수 표현식은 변수에 함수를 할당하는 방식으로 작성된다. 이때 변수에 할당되기 때문에 변수 이름을 통해서만 함수를 호출할 수 있다. 함수 표현식은 코드가 실행되는 시점에서 할당이 이루어진다.

• Function 생성자 함수로 생성한 함수는 클로저를 생성하지 않는다.

• 화살표 함수는 생성자 함수로 사용할 수 없으며 기존 함수와 this 바인딩 방식이 다르고, prototype 프로 퍼티가 없으며 arguments 객체를 생성하지 않는다.

  • 화살표 함수는 인자가 하나면 괄호도 생략이 가능하다.

function add(x, y) {
  console.log(arguments)
  // Arguments(3) [2, 5, 10, callee: f, Symbol(Symbol.iterator): f]
  return x + y
}
add(2, 5, 10)

함수의 인자를 정해진 개수만큼이 아니라 초과해서 호출하면 Arguments 객체에는 담겨있지만, 실제로 사용되지는 않는다.

• 즉시 실행 함수는 단 한 번만 호출되며 다시 호출할 수 없다.

2.2 Git Flow

오늘 발표준비를 하면서 Git Flow에 대해 알아보는데, 예전에 정말 간단하게 검색해봤을 때는 브랜치 전략이 하나만 있는 줄 알았다. (그걸 봤으면서도 사실 그때는 그 전략을 쓸 생각조차 하지 않았음..) 하지만 오늘 알아보면서 브랜치 전략이라는 것도 반드시 그대로 따라야 한다는 것도 아니고, 특정 상황에 맞춰서 하면 되는 것 같다. 즉, 자기 환경과 팀의 환경에 맞춰서 하면 된다.

결론부터 이야기하면 나는 기존에 GitHub Flow 방식으로 평소에 했던 것 같다. 두 가지에 대해 간단하게 짚고 넘어가자면 Git Flow 방식은 규모가 있는 프로젝트나 다양한 버전을 유지하고 관리해야 하는 경우에 브랜치가 목적성을 확실히 가지고 있어서 각 브랜치에 맞게 확실한 규칙성을 가지고 있는 방식이라고 보면 될 것 같고, GitHub Flow는 Git Flow방식은 좀 더 그것보다는 유연하게 관리할 수 있는 전략이다. 그렇기 때문에 좀 더 소규모 프로젝트나 버전관리가 크게 필요없는 상황에서 사용하는 걸 권장한다.

Git Flow 전략은 메인 브랜치로 관리되는 Master, Develop 브랜치와 서브 브랜치로 관리되는 Feature, Hotfix, Release 브랜치로 나누어서 개발한다.

GitHub Flow 전략은 Master를 메인 브랜치로 Topic 브랜치(Feature가 될 수도, Hotfix가 될수도 있다.)를 서브 브랜치로 나누어서 개발한다.

한 마디로 Git Flow는 좀 더 디테일하게 관리하고 GitHub Flow는 유연하게 관리한다고 생각하면 된다.

그렇기 때문에 실제로 개인적으로 개발하는 토이프로젝트의 경우 Git Flow는 좀 과하다는 생각이 든다.

브랜치가 많아질수록 복잡하다는 느낌을 지울 수가 없다. 그렇기 때문에 앞으로 팀으로 프로젝트를 진행하지 않는 이상은 GitHub Flow를 따라갈 것 같고, 앞으로 동아리에서 팀으로 프로젝트를 진행한다면 GIt Flow를 따를지 GitHub Flow를 따를지를 논의하고 결정하면 될 것 같다.

2.3 코드 리뷰

코드리뷰에 대해서는 그동안은 그냥 F-Lab에서 멘토님이 코드 리뷰해줬던 것만 기억하고 그렇게만 알고 있었는데, 이번에 조사하고 알아보면서 깃허브에서 단순하게 주고 받았던 것 이상으로 코드리뷰에 대해서 많이 생각하고 팀이 아니라 개인적으로 프로젝트 할 때도 나만의 기준을 세우는 게 중요하다는 생각을 했다. 그래서 코드리뷰를 받기 전에 나만의 체크리스트를 만들어놓고 먼저 체크리스트에 맞춰서 코드를 작성했는지 확인한 뒤에 코드리뷰를 받도록 해야 한다.