깨끗한 코드

왜 코드는 깨끗해야 할까?

2~3년 정도 프로그램을 만들면서 신규 피쳐를 개발하고 버그도 개발(?)하고, 동료의 코드를 리뷰하고 내 코드도 리뷰하다 보면 어느 시점 그런 생각이 드는 때가 있다. 나에게 '코드 감각'이 있나?

(1) 나쁜 코드를 감지하고 (2) 깨끗한 코드로 바꿀 수 있는 능력이 내게 있는지 의문이 들었다.

그때쯤 클린 코드를 읽어야겠다고 다짐하게 된 사건(?)이 생긴다. 나의 생각과 다른 방향의 코멘트가 달렸지만 출처가 이름부터 '클린'한 코드여서 리뷰 반영을 안 할 수 없었고 무엇보다 이 책을 읽지 않았기 때문에 쉽사리 반박하지도, 반박할 근거를 찾지도 못하였다.

나의 코드가 클린 코드에 벗어난다는 리뷰가 달린 사건(?).jpg

지금껏 이 책을 읽지 않았다는 반성과 함께 내가 맞게 코드를 짜고 있는 것인지, 맞다면 그 근거는 무엇인지 알고 싶었다. 나 또한 코드의 근거를 마련하고 싶다는 생각이 들었다. 그리고 리뷰를 단 팀원은 내가 생각하기에 가장 '코드 감각'이 좋은 팀원이었다. 나는 그가 생각하는 흐름을 알고 싶었다. 그러려면 무엇보다 이 책을 읽어야 했다.

그래서 오래전 구매해 두고 고대로 벽장에 모셔놓아 본래의 용도로 사용되지 못하고 장식품이 된 <클린 코드, 애자일 소프트웨어 장인 정신>을 집어 들었다. 이름처럼 너무나도 깨끗한 책을 바라보며 '내가 너무 늦게 온 건 아니지? 이젠 네 빛을 발할 때야... 삐지지 않았다면 누나(?) 좀 도와줘...'라고 중얼거리면서.

경건한 마음가짐으로 책을 펼쳤기 때문에 서문부터 꼼꼼히 읽기 시작했다. 그리고 얼마 지나지 않아 나의 의무를 상기시키는 문장을 만났다. 

우리 개발자들에게는 체크아웃해 코드를 꺼낼 때보다 체크인해서 코드를 넣을 때 더 깨끗한 상태로 만들어야 할 의무가 있다.

뜨끔했고 곧바로 과거를 돌아봤다. 예상보다 훨씬 일찍 와버린 반성의 시간. '나의 PR은 항상 merge 되기 전보다 후가 낫도록 생성되었나? 괜히 더 유지보수하기 복잡한 코드 덩어리를 양산한 건 아닌가?' 책에서 유지보수를 유기한다고 표현한 것이 인상 깊었다. 개발자가 코드를 깨끗한 상태로 유지하지 않는다면 그것은 직무 유기다!

코드를 깨끗하게 유지하기 위해서는 세세함에 주의를 기울이는 것이 중요하다. 그리고 이 태도를 단순히 코드를 짤 때뿐만 아니라 삶을 대하는 태도와도 연결시키는 추천사 대목을 읽으며 철학 덕후인 나는 마음이 조금 웅장해졌다. 

정리 (= 조직, 정렬) : 적절한 이름을 지어 붙이다. 내가 그의 이름을 불러주기 전에는...

정돈 (= 단정함, 체계화) : 글자 그대로 모든 악을 퇴치할 치료약이다. 물건마다 모두 제자리가 있다.

청소 (= 정리, 광내기) : 히스토리(과거)나 TODO(미래)를 기억하는 주석은 제거하기 바란다.

청결 (= 표준화) : 청결은 경건과 마찬가지다. 집이 아름다워도 책상이 지저분하면 아름다움이 반감된다.

생활화 (= 규율) : 작은 것에도 충실한 사람이 큰 것에도 충실하다. 오늘 할 일을 내일로 미루지 마라.

백이면 백 다 좋은 말만 담긴 가치들을 읽고 있으니 '암암 그렇고 말고' 연신 고개를 끄덕이며 동의할 수밖에 없었다. 작은 것에도 충실한 사람, 부지런한 사람 나도 되고 싶다는 생각이 들 때쯤 이미 책에 설득되었단 걸 깨달았다. '그래서 클-린한 코드 어떻게 짜는 건데! 클린 한 게 뭔데!'

깨끗한 코드는 무엇이라고 정의할 수 있을까? 

보기 즐거운 코드 (= 읽기 쉬운, 가독성이 좋은)

논리가 간단한 코드 (= 효율적인)

철저한 오류처리를 한 코드 (= 세세한) ex. 메모리 누수, race condition, 네이밍을 고려한

설계의 의도가 드러나는 코드 ex. 명쾌한 추상화, 단순한 제어문

고치기 쉬운 코드 (= 테스트 케이스가 있는)

주의 깊게 작성한 코드 (= 손댈 곳이 없는)

중복이 없는

한 기능만 수행하는

짐작한 기능을 그대로 수행하는

'clean'이라는 단어에 이렇게나 많은 가치가 함축되어 있다니!

사실 나쁜 코드로 치르는 대가는 이미 경험으로 알 수 있었다. 개발 속도를 떨어트리고 팀 생산성을 떨어트린다. 그럼 왜 나쁜 코드를 만들었을까? '일정이 촉박해서', '요구사항이 갑자기 바뀌어서' 모두 이유가 되지 못한다. 내가 전문가 답지 못했기 때문이다. (당연하게도) 일정과 요구사항을 강력하게 밀어붙이는 것은 동료의 책임이고 좋은 코드를 사수하는 것이 프로그래머의 책임이라는 부분에서 나는 당연하지 않게 일해왔다는 죄책감이 들었다. 

세세함에 주의를 기울이는 것이 전문가에게 왜 필수적인 자질이 되었는지 알게 해 준 대목

더 본질적으로 접근해 보자. 왜 코드는 깨끗해야 할까? 짜기 위해선 읽어야 하기 때문이다. 주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 깨끗하게 코드를 짜지 않으면 짜는 행위보다 읽는 행위에 더 많은 시간과 노력을 할애해야 한다. 급하다면 급할수록 서둘러 끝내기 위해 읽기 쉬운 코드를 만들면 된다. 그리고, 읽기 쉬운 상태를 유지해야 한다. 자연스럽게 '코드 리뷰를 왜 해야 하는가?'에 대한 해답도 얻었다. 동료의 코드에 적극적으로 나서 코드의 퇴보를 막기 위함이다. 체크인해서 코드를 넣을 때 더 깨끗한 상태로 만드는 것이 프로그래머의 의무이기 때문이다. 그렇지 않다면 직무유기.. 이니까 흠흠.