[Clean Code] 클린코드 - 01장. 깨끗한 코드

클린 코드 개발도서 관련 : 1장 깨끗한 코드란 무엇인지 살펴본다.

코드가 존재하리라

• (많은 사람들의 생각) 코딩의 시대는 끝났다. 왜냐하면, 자동화로 인해 사람이 아닌 기계가 코딩을 할 수 있기 때문이다.
• (저자의 생각) 아니다. 코딩은 꼭 필요하다. 아무리 기술이 발달해도 코딩이란 엄밀하고, 정확하고, 상세하고, 정형화 되어야 하기 때문이다. 이는 사람도 하기 힘들다.

내 생각…

이 책이 쓰여질 때 까지만 해도 이렇게까지 기술이 발달 할 줄은 몰랐던 것 같다. 나는 전자의 의견이 맞다고 생각한다. 언젠가는 인간이 코딩할 일은 없어질듯 싶다.

아무튼 이 책에서 주장하는 바는 코드는 죽었다 깨어나도 항상 존재한다는 말씀이다. 고로 우리는 코드 공부를 해야할 필요성이 있다~! (아직은 코드가 죽지 않았으니, 공부해야겠다.)

나쁜 코드

• 켄트 벡이 저술한 책에서 이 책은 좋은 코드가 중요하다는 다소 미약한 전제에 기반한다 ...는 문구가 있으나 저자는 이에 동의하지 않는다. 왜냐하면 좋은 코드는 매우 중요하기 때문이다.
• 80년대 후반 킬러 앱을 출시한 회사가 처음에 잘나가다가 잦은 버그와 그에 대응하지 못해 결국 망해버린 사례를 들었다. 그 이유는 개발 당시 바쁜 일정으로인해 마구 작성한 나쁜 코드였다고 한다.
• 우리들도 아마 바쁜 일정으로 인해 나쁜 코드를 작성한 경험이 많을 것이다. 아마 당시에는 나중에 정리하리라 다짐하며 작성 했겠지만, 우리는 알고 있다. 나중은 켤코 오지 않는다는걸.(르블랑의 법칙)

나쁜 코드로 치르는 대가

• 나쁜 코드는 시간이 지날수록 쌓인다. 쌓일수록 팀 생산성은 떨어지고, 결국 생산성은 0에 근접한다.
• 이미 떨어진 생산성을 복구하기 위해 프로젝트를 띄운다. 그러나 설계 의도를 온전히 이해하지 못한 프로젝트 인력들이 복구에 대한 압력에 시달려 결국 나쁜 코드를 더 많이 양산한다. 결국 생산성은 더더욱 0에 수렴한다…

원대한 재설계의 꿈

• 결국 원대한 재설계의 꿈을 가지고 관리층에 재설계 할 것을 요구한다. 결국 진행이 되어 유능한 인력으로 프로젝트가 꾸려져 진행 된다. 진행되는 동안 기존 시스템도 기능이 추가 되기 때문에, 신규 시스템은 기존 요구사항 + 새로운 요구사항을 모두 만족할 때까지 진행된다. 결국 마무리가 되어 출시하였을때는 초창기 인력들은 사라져있고, 새로운 팀원들이 또 다시 새 시스템을 설계하자고 나선다. 왜냐하면 이 또한 너무 엉망이라서…ㅋㅋㅋ
• 이러한 경험을 해본 사람들은 알 것 이다. 시간 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법이며 전문가로 살아남는 길이라는 사실을.

태도

• 코드가 엉망인 것에 대해 온갖 외부 요인들을 생각할 것이다. 그러나 이는 핑계일뿐 잘못은 전적으로 프로그래머에게 있다. 우리가 전문가답지 못했기 때문이다.
• 기획자며, PM 이며 모두 우리에게 프로젝트 관련 정보를 구한다. 우리는 프로젝트를 계획하는 과정에 깊숙히 관여하고 있기 때문에 우리에게도 커다란 책임이 있다. 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다.
• 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르는 행동은 전문가답지 못하다. (마치 환자가 오래걸리니 손을 씻지말고 수술해달라고 한 말을 믿고 따르는 의사처럼)

내 생각…

아무리 무리한 요구사항이 있을지라도 지킬건 지키면서 코딩을 하는 것이 전문가다. 근데 그런거 지키면… 일정을 못맞출텐데…? 내가 손해보더라도 지킬것도 지키고 일정도 지키란 건가…

