[클린 코드 Clean Code] 1장 깨끗한 코드

 

Clean Code 클린 코드 애자일 소프트웨어 장인 정신

- Robert C. Martin

---

0장 들어가면서

깨끗한 코드를 작성하는 방법은 배우기 어렵다

단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다. 잘 그린 그림과 그렇지 않은 그림을 구분할 줄 안다고 해서 그림을 잘 그릴 수 있는 게 아니듯이

스스로 연습하고 실패도 해보며 고생을 해야 한다.

 

 

 

---

1장 깨끗한 코드

코드가 존재하리라

코드는 더 이상 문제가 아니고, 모델이나 요구사항에 집중해야 한다고 생각하는 사람도 있을 것이다. 코드를 자동으로 생성하는 시대가 다가오면 프로그래머는 필요가 없게 될 것이다. 챗GPT?

코드가 사라질 가망은 전혀 없다. 왜? 코드는 요구사항을 상세히 표현하는 수단이기 때문

기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍이고, 명시한 결과가 바로 코드이다.

궁극적으로 코드는 요구사항을 표현하는 언어이다. 어느 순간에는 정밀한 표현이 요구되며, 그러므로 코드도 항상 존재하리라.

 

나쁜 코드

나쁜 코드에 발목잡혀 고생한 기억은 조금이라도 프로그램을 짜봤다면 수없이 경험했을 것이다.

우리 모두는 자신이 짠 쓰레기 코드를 보고 나중에 손보겠다고 생각한 경험도 있을 것이다. 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로하면서 말이다. 다시 돌아와 나중에 정리하겠다고 다짐했었다.

르블랑의 법칙 (Leblance's Law)
Later equals never. 나중은 결코 오지 않는다. 한번 작성한 쓰레기 코드를 나중에 수정하는 일은 결코 없다.

 

나쁜 코드로 치르는 대가

나쁜 코드는 개발 속도를 크게 떨어뜨린다.

코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기고, 시간이 지날수록 쓰레기 더미는 점점 높아지고 깊어지고 커진다.

 

나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.

생산성이 떨어지면 관리층은 생산성 증대에 대한 희망을 품고 프로젝트에 인력을 추가로 투입한다.

브룩스의 법칙 (Brooks' law)
프레더릭 브룩스가 자신의 1975년 저서 《맨먼스 미신》 (The Mythical Man-Month)에서 "지체되는 소프트웨어 개발 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다"라고 주장한 법칙이다.

새 인력은 시스템 설계에 대한 조예가 깊지 않고, 설계 의도에 맞는 변경과 설계 의도에 반하는 변경을 구분하지 못한다. 결과적으로는 나쁜 코드를 더 많이 양산한다. 그 덕분에 생산성은 더더욱 떨어져 거의 0이 된다.

원대한 재설계의 꿈

기존의 혐오스러운 코드로는 더 이상 일하지 못하겠다며 관리층에 재설계를 요구한다.

새로운 타이거 팀이 구성되어 기존 시스템 기능을 모두 제공하며, 유지보수 되고 있는 기존 시스템에 가해지는 변경도 모두 따라잡아야 한다.

이러한 재설계 과정은 아주 오랫동안 이어지며, 새 시스템이 기존 시스템을 따라잡을 쯤이면 초창기 타이거 팀원들은 모두 떠났고 새로운 팀원들이 새 시스템을 설계하자고 주장한다.

재설계는 근본적인 해결 방법이 되지 못한다.

 

태도

나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못한 태도이다.

 

원초적 난제

기한을 맞추기 위해 프로그램을 빨리 완성하다 보면 나쁜 코드를 양산할 수밖에 없다. 하지만 오히려 엉망진창인 상태로 인해 속도가 늦어지고, 결국 기한을 놓친다.

기한을 맞추는 유일한 방법, 다시 말해 빨리 가는 유일한 방법은 언제나 코드를 깨끗하게 유지하는 습관이다.

 

깨끗한 코드라는 예술?

잘 그린 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아닌 것처럼, 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.

 

깨끗한 코드란?

• 깨끗한 코드는 보기에 즐거운 코드다.
  • 효율적인 코드 : 단순히 속도만을 의미하는 것이 아닌, CPU 자원까지 고려한 코드
• 철저한 오류 처리 - 세세한 사항까지 꼼꼼하게 신경써야 한다.
  • 메모리 누수, 경쟁 상태(race condition), 일관성 없는 명명법

경쟁 상태 (Race condition)
설명공학 분야에서 경쟁 상태란 둘 이상의 입력 또는 조작의 타이밍이나 순서 등이 결괏값에 영향을 줄 수 있는 상태를 말한다. 입력 변화의 타이밍이나 순서가 예상과 다르게 작동하면 정상적인 결과가 나오지 않게 될 위험이 있는데 이를 경쟁 위험이라고 한다.

• 깨끗한 코드는 한 가지에 '집중'한다.
  • 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다.
  • 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.
• 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. (가독성)
  • 단순하고 직접적으로 작성해야 한다.
  • 설계자의 의도를 숨기지 않고, 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
• 깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
  • 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다.
  • 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다.
  • '최소'의 의존성, '최소'의 API : 작을수록 좋다.
• 깨끗한 코드는 주의 깊게 작성한 코드다.
  • 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다. 세세한 사항까지 꼼꼼하게 신경쓰고 주의를 기울인 코드다.
• 중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기
• 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다.

 

우리는 저자다

저자와 독자의 관계처럼 코드를 짠 사람은 코드를 읽는 사람에 대해 책임이 있다.

새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 따라서 읽기 쉬운 코드가 매우 중요하다.

급하다면, 서둘러 끝내려면, 쉽게 짜려면? 읽기 쉽게 만들면 된다.

 

보이스카우트 규칙

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

잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다. 지속적인 개선이야말로 전문가 정신의 본질이 아니던가?

 

프리퀄과 원칙

객체 지향 설계의 다섯 가지 원칙

1. SRP(The Single Responsibility Principle): 클래스에는 단 한 가지, 단 한 가지 변경 이유만 존재해야 한다.
2. OCP(The Open Clused Principle): 클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다.
3. LSP(The Liskov Substitution Principle): 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.
4. DIP(The Dependency Inversion Principle): 추상화에 의존해야 하며, 구체화에 의존하면 안 된다.
5. ISP(The Interface Segregation Principle): 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.

 

 

---

느낀 점

팀 프로젝트를 진행하면서 다른 팀원들의 코드를 읽다 보면 물 흐르듯 읽히는 코드가 있는 반면, 아무리 읽어도 이해가지 않는 코드들도 많이 마주했었다. 아마 내 코드도 다른 사람들이 봤을 때 수없이 그랬을 것이다. 누가 봐도 직관적으로 이해할 수 있는 코드를 짜고 싶어서 이 책을 읽기 시작했다.

 

저자가 말했듯 단순히 이 책을 완독한다고해서 바로 깨끗한 코드를 작성할 수는 없을 것이다. 하지만 이 책을 계속해서 반복하며 체화하고, 또 이 책의 내용을 바탕으로 선배, 동료들과 코드 리뷰를 하고 의견을 나누다 보면 언젠가는 아름다운 코드를 작성할 수 있지 않을까?