CleanCode 1장 깨끗한 코드

"클린 코드"라는 책을 통해 사내 스터디를 하였다. 클린 코드라는 책을 선택한 이유는 개발자가 꼭 읽어야 할 책들 중 하나였고, 더 좋은 코드를 작성하기 위해 읽게 되었다. 출처: 인사이트, 글쓴이: 로버트 C. 마틴

출처: 인사이트

깨끗한 코드가 왜 중요할까?

---

이 책에서 나온 내용의 일부이다. 80년대 후반 킬러 앱 하나를 구현한 회사가 있었고, 큰 인기를 끌었으나 새 버전에 대한 출시가 점점 늦어지고 이전에 발견됐던 버그가 그대로 남아있는 문제가 있었다고 한다. 그 회사는 얼마 못가 망했고 후일 책의 저자가 망한 회사의 초창기 직원을 만났을 때에 들은 이야기는 "초기 코드를 마구 짰고 갈수록 엉망이 되어 감당이 안되었다"라고 했다고 한다. 이 글을 읽으며 나는 깊이 공감하였고, 나 자신이 짰던 코드들을 돌아보게 되었다.

 

 

태도

---

우리는 코드를 짤 때에 항상 코드에 전문가다운 태도를 취해야 한다. 코드가 잘못됐다면 모두 개발자의 잘못이기 때문이다. 때로는 촉박한 개발 일정에 쫓길 수도 있다. 그러나 우리는 시간에 쫓기더라도 좋은 코드를 짜야한다. 좋은 코드를 사수하는 것이 프로그래머들의 책임이기 때문이다.

 

책에서는 이런 비유를 하나 들었다. 자신이 의사라고 가정해보자. 어느 환자가 수술 전에 손을 씻지 말라고 요구했다. 손 씻는데 시간이 걸리기 때문이다. 그렇지만 의사는 단호하게 거부한다. 왜? 당연하다 질병과 감염의 위험은 환자보다는 의사가 더 잘 알기 때문이다. 환자의 말을 그대로 따르는 행동은 전문가 답지 못하다.

 

우리 프로그래머들은 코드의 전문가다. 좋은 코드를 짜고, 좋은 아키텍처를 설계하고, 더 좋은 성능을 위해 고민하는 것이 이 분야의 전문가인 우리 프로그래머들이 해야 할 일이다. 시간이 촉박한 것 이해한다. 그러나 우리는 전문가답게 좋은 코드를 짜기 위해서 항상 공부하기를 노력하고, 생각하기를 노력해야 한다.

 

 

깨끗한 코드

---

"깨끗한 코드를 어떻게 작성할 것인가?" 이 책에서는 깨끗한 코드가 무엇인지 모르면 작성할 수 없다고 말한다. 또한 깨끗한 코드를 구분할 줄 안다고 해서 작성할 줄 아는 것은 아니라고 한다. 즉, 쉽게 말하자면 "내 방의 디자인이 엉성하고 복잡한 것은 알겠으나 그걸 치우고 아름답게 꾸미는 것은 다른 문제다."라는 말이다. 그렇다면 깨끗한 코드란 무엇일까? 이 책에서는 여러 노련한 프로그래머들에 의견을 구했고 그들의 말 중 몇 가지를 정리해봤다.

 

비야네 스트롭스트룹

논리가 간단해야 버그가 숨어들지 못한다. 의존성을 줄여야 유지보수가 쉬워지며 오류는 명백한 전략에 의해 처리되어야 한다. 성능을 최적으로 유지해야 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 코드는 한 가지를 제대로 한다.

 

그래디 부치

깨끗한 코드는 단순하고 직접적이다. 아주 잘 쓴 문장처럼 읽힌다. 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.

 

빅 데이브 토마스

깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미 있는 이름이 붙는다. 의존성은 최소이며 각 의존성을 명확히 한다. 특정 목적을 달성하기 위한 방법은 하나만 제공한다.

 

마이클 페더스

깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 주며 고치려 하면 언제나 제자리로 돌아온다.

 

론 제프리스

모든 테스트를 통과한다. 중복이 없다. 시스템 내 모든 설계 아이디어를 표현한다. 클래스, 메서드, 함수 등을 최대한 줄인다.

 

워드 커닝햄

코드를 읽으면서 짐작 했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드이다.

 

 

노련한 프로그래머들이 했던 말들은 모두 피가 되고 살이 되는 말들을 요약해보면 아래와 같다.

