[클린코드] 1장. 깨끗한 코드

스터디 메인 페이지

목차

- ☆ 표시가 붙은 부분은 스터디 중 나온 얘기 혹은 제 개인적인 생각이나 제가 이해한 방식을 적어놓은 것으로, 책에서 말하고자 하는 바와 다를 수 있습니다.

- 모든 이미지의 출처는 클린 코드(로버트 C. 마틴 저) 책 입니다.

 

---

 

⚈ 팀이나 공동체에서 서로 동의하는 합리적인 원칙을 세우기 위한 소통이 핵심

• 이 책은 이런 소통을 위한 기초 지식을 제공하고 생각할 거리를 던져주는 책

 

---

1장 깨끗한 코드

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

• 코드는 요구사항을 표현하는 언어이다.

 

⚈ 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다.

• 나중은 결코 오지 않는다. (르블랑의 법칙)

 

⚈ 나쁜 코드로 치르는 대가

• 나쁜 코드는 개발 속도를 크게 떨어뜨린다.
• 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 간단한 변경은 없다.
• 시간이 지나면서 쓰레기 더미는 점점 커진다.
• 팀 생산성이 점점 떨어지다가 0에 근접한다.
• 관리층은 나름대로 복구를 시도하려고 인력을 추가로 투입한다.
• 새 인력은 기존 시스템에 대해 조예가 깊지 않고, 생산성을 높여야 한다는 극심한 압력에 결국 나쁜 코드를 더 많이 양산한다.
• 생산성은 더더욱 떨어진다.
• 마침내 팀이 반기를 든다.
• 관리층은 재설계에 자원을 넣기 싫지만 생산성이 바닥임을 부인할 수 없으므로 팀이 요구하는대로 원대한 재설계를 허락한다.
• 모두가 새로운 타이거 팀에 합류하고 싶어한다. 처음부터 시작해 진정을 아름다운 작품을 창조할 기회니까.
• 타이거 팀은 기존 시스템 기능을 모두 제공하는 새 시스템을 내놓아야 한다. 또한 새로운 시스템을 개발하는 동안 기존 시스템에 가해지는 변경도 모두 따라잡아야 한다.
• 때때로 아주 오랫동안 이어지고, 기존 시스템을 따라잡을 즈음이면 초창기 타이거 팀원들은 모두 팀을 떠났고 새로운 팀원들은 현재 시스템이 너무 엉망이라서 새 시스템을 설계하자고 나선다. (반복)

 

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

 

⚈ 핑계 - 우리의 코드가 어째서 순식간에 나쁜 코드로 전락할까?

• 원래 설계를 뒤집는 방향으로 요구사항이 변했다고 불평. 일정이 촉박해 제대로 할 시간이 없었다고 한탄. 멍청한 관리자와 조급한 고객과 쓸모없는 마케팅 부서 탓이라 떠벌인다.
• 하지만 잘못은 전적으로 우리 프로그래머에게 있다. 우리가 전문가답지 못했기 때문이다.
• 인정하기 어려울 것이다. (☆ ㄹㅇㅋㅋ)
• 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.
• 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
• ☆ 뼈맞았음. 그치만 이런 얘기 꽤 많이 해봤다. 내 경험상 일정 수정이 어려운 경우가 아직은 더 많은 것 같다. 아마 정확히 일정 수정에 대해 피력하지 못했기 때문일 것 같기도 하다.

 

⚈ 빨리 가려면 깨끗한 코드가 필요

• 착각 : 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느낀다.
• 진짜 전문가 : 기한을 맞추는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

 

⚈ 깨끗한 코드

• '보기에 즐거운' 코드
• 나쁜 코드는 나쁜 코드를 '유혹'한다.
• 깨끗한 코드는 한 가지에 '집중'한다.
• 깨끗한 코드는 잘 쓴 문장처럼 읽혀야 한다.
• 필요한 내용만 담아야 한다.
• 다른 사람이 고치기 쉽다.
• 테스트 케이스가 있어야 한다.
• 깨끗한 코드는 주의 깊게 작성한 코드다.
• 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라.
• 깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다. (☆ 누군가 뭔가를 엄청 쉽게 하고 있다면 쌉고인물이다)

 

⚈ 우리는 저자다

• 저자에게는 독자와 잘 소통할 책임도 있다. 
• 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.
• 읽기 쉬운 코드가 매우 중요하다.

 

⚈ 보이스카우트 규칙 (☆ 엄청 괜찮은듯. 크게 전부 바꿀 생각보다도, 어쨌든 볼 때 마다 하나라도 개선하겠다는 마인드)

• "캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라."
• 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.
• 변수 이름 하나를 개선하고, 조금 긴 함수를 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다.
• 결국 시간이 지날수록 코드가 좋아지는 프로젝트가 된다.