클린코드는 “Uncle Bob” 이라고도 불리는 Robert C. Martin 이 저술한 책이다. 이 책은 객체지향 코드를 구조적으로 깔끔하게 작성하는 방법과 이유에 대해서 설명한다. 개인적으로 “내가 이 책을 평생 읽지 않았다면 어쩔뻔 했나?” 라는 생각을 한다.
What does it say?
클린코드는 우리에게 코드를 구조적으로 깔끔하게 작성하는 방법과 그렇게 해야하는 이유에 대해서 샘플코드를 예시로 들며 설명해준다. 아래 나열된 카테고리들은 Robert C. Martin이 말하는 클린코드를 작성하는 대표적인 주제들이다.
- 한가지 함수는 한가지 동작만 잘 수행해야 한다(Once And Only Once)
함수는 한가지 동작만 수행하여 함수가 만들어진 이유가 명확하여야 한다. 함수를 사용하는 다른 사용자들은 함수명을 보고 한가지 동작만 이뤄질 것이라고 생각하기 때문에 시간이 지날수록 코드 내에서 Side Effects를 발생시킬 확률이 매우 높아지며 몇번의 Side Effects를 겪은 후에는 정의된 함수를 사용할 때마다 불신하며 코드를 일일이 까보고 사용하게 되기 때문에 개발시간도 더 늘어나게 될 수밖에 없다.
- 중복된 코드를 발견하면 코드를 리펙토링할 기회로 생각해라
중복된 코드는 하나의 함수로 정의되어야 하는 로직을 추상화하지 못한 케이스이며 중복코드의 발견을 현재의 코드를 더 개선시킬 기회를 얻었다고 생각하고 발견된 모든 중복을 없애야 한다. 만일 중복된 코드들 사이에서 약간씩 구조가 달라 한가지 함수로 정의하기 어렵다면 템플릿 메서드 패턴과 같은 디자인 패턴을 사용하여 중복 제거를 시도해 보아라. 사실 대부분의 디자인 패턴은 중복을 제거하는 패턴이다.
- 함수명은 의도를 명확하게 서술적인 명사로 표현하여야 한다
우리는 주로 여러명의 개발자들과 협업을 하여 서비스를 개발하게 된다. 만일 혼자 개발하는 개발자일 지라도 몇일 혹은 몇달이 지나면 자기가 개발했던 코드를 기억하지 못하게 된다. 그러므로 우리는 함수명을 정의할 때 함수가 하는 동작을 명확하게 서술할 수 있는 이름을 지어주어야 한다.
- 함수를 작게 더 작게 만들어라
함수는 최대한 작게 만들어 한눈에 파악할 수 있도록 하는것이 좋으며 만일 함수 하나에 코드가 길다면 이 함수가 과연 한가지 동작만 하는 것인지 의심해 봐라.
- 함수 인수
— 함수 인수는 적을수록 좋고 없는게 가장 좋다. 왜냐하면 인수는 함수의 개념을 이해하기 어렵게 만든다.
— 플래그 인수를 사용하지 마라. 플래그 인수가 있다는 것은 한 함수 내에서 두가지 동작을 수행한다는 반증이다. 이럴 경우 함수를 쪼개어 정의하라.
- 점진적인 리펙토링
좋은 코드는 한번에 나오기 힘들다. 그러므로 개발한 코드나 구조가 이상하다고 생각이 들어도 자책할 필요 없다. 한번 작성해서 코드가 동작한다고 개발이 끝난게 아니라 점진적인 리펙토링을 통하여 코드와 구조를 개선시키는 작업을 통하여 우리는 항상 더 좋은 코드를 얻어야 한다.(떠날 때는 찾을 때 보다 깨끗이 하라)
- 위에서 아래로 서술하듯 코드를 작성해라
앞서 말했듯 우리는 항상 협업한다. 또한 내가 작성한 코드라고 하더라도 금방 까먹게 되고 우리는 그것을 수없이 겪어왔다. 그렇기 때문에 우리는 내 코드를 보는 사람들을 생각하며 어떻게 하면 이해하기 쉬운 코드를 작성할지 고민하여야 한다.
- TDD(Test Driven Development)
작성한 코드는 모든 테스트 케이스를 통과하여야 한다. 통과하지 못한 테스트 케이스가 있다면 결함이 있다는 증거이며 리펙토링 대상이다. 그러므로 테스트를 게을리 하지 마라.
ps. 사실 TDD는 이 글을 쓰고있는 나조차 제대로 지키지 않는 부분이다. 앞으로 꾸준히 업무에서나 사이드 프로젝트를 진행하면서 테스트 주도 개발(TDD)를 해야겠다.
What do I think?
개인적으로 느끼기엔 코딩에는 정답이 없다는 말과 상반되는 듯한 의견을 전달하는 책이었다. 테스트 주도 개발을 적용하며 확실한 규칙들이 정해져있는 코딩 컨벤션을 최대한 지키고 그 안에서 움직이며 점진적인 리펙토링을 하는 습관을 들여 항상 더 좋은 코드를 얻어야 한다는 메시지를 내게 주었다. 이 책에서 말하는 코딩 컨벤션과 내 생각이 상이한 2가지 이론도 있었다.
- 함수 인수는 없는게 적을수록 좋으며 없는게 가장 좋다. 그리고 4개가 넘어갈 경우 정상적으로 짜여진 함수가 아닐 확률이 높다.
— 인수의 유무 또는 인수 갯수가 설계가 잘 된 함수인지 아닌지 판단하는 기준이 되지 못한다고 생각한다. 왜냐하면 함수가 동작 할 때마다 바뀔 설정 값들이 있을 것이라 생각하기 때문이다. 하지만 나 또한 인수가 4개 이상 넘어가는 함수의 경우 설계가 잘못되었을 확률이 높다고 생각한다.
2. 떠날 때는 찾을 때 보다 더 깨끗이 하라.
— 조직마다 혹은 개인별 성향에 따라서 상대방의 동의 없는 코드 리펙토링을 바라보는 관점은 매우 다를 수 있다. 물론 개발자라면 복잡한 구조의 혹은 잘못 설계되었다고 생각이 드는 코드를 발견했을 때 리펙토링 하고싶은 요구가 마구 솟구칠 것이다. 떠날 때는 찾을 때 보다 깨끗이 하면 좋겠지만 사전 동의없는 무분별한 수정은 좋은 결과를 가져왔다 하더라도 충분히 트러블을 일으킬만한 사안이며 이전에 충분한 협의와 서로 해당 로직에 대한 생각을 주고받는 코드리뷰가 동반되어야 한다고 생각한다.
위의 2가지 항목을 제외하면 모든 부분은 이 책이 말하는 방향대로 개발을 해야한다는 생각이 들었고 지금도 클린코드(깨끗한 코드)를 작성하려고 실무에서나 사이드 프로젝트 개발을 할때나 항상 의식하려고 노력 중이다. 물론 아직 TDD(테스트 주도 개발)은 학습을 더 하며 적용해야 할 것 같다.
Who should read the book?
사실 이 책은 개발자라면 아직 읽지 않은 모든이가 읽어야 한다고 생각한다. 개발자라면 남녀노소 누구에게나 도움이 될 수 밖에 없는 공통적인 주제를 다루며 코드 작성에 대한 기본적이면서도 꼭 알아야 할 내용들을 다루고 있으며 이 책에서 말하는 규칙들을 다 지키며 개발 한다면 좋은 코드가 나올 수 밖에 없을거라 나는 생각한다.
Conclusions
나는 아직 부족한게 많은 주니어 개발자이다. 특히 이번에 이 책을 읽으면서 더더욱 뼈저리게 느낄 수 있었다. 나와 같은 혹은 나보다 훨씬 실력이 월등한 개발자라도 아직 이 책을 보지 않았다면 이 책을 보면서 분명히 반성을 하게 될 것이라고 생각한다. 물론 이 책 서론에서 Robert C. Martin이 미리 말했듯 클린코드에서 말하는 여러 방법론 중에는 논란의 여지가 될만한 부분도 존재한다. 코딩에는 정답이 없듯이 앞으로도 Robert C. Martin을 포함한 유명 개발자들의 방법론들도 모두가 우리에게 완벽한 정답을 주진 않을 것이다. 나는 그것 또한 코딩의 매력이라고 생각하며 언젠가는 내가 더 나은 방법론들을 개발자들에게 소개할 날이 올 수도 있다고 생각한다.
