[Clean Code (클린코드)] ch.1 깨끗한 코드

나쁜 코드

80년대 후반 킬러 앱을 구현한 회사가 있었다. 초반엔 흥행하는 듯 했으나 점점 제품 출시 일이 늦춰지고 이전 버그가 다음 버전에도 남아았었음 + 프로그램 시동 시간 증가 + 프로그램 다운 횟수 증가 결국, 회사는 망했다.

👉 Why? 나쁜 코드 때문이다.

 

르블랑의 법칙

나중은 결코 오지 않는다.

→ 안 돌아가는 프로그램보다 돌아가는 쓰레기로 위안삼으며 나중에 정리하겠다는 생각은 버리자! 

 

나쁜 코드로 치르는 대가

"나쁜 코드가 쌓을 수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다"

 

원대한 재설계의 꿈

시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이라는 사실을 인정하라

 

태도

프로그래머가 나쁜 코드를 작성할 수 밖에 없었던 이유는 무엇일까?

멍청한 관리자, 조급한 고객, 쓸모없는 부서, 촉박한 일정

위 4개 모두 아니다. 이유는 프로그래머에게 있다.

관리자와 마케팅은 약속과 공약을 내걸며 우리에게 정보를 구한다.

우리에게 정보를 구하지 않더라도 우리는 적극적으로 정보를 제공해야 한다.

 

👨 사용자 - 요구사항을 내놓으며 프로그래머에게 현실성 자문

👨 프로젝트 관리자 - 일정을 잡으며 프로그래머에게 도움 요청

→ 따라서 우리는 커다란 책임을 가지고 있다.

 

일정에 쫒기더라도 대다수 관리자는 좋은 코드를 원한다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그댈 따르는 행동은 전문가답지 못하다.

 

원초적 난제

나쁜 코드가 업무 속도를 늦춘다는 사실을 안다. 하지만 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다.

하지만, 진짜 전문가는 두 번째 부분이 틀렸다는 것을 안다. 나쁜 코드를 양산하면 기한을 맞추지 못한다! !

⭐ 기한을 마추는 유일한 방법은 언제나 코드를 깨끗하게 유지하는 습관이다.

 

깨끗한 코드라는 예술?

"깨끗한 코드를 어떻게 작성할까?"

 

깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷하다.

→ 그림을 보면 잘 그렸는지 엉망으로 그렸는지를 알 수 있다. 그렇지만 잘 그린 그림을 구분한다고 해서 그림을 잘 그리는 것은 아니다. 즉, 깨끗한 코드와 나쁜 코드를 구분한다고 해서 깨끗한 코드를 작성할 수 있는 건 아니다.

 

코드감각이 중요하다.

‘코드감각’이 있는 프로그래머는 나쁜 모듈을 보면 좋은 모듈로 개선할 방안을 떠올린다.

최고의 방안을 선택한 후 여기서 거기까지 이동하는 경로를 계획한다.

⭐ 깨끗한 코드를 작성하는 프로그래머는 빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다.

 

깨끗한 코드란?

바야네 스트롭스트룹

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

 

그리디 부치

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

→ 코드는 추측이 아니라 사실에 기반해야 한다.

반드시 필요한 내용만 담아야 한다.

 

'큰'데이브 토마스

깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드는 의미 있는 이름이 붙는다. 의존성은 최소이며 각 의존성을 명확히 정의한다. API는 명확하며 최소로 줄였다.

 

마이클 페더스

깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 상황을 고려했으므로, 고칠 궁리를 하다 보면 언제나 제자리로 돌아온다.

 

론 제프리스

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

→ 객체가 여러 기능을 수행한다면 여러 객체로 나눈다.

→ 메서드가 여러 기능을 수행한다면 메서드 추출 리펙터링 기법을 적용해 기능을 명확히 기술하는 메서드와 기능을 실제로 수행하는 메서드 여러 개로 나눈다.

 

워드 커닝햄

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

→ 깨끗한 코드는 놀랄일이 없어야 한다.

 

우리는 저자다

코드는 코드를 짜는 시간보다 읽는 시간에 더 많은 시간을 투자하게 된다.

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

 

보이스카우트 규칙

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

잘 짠 코드가 전부는 아니다. 시간이 지나도 깨끗하게 유지해야 한다.

한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요는 없다. 아래 것들만 해도 충분하다.

• 변수 이름을 하나로 개선
• 조금 긴 함수를 하나를 분할
• 약간의 중복 제거
• 복잡한 if 문 하나 정리

결론

공부하자!!! 연습하자!!!