이 블로그와 글의 시작의 이유

어느새 개발자로 일한지 6년이 다되어가고 있다. 그동안 "일은 돈을 벌기 위해 할 뿐, 그 이상도 그 이하도 아니다." 고 생각하며 살았다. 맹목적으로 좇은 덕인지 모르겠지만, 운 좋게도 작은 성공들이 이어져 지금은 충분히 먹고 살만해진 삶을 살고 있다. 다만, 그러고나니 조금은 공허해졌다. 나이와 학력, 커리어에 비해 연봉도 괜찮고 나쁘지 않은 대우를 받고 있지만, "나는 정말로 좋은 개발자인가?" 의문이 들기 생각했다. 그 와중에 생각난 3년전에 사둔 책을 읽고 감명깊게 읽은 부분을 공유하려고 한다. 사놓았던 책은 훌륭한 프로그래머 되는 법 이다. 개발자라면 누구나 다 아는 동물책 시리즈이다. 지금은 절판된 것으로 보인다.

내가 이렇게 글을 써 공유하는 것이 누군가에겐 의미가 있기를 바란다.

1장. 코드에 신경쓰기

지옥에 보내버려야 할 코드 역시 좋은 의도로 포장되어 있다.

업무를 하다보면 이런 코드를 정말 많이 보게 된다. 이런 코드가 수익을 내고 있기도 하기 때문에 쉽사리 버리지도 못한다. 유지보수할 일이 생기면 덜컥 겁부터 난다. 내가 만든 코드가 아니라고 떠넘기고 싶지만, 만든 사람은 이미 퇴사했을 가능성이 높다. 상위자에게 이 똥은 내가 건드리고 싶지 않다고 말하고 싶은 마음이 굴뚝같지만, 조금만 진지하게 고민해보면 고칠수 있다. 해당 기능의 의도를 파악하고 재작성하는 것이 좋다.

코드에 대한 감정적 반응은 잘못된 것이 아니다. 훌륭한 결과물을 자랑스러워하거나 더러운 코드에 혐오감을 느끼는 것은 자신이 건전하다는 증거다.

코드 리뷰를 하다보면 감정적인 대화가 오고가기도 한다. 댓글로 시작해서 실제로 소리지르며 싸우기도 한다. 어쨌든 냉철하게 깔끔하고 명확한 코드를 작성하면 된다. 그러면 서로 또 좋아한다. 개발자들의 이상한(?) 행태이다. 다만 싸움은 피하는 것이 좋다. 개발자들끼리는 싸웠다고 생각하지도 않는데, 인사 평가상 불이익은 있을 수 있다.

2장. 정돈된 코드 유지하기

보기 좋은 코드는 의도를 드러낸다. 그것은 예술이 아니다.

좋은 코드는 들여다보는 순간 의도와 의미를 파악할 수 있다. 개발자들이 메서드 명과 변수 명에 가장 많은 고민을 하는 것은 괜한 것이 아니다. 보기에 좋은 코드가 이해하기도 좋고 실제 버그도 없을 확률이 99%이다.

깔끔하게 글을 쓰고 싶다면, 먼저 생각을 깔끔하게 정리하라.

요한 볼프강 폰 괴테의 말이다. 물론, 이 책에도 나온다. 구조를 잘 잡아야하고, 일관성이 있어야한다. DAO(Data Access Object)에서 메서드 명이 find로 시작하면 Option Object를 리턴하도록 하고, get으로 시작하면 Object 나 Object List를 리턴하게 하는 것은 나의 일관성이다. 통일함으로써 깔끔하게 사용할수 있도록 했다. 메서드를 사용하는 입장에서도 메서드 명만 봐도 리턴 타입을 알 수 있어, 일관된 코드를 작성하는데 도움이 된다.

어떤 단어를 사용할 때, 나는 뜻하는 바를 나타내는 단어를 고르지. 그 이상도 그 이하도 아냐.

<이상한 나라의 앨리스> 한 구절이다. DataObject 라는 클래스는 무엇을 나타낼까? 사람인지 동물인지 알 수 없다. 간결하기 전에 명확해야한다. 그리고 반복을 줄여야 한다. NumberList 라는 클래스에 numberCount 라는 메서드 명은 동어 반복일 뿐이다. count 또는 size 정도의 메서드명이어도 충분하다.

기능 변경과 모양 변경을 동시에 하지 말라.

작업을 하다보면 어려운 부분 중에 하나다. 기능 변경을 하다보니 코드가 정리되는 경우도 있고, 코드를 정리하지 않으면 기능 변경을 시작할수 없는 경우도 있다. 리뷰어의 입장에서 이해할수 있도록 하기 위해서는 기능 변경과 코드 정리가 별개의 커밋으로 나뉘어야한다. 가장 베스트는 브랜치를 이어 만들어서 정리하는 것이다. 이럴 경우 PR(Pull Request)도 별개로 요청하고 받을 수 있다.