[🐕🐾 일기 1일차] 엥? 아직도 커밋을 안한다고?

혼자서 작업을 하다보면 수능 문제를 푸는 것 처럼 작업을 하게된다. 물론 벌써 수능을 본지 10년 정도가 되었지만 당시 학원 선생님이 이런 전략을 이용하라고 했다.

"한 문제가 막히면 다른 문제를 먼저 풀고 또 풀다가 막히면 넘어가고 마지막 페이지를 넘기고 나서 다시 별표친 문제를 다시 보아라."

 

 프로그래밍을 시작한지 얼마되지 않았을 때 나는 흐르는 강물을 거스르는 연어였다. 펄떡펄떡

일단 쉽게 구현할 수 있는 부분을 먼저 구현한 다음 다시 처음으로 돌아와 어려운 구현을 하는 방식으로 작업을 했다. 이런식으로 작업을 하면 작업이 빨라진다. 깊은 생각 없이, 구현할 수 있는 부분을 먼저 구현하기 때문에 작업 진도를 빠르게 칠 수 있다. 수능에서도 이런 전략을 사용했던 이유도 짧은 시간안에 많은 문제를 풀어야 했기 때문이다. 단점이라면  너무 자유로워서 하나를 구현하다 다음 것을 구현하고 또 그러다 다음 것을 구현하다보니 무한 츠쿠요미에 빠지게 된다는 점이다. 이런식으로 몇번 반복하다보면 내가 어떤 걸 하고 있었는지도 까먹는 지경에 이르른다. 커밋은 이런 부분을 예방해준다.

그게 뭔데 씹덕아..

물론 커밋도 오직 작업을 저장하는 용도로 한다면 다시 무한 츠쿠요미에 빠진다. 그렇기 때문에 아래의 과정을 꼭 지켜줘야한다.

 

1. 커밋 메세지를 먼저 생각한다.

2. 작업을 해본다.

3. 생각 보다 어렵다. => 커밋 메세지의 범주를 줄인다.

4. 생각 보다 쉽거나 예상대로다. => 커밋을 푸쉬한다.

 

이런 말이 있다. 커밋에서 가장 중요한 건 커밋 메세지를 먼저 생각하는 것이고 두번째로 중요한 건 첫번째를 기억하는 일이다. 내가 말했다.

어쨌든 이 작업하는 방식이 좋은 점은 연어이긴 하지만 인간이 만들어준 수로를 따라 가는 연어라는 점이다. 일단 해야할 일이 분명하기 떄문에 딴눈도 안팔고 먼저 직면한 문제를 풀게된다. 

 

하지만 커밋이 익숙하지 않은 사람이나 필요성을 아직 못느낀 사람들은 여전히 왜 그렇게 해야하는지 납득이 되지 않을 것이다. 이런 분들을 위한 특별 처방이 있다. 바로 협업이다. 사람들은 자신의 행동으로 자신이 손해를 보는 건 잘 참지만 남이 피해를 보는건 잘 견디지 못한다.

(좋은 사람이라면 말이다.) 여러분이 연어처럼 프로덕션 코드를 이리저리 오가며 산란해 놓은 코드를 보며 팀원들이 리뷰하기 난처하다는 뉘앙스만 보여도 당장에 다음 작업부터 커밋메세지를 먼저 고민하게 될 것이다. 

 

오늘의 한줄 평 : 연어도 좋지만 함께 갈 때는 로봇 물고기가 되자

프로덕트를 만드는 개발자들.. 터미널과 같은 눈