Clean Code - 깨끗한 코드

로버트 C. 마틴의 "클린 코드"를 읽고 정리하고 생각하는 시리즈

나쁜 코드

…우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다... 나중은 결코 오지 않는다.
Clean Code, 4p

나쁜 코드의 악순환

나쁜 코드는 생산성을 떨어트린다. 코드를 고칠 때마다 매번 복잡한 코드를 다시 해독하고 수정해야 한다. 시간은 한정되어 있고 개발은 해야 하기에, 나쁜 코드 위에 나쁜 코드가 쌓이는 악순환이 생긴다.

생산성이 떨어지면 관리층은 나름대로 복구를 시작한다. 프로젝트에 인력을 추가로 투입하는 것이다. 하지만 새 인력은 시스템 설계에 대한 조예가 깊지 않아 나쁜 코드를 더 많이 양산한다. 결국 생산성은 더더욱 떨어져 거의 0이 된다.

해결책은 무엇인가? 처음부터 나쁜 코드를 만들지 않는 것이다. 재설계와 유지보수에 쓸 자원을 더 개발에 투자하게끔 하는 것이다.

나의 개발자 마인드셋 & 습관 설정하기 에 언급한 것처럼, 안 돌아가는 프로그램보다 돌아가는 쓰레기가 더 낫다. 하지만 돌아가는 쓰레기보다는 돌아가는 좋은 프로그램이 당연히 더 좋다.

'좋은 코드'를 바로 작성할 수 있는 능력이 부족하다면, '나쁜 코드'를 작성하게 되고 이후 유지보수에 시간을 많이 쏟게 된다. 반면에, '좋은 코드'를 바로 작성할 수 있는 능력이 있다면, 유지보수에 시간을 덜 쏟게 된다. 결국 이것이 주니어, 시니어, 베테랑 개발자를 나누는 기준 중 하나가 아닐까.

태도

좋았던 코드가 어째서 순식간에 나쁜 코드로 전락하는가? 그 책임은 우리, 개발자들에게 있다고 저자는 말한다.

어째서 우리 탓인가? 요구사항은? 일정은? 개발에 문외한인 관리자는?

관리자는 약속과 공약을 내걸며 우리에게 정보를 구한다. 우리에게 정보를 구하지 않더라도 우리가 적극적으로 정보를 제공해야 마땅하다. 사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다. 프로젝트 관리자는 일정을 잡으며 우리에게 도움을 청한다. 우리는 프로젝트를 계획하는 과정에 깊숙이 관여한다. 그러므로 프로젝트 실패는 우리에게도 커다란 책임이 있다... 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다... 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
Clean Code, 7p

이 부분에 대해선 아직 완전히 동감하지는 못한다. 일반적으로 미국보다 더 수직적인 조직 구조를 가진 한국의 개발자들은 관리자와 상급자의 말을 거부하기 더 힘들다고 생각한다.

원초적 난제

나쁜 코드는 업무 속도를 늦춘다. 그럼에도 어떤 개발자들은 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다. 하지만 나쁜 코드를 양산하면 오히려 더 기한을 맞추지 못한다. 그만큼 유지보수에 시간을 더 쏟아야 하니까. 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

방을 어지럽히지 않는 가장 좋은 방법이 무엇일까? 물건을 사용할 때마다 제자리에 놔두는 것이라고 생각한다. 그리고 매일 조금씩 청소해 주는 것. 개발에도 동일한 상황이 적용된다고 느낀다. 시간이 조금 더 걸리더라도, 시작부터 좋은 코드를 작성하는 것. 이것이 가장 시간을 절약하는 방법이다.

물건을 어디 놔뒀는지 기억하지 못해 방 전체를 뒤집어 찾기보다, 매일 정리하고 분류된 장소에 물건을 놓는 것. 이것이 좋은 코드가 아닐까.

깨끗한 코드

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

나쁜 코드는 프로젝트에 심각한 장애물이라는 사실을 알았다. 빨리 가려면 코드를 깨끗하게 작성하고 유지해야 한다는 사실도 안다. 그렇다면 다음 질문은, "깨끗한 코드를 어떻게 작성할까?" 이다. 그 이전에, 깨끗한 코드는 무엇인가?

저자는 깨끗한 코드를 구현하는 행위는 그림을 그리는 행위와 비슷하다고 한다. 어떤 그림을 볼 때, 대부분의 사람은 그 그림이 잘 그려졌는지 엉망으로 그려졌는지 판단할 수 있다. 그렇지만 그렇게 그림을 구분하는 능력이 그림을 잘 그리는 능력은 아니다.

깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다. 열쇠는 '코드 감각' 이다. 어떤 사람은 코드 감각을 타고난다. 어떤 사람은 투쟁해서 얻어야 한다.
Clean Code, 8p

코드 감각은 우리가 흔히 말하는 패션 감각과 일맥상통하다. 누군가는 타고나고, 누군가는 배워 얻는다. 다행인 점은 타고난 극소수의 전유물이 아니라는 것이다.

이 코드 감각을 지닌 유명한 개발자들의 의견들을 저자는 가져온다.

깨끗한 코드란?

• 효율적이다.
• 철저한 오류 처리를 한다.
• 가독성이 좋아야 한다. 코드가 잘 쓴 문장처럼 읽혀야 한다.
• 반드시 필요한 내용만 담는다.
• 다른 사람이 고치기 쉬워야 한다.
• 중복되는 기능이 없다.
• 모든 테스트를 통과한다.
• 클래스, 메서드, 함수 등을 최대한 줄였다.
• 표현력이 높다.(함수의 명확한 이름 등)
• 초반부터 간단한 추상화를 고려한다.
• 읽으면서 짐작한 대로 돌아가는 코드이다.(코드 해독에 시간을 많이 쏟을 필요가 없다.)

우리는 코드 작성보다 읽는 데 시간을 더 사용한다.

새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 저자는 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10:1을 훌쩍 넘는다고 한다. 그만큼 읽기 쉬운 코드가 매우 중요하다. 읽기 쉽게 만들면 짜기도 쉬워진다.

이 논리에서 빠져나갈 방법은 없다. 주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 주변 코드가 읽기 쉬우면 새 코드를 짜기도 싶다. 그러므로 급하고, 서둘러 끝내려면, 읽기 쉽게 만들면 된다.

보이스카우트 규칙

캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
- 보이스카우트 규칙

잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지나면서 엉망으로 전락하는 코드가 많다. 적극적으로 코드의 퇴보를 막아야 한다. 위의 보이스카우트 규칙이 우리에게도 유용하다.

 

체크아웃 할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.
Clean Code, 19p

결론

"연습해, 연습!"
Clean Code, 20p

엉망인 그림과 그렇지 않은 그림을 구분하는 건 쉽다. 책만 따라가도 된다. 하지만 좋은 그림을 그리는 건 별개의 문제다. 이 책은 좋은 코드와 나쁜 코드의 예시, 다양한 도구와 기법, 생각하는 방식을 제공한다. 그걸 가지고 실제로 그림을 그리는 건 나에게 달렸다. 말해 무엇하나? 연습만이 살길이다.