• 깨끗한 코드는 단순해야 한다.
• 모든 테스트 케이스가 존재하고, 통과해야 한다.
• 코드에 설계자의 의도가 드러나며, 짐작했던 기능을 수행한다.
• 오류는 명백한 전략에 의해 처리가 되어야 한다.

많은 조언들 중 "깨끗한 코드는 단순해야 한다"라는 말이 핵심이라고 생각한다. 단순하기에 읽기 쉽고, 기능을 짐작할 수 있고, 고치기 쉽고, 고치려 하면 제자리로 돌아오기 마련이다.

 

최근 개인적으로 가장 공감되는 말은 "모든 테스트 케이스가 존재하고 통과해야 한다"이다. 회사에 있는 오래된 프로젝트들은 수정 요청사항이 들어올 때마다 골치 아프다. 테스트 케이스가 존재하지 않기에 메서드를 조금 수정하더라도 어디까지 영향을 미치는지 알 길이 없기 때문이다. 이럴 때는 차라리 영향력을 일일이 체크하기보다는 요청사항에 맞게 하나 만드는 것이 더 빠르다. 테스트 케이스가 있었다면 이런 걱정은 필요 없었을 것이다.

 

 

1장 깨끗한 코드를 읽고 난  후 들었던 생각과 깨끗한 코드를 알아가는 방법

---

나는 회사에 입사 후 책과 강의를 이용해 공부를 했다. 간혹 책과 강의를 보다 보면 주변 사람들에게 이런 말을 듣는다. "책하고 강의를 보는 건 소용없어 직접 해보는 게 최고야!"라고. 일부분 공감은 하지만 온전히 공감하지는 못한다. 개발자라면 책과 강의 그리고 구글링을 통해 항상 새로운 것을 접해야 한다고 생각한다. 물론 예전 것도 중요하고 공부해야 한다. 그러나 글쓴이가 말하는 새로운 것이란 새로운 기술뿐만 아니라 다른 개발자들이 설계한 아키텍처 그리고 어떠한 방법을 통해 코드를 더 효율적으로 작성하는지 많이 접해야 한다는 말이다.

 

깨끗한 코드에서 이런 말이 나온다. '깨끗한 코드가 무엇인지 모르면 깨끗한 코드를 만들려고 애써봤자 소용이 없다.'라고. 이 말에 깊이 공감한다. 나는 입사 후 첫 프로젝트를 진행하며 기능을 만들어갈 때마다 더 좋은 방법은 없는지 검토하고, 리펙토링 하기를 반복하여 스스로 만족스럽다 할만한 코드를 짜고 뿌듯해했었다. 그러나 여러 강의와 깃허브를 통해 코드들을 접하고, 책을 읽으며 스스로 만족하며 작성했던 코드들 속에서 풍겨오는 악취를 맡게 되었다.

 

깨끗한 코드가 무엇인지 알기 위해서는 깨끗한 코드가 무엇인지 알아야 된다. 스스로 생각을 통해 개선하며 알아갈 수도 있고, 책을 통해, 강의를 통해, 깃허브를 통하는 등... 여러 자료를 접하며 알아갈 수 있다 그러나 그중 가장 접근하기 쉬운 방법은 강의와 책이라고 생각한다.

 

강의에 장점 2가지

첫 번째는 네이버, 카카오, 당근, 구글, 마이크로 소프트 등.... 에서 근무했거나 근무하는 실력 있는 개발자들이 모여 강의한다는 것이다. 강사들이 각자가 속한 조직에서 배운 좋은 개발 방법들을 강의를 통해 보여주고, 나는 그 방법들을 좀 더 쉽게 접근하고 배울 수 있다. 또한 왜 이런 방식으로 개발했고, 이런 방법을 택했는지 개발자들의 생각을 들어볼 수 있다.

 

두 번째는 너무 많은 정보 덕에 선택의 폭이 넓어진다는 것이다. 가장 좋은 방법이라 생각되는 것을 택하고 분별해야 할 능력 또한 요구되지만, 좋은 것을 스스로 분별해내는 과정이 나의 생각의 영역을 넓혀주기 때문이다.

 

책을 읽는 것에 장점

강의만으로는 부족했던 상세한 내용들을 채워준다. 또한 책을 읽고 생각을 정리하며 잘못 이해했던 개념들은 바로잡고, 알았던 개념은 더 깊게, 몰랐던 개념은 새롭게 알게 된다.

 

우리가 작성하고 늘 접하고 있는 코드와 개발 방법이 가장 완벽한 것이라고 생각하는가? 나는 언제부턴가 더욱더 확신할 수 없게 되었다. 항상 더 좋은 방법이 있을 거라는 생각을 가지게 된다.