이 책에서 너무 강경하게 나쁜 코드의 주요 원인을 프로그래머라고 말하는데, 이는 책의 주제인 깨끗한 코드의 중요성을 합리화하고, 독자에게 주입시키기 위해 노력하는 느낌이 든다. 물론 정말 맞는 말일지언정 썩 기분이 좋지는 않다…ㅎㅎ

원초적 난제

• 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다.
• 그러나 이는 잘못됐다. 나쁜 코드를 양산하면 오히려 기한을 맞추지 못한다. 엉망진창인 상태로 인해 속도가 곧바로 늦어지고 결국 기한을 놓친다.
• 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관을 갖는 것이다.

내 생각…

나도 많이 겪어본 일이다. 내 스스로 개발 기한이라는 핑계로 좀 더 편하게 코딩하려고 나쁜 코드를 양산한 경험이 있다. 실용주의 프로그래머 초반부에 나오는 깨진 창문 이야기 처럼 나의 잘못된 코드로인해 주변이 더럽혀지는 것은 순식간인것 같다.

나 하나 가지고라는 마인드를 버리고 나 라도라는 마인드로 깨끗한 코드를 하기 위해 노력해야 겠다…!

깨끗한 코드라는 예술?

• 깨끗한 코드의 중요성을 알았으니, 깨끗한 코드가 무엇인지 알아야 한다.
• 깨끗한 코드가 무엇인지 안다고해서 깨끗한 코드를 작성할 수 있는것은 또 아니다.
• 깨끗한 코드를 작성하려면 코드 감각이 있어야 한다. 이는 좋은 코드와 나쁜 코드를 구분한다. 또한, 절제와 규율을 적용하여 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.

깨끗한 코드란?

• 깨끗한 코드의 정의는 프로그래머 수만큼 다양할 것이다. 그렇기에 유명 프로그래머의 의견을 인용하겠다.

우아한 코드

비야네 스트롭스트룹 - C++ 창시자이자 The C++ Programming Language 저자

우아하고 효율적인 코드 선호
논리가 간단해야 버그가 숨지 못한다.
의존성을 줄여야 유지보수가 쉽다.
오류는 명백한 전략에 의거해 철저히 처리
성능을 최적으로 유지하라. 그래야 다른 사람들이 원칙 없는 최적화로 망치려 하지 않는다.
깨끗한 코드는 한 가지를 제대로 한다.

• 우아한 이라는 단어를 사용함.

  ” 우아함 “

  외양이나 태도가 기품 있고 단아하며 보기에 즐거운

  교묘하고 단순해 보기에 즐거운

• 여기서 보기에 즐거운에 주목해야 한다. 깨끗한 코드는 보기에 즐거운코드다. (코드를 보는사람에게 즐거움을 선사하자.)
• 성능과 나쁜 코드의 유혹, 그리고 명백한 오류 처리 등 모두 세세하게 신경써야 한다. 즉, 여기서 말하는 깨끗한 코드란 세세한 사항까지 꼼꼼하게 처리하는 코드다.

가독성 좋은 코드

그래디 부치 - Object Oriented Analysis and Design with Application 저자

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

• 가독성을 강조하였다.
• 소설과 마찬가지로 해결할 문제의 긴장을 명확히 드러내며, 긴장을 쌓으며 클라이맥스에서 명백한 해법을 제시하며 긴장과 문제를 풀어야 한다.
• 명쾌한 추상화는 모순어법이다. 그러나 의미는 강력하고 분명하다. 코드는 반드시 필요한 내용만 담아야 한다. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야 한다.

고치기 쉬운 코드

큰(Big) 데이브 토마스 - OTI 창립자이자 이클립스 전략의 대부

작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
의미 있는 이름이 붙는다.
특정 목적을 달성하는 방법은 하나만 제공한다.
의존성은 최소이며 각 의존성을 명확히 정의한다.
API는 명확하며 최소로 줄인다.
필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에 코드는 문학적으로 표현해야 마땅하다.

• 마찬가지로 가독성을 강조함과 동시에, 다른 사람이 고치기 쉽다고 단언한다.
• 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다.
• 테스트 케이스가 없는 코드는 아무리 우아해도 깨끗한 코드가 아니다. (테스트 케이스의 중요성)
• 최소라는 단어를 두 번이나 사용하였는데, 큰 코드보다 작은 코드에 가치를 둔다는 의미이다.
• 코드가 문학적이어야 한다. = 인간이 읽기 좋은 코드를 작성하라는 말

주의 깊은 코드

마이클 페더스 - Working Effectively with Legacy Code 저자

