1 minute read

nil

아침에 출근하면 가장 먼저 하는 일. 전날 커밋된 코드를 읽는다. 물론 읽는 건 내 코드가 아니라 동료가 커밋한 코드.

처음에는 코드를 읽을 때, 2~3시간을 썼다. 코드를 읽는 것도 중요하지만 이렇게 시간을 써버리면 곤란하다. 왜냐하면, 아직 내 역할은 코드 품질 유지보다는 생산 쪽이기 때문이다. 물론 모든 프로그래머는 둘 다 신경을 써야 한다. 하지만 역할이 한쪽으로 더 치우쳐 있기 마련이다. 현재 나는 생산 쪽에 더 치우쳐 있다. 그래서 원칙을 세웠다. 길어야 40분. 초과하면 커밋 코멘트만 보거나 내 업무와 연관된 코드만 읽는다.

다른 사람이 짠 코드를 많이 읽어라. 참 많이 듣는 조언이다. 경력이 쌓이면 으레 이런 조언을 한다. 코드를 많이 읽는 프로그래머도 이런 조언을 하고 안 읽는 프로그래머도 이런 조언을 한다. 그래 왜 읽어야 하는지 설명을 안 해도 될 만큼 모두 중요성을 알고 있다. 자~ 이제 유명한 오픈 소스 프로젝트를 찾아보자. 하지만 가까운 데도 금광이 있다. 바로 나와 같이 일하는 동료가 짠 코드. 코드를 읽는 능력도 향상되고 업무에도 바로 도움이 된다. 우선 동료 코드를 읽는 것부터 시작하자.

이렇게 짜니깐 쉽게 읽을 수 있구나. 이런 문제를 나는 되게 어렵게 풀었는데, 이렇게 우아하게 해결할 수 있구나. 이건 처음 보는 단어다. 사전으로 찾아보니 이런 뜻이 있네. 이 단어 적절해 보인다. 등등을 나는 지난 1년간 동료 코드를 읽으면서 배웠다. 정말 읽기 힘든 코드가 있기도 한데, 자책을 안 해도 된다. 그 코드는 당사자도 1~2주 후면 읽는데 애를 먹을 것이기 때문에.

여기에 덧붙여 같이 일하는 동료 성향을 알 수도 있다. 빠르게 해결하고 반복하면서 품질을 높여가는 동료. 느리지만 견고하게 문제를 해결하는 동료. 속도 우선. 견고함 우선. 이후 막혔을 때, 성향을 파악하고 있으면 조언을 구하기도 좋다.

그리고 팀 퍼포먼스도 알 수 있다. 내가 읽을 수 없는 양이 커밋되는 게 맞는데, 읽을 만하다. 와! 내 실력이 좋아졌구나. 하지만 착각이다. 팀 퍼포먼스가 낮아질 때, 이런 현상을 겪는다.

아침에 코드를 읽는데, 쓸 시간이 부족했다. 그래서 바로 업무를 시작하려고 했는데, 너무 찝찝하더라. 아~ 습관이 만들어졌구나. 2011년 말에 시작했으니 1년이 조금 넘었다.

이렇게 매일 보다 보면 왜 체크인 전에 diff를 떠야 하는지 알게 된다. #훌륭한습관 코드 commit(submit, check-in) 전에 diff 에서 썼듯이 커밋 전에 diff를 떠보는 걸 강조하는 것도 코드를 읽는데, 너무 방해되기 때문이다.

Update <2022-05-21 Sat> 표지 사진 링크가 끊겨서 사진 변경

링크