언제나 누군가 주의 깊게 짰다는 느낌을 준다.
고칠곳이 없다.
작성자가 이미 모든 사항을 고려했다.
남겨준 코드에 감사를 느낀다.

• 주의에 대해 강조하고 있다.
• 이것이 이 책의 주제이다. 책의 부제를 ‘코드를 주의 깊게 짜는 방법’이라고 해도 될 정도다.
• 깨끗한 코드는 주의 깊게 작성한 코드다. (깔끔, 단정, 세세한 사항까지 꼼꼼히 신경쓴 코드)

최소화된 코드

론 제프리스 - Extreme Programming Installed와 Extreme Programming Adventure in C# 저자

단순한 코드 규칙 by 켄트 벡
(중요도 순서대로 나열)

모든 테스트를 통과한다.
중복이 없다.
시스템 내 모든 설계 아이디어를 표현한다.
클래스, 메서드, 함수 등의 내용을 최대한 줄인다.(작은단위의 여러개로 쪼개기)

• 중복을 피하라, 한기능만 수행하라, 제대로 표현하라, 작게 추상화하라.
• 이는 곧 이 책의 내용을 요약한 것이다.

짐작 가능한 코드

워드 커닝햄 - Wiki 창시자, Fit 창시자, eXtreme Programming 공동 창시자, 디자인패턴을 뒤에서 움직이는 전문가, 스몰토크와 객체 지향의 정신적 지도자, 코드를 사랑하는 프로그래머들의 대부

코드를 읽으면서 짐작했던 대로 기능들이 수행하면 깨끗한 코드다.
코드가 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드다.

• 깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다.
• 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다.
• 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다.
• 명백하고 단순해 마음이 끌리는 코드가 깨끗한 코드다.
• 코드를 단순하게 보이도록 만드는 책임이 우리에게 있다.
• 프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다. 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다. (즉, 사용하는 언어탓 하지말자. 내 탓 하자…!)

우리들(저자) 생각

• 저자는 이 책에서 깨끗한 변수 이름, 깨긋한 함수, 깨끗한 클래스를 만드는 방법을 소개한다.
• 저자의 의견을 절대적인 진리처럼 설교한다는 점을 참고하자.
• 그치만, 이 책에서 주장하는 모든 기법에 동의하지 말고, 일부는 격렬히 반대하라. (그래도 경험과 노력이 담겼으니 존중은 해주라.)

우리는 저자다

• 앞으로 코드르 짤 때 자신이 저자라는 사실을 인지하고 독자를 생각하라.
• 코드를 읽는것보다 쓰는데 시간을 더 많이 투자할 줄 알지만, 반대이다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. (읽기 : 쓰기 = 10 : 1)
• 그러므로, 읽기 쉬운 코드는 매우 중요하다.

보이스카우트 규칙

• 우리는 적극적으로 코드의 퇴보를 막아야 한다. (시간이 지나면 코드가 엉망이 되기 마련…)
• 미국 보이스카우트가 따르는 간단한 규칙

  캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

• 체크아웃할 때보다 체크인할 때 더 깨끗한 코드를 내보내면 절대 나빠지지 않는다.
• 한꺼번에 많은걸 하기보다는 작은것 들을 처리해보자.
  • 변수 이름 하나 개선하기
  • 조금 긴 함수 하나 분할하기
  • 약간의 중복 제거하기
  • 복잡한 if문 정리하기

프리퀄과 원칙

• 이 책을 다읽으면 PPP(Agile Software Development: Principles, Patterns, and Practices)을 읽어볼것.

결론

• 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.
• 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다.
• 책에서 무수히 많은 예제를 보여줄것 이고, 연습만이 답이다~!

고찰

Overview 서문에서도 그랬듯이 이번에도 결국 결론은 열심히 연습하라는 말이다.

아직 1장 밖에 읽지 않았지만 벌써부터 마음 한구석에서 많은 변화가 시작된 것 같다.

나쁜 코드에 대해 읽을 때는 정곡을 찔려가며 반성하게 되었고, 깨끗한 코드란 무엇인가에 대해 읽으면서는 모든것을 통찰하는 주옥같은 말씀들에 가슴 속 무언가가 차오르는 느낌이 들었다…

빨리 코딩하고 싶어진다. 빨리 팀원들에게 이 위대한 말씀을 전파하고 싶어진다.

앞으로 핑계대지말고 나부터 깨끗해지려고 노력해야겠다. 창문이 깨져있으면, 새 창문을 끼워보도록 하자.

⬅️ 클린코드 목차보기