[독서 기록] 클린 코드 1~2장 / 깨끗한 코드, 의미 있는 이름

클린 코드, 로버트 C. 마틴, 박재호 이해영 옮김, 인사이트

 

Clean Code(클린 코드)

『Clean Code(클린 코드)』은 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 소개하고 있다. 소프트웨어 장인 정신의 가치를 심어 주며 프로그래밍 실력을 높여줄 것이다. 여러분이 노력만 한다면. 어떤 노력이 필요하냐고? 코드를 읽어야 한다. 아주 많은 코드를. 그리고 코드를 읽으면서 그 코드의 무엇이 옳은지, 그른지 생각도 해야 한다. 좀 더 중요하게는 전문가로서 자신이 지니는 가치와 장인으로서 자기 작품에 대한 헌신을 돌아보게 된다.

저자

로버트 C 마틴

출판

인사이트

출판일

2013.12.24

 

 

 

신은 세세함에 깃들어 있다. 건축가인 루트비히 미스 반 데어로에가 한 말이다. 소프트웨어 개발, 특히 애자일 세상에서 아키텍처의 역할을 논하는 요즘 논쟁을 떠올리게 만드는 문구다.

- xxii

 

 

우리 둘 다 "책임 있는 전문가라면 프로젝트를 시작할 때 생각하고 계획할 시간을 확보해야 한다"는 사실을 당연하게 여기기 때문이다. 

- xxii

 

 

소프트웨어는 80% 이상이 소위 "유지보수"다. 

- xxiii 

 

 

신의 집을 세세함이 깃든 공간으로 표현한 사람을 찾다가 우리는 19세기 프랑스 문인 귀스타브 플로베르를 만났다. 프랑스 시인인 폴 랄레리는 시란 영원히 미완성이라 끝없는 재작업이 필요하며 포기할 때에만 끝난다고 말했다. 이렇듯 세세함에 몰두하는 태도는 탁월함을 추구하는 모든 노력에서 공통으로 발견된다. 

- xxxvi

 

 

품질은 하늘에서 뚝 떨어진 위대한 방법론이 아니라 사심 없이 기울이는 무수한 관심에서 얻어진다.

- xxvii

 

 

장인 정신을 익히는 과정은 두 단계로 나뉜다. 바로 이론과 실전이다. 첫째, 장인에게 필요한 원칙, 패턴, 기법, 경험이라는 지식을 습득해야 한다. 둘째, 열심히 일하고 연습해 지식을 몸과 마음으로 체득해야 한다.

-xxxii

 

 

우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다. 

- 4p

 

 

코드가 정말이지 너무도 엉망이라 몇 시간으로 예상한 업무가 몇 주로 늘어진 경험이 있는가? 한 줄만 고치면 되리라 예상했다가 모듈을 수백 개 건드린 경험이 있는가? 너무 자주 접하는 모습이다.

- 6p 

 

 

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

- 7p 

 

 

마지막으로 비야네는 깨끗한 코드란 한 가지를 잘 한다고 단언한다. 수많은 소프트웨어 설계 원칙이 이 간단한 교훈 하나로 귀결된다는 사실은 우연이 아니다.

- 10p

 

 

깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로. 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다. (마이클 페더스)

- 12p

 

---

 

의도를 분명히 밝혀라

 

int d; 

 

이름 d는 아무 의미도 드러나지 않는다. 경과 시간이나 날짜라는 느낌이 안 든다. 측정하려는 값과 단위를 표현하려는 이름이 필요하다.

 

int elapsedTimeInDays;

 

- 22p

 

 

그릇된 정보를 피하라

의미있게 구분하라

-24 ~ 25p

 

 

연속적인 숫자를 덧붙인 이름(a1, a2 ...)은 의도적인 이름과 정반대다. 이런 이름은 그릇된 정보를 제공하는 이름도 아니며, 아무런 정보를 제공하지 못하는 이름일 뿐이다. 

- 26p

 

a나 the 같은 접두어를 사용하지 말라는 소리가 아니다. 의미가 분명히 다르다면 사용해도 무방하다. 예를 들어, 모든 지역 변수는 a를 사용하고 모든 함수 인수는 the를 사용해도 되겠다. 요지는 zrokr라는 변수가 있다는 이유만으로 theZork라 이름 지어서는 안 된다는 말이다.

 

불용어는 중복이다. 변수 이름에 variable이라는 단어는 단연코 금물이다. 표 이름에 table이라는 단어도 마찬가지다. 

- 26p 

 

 

발음하기 쉬운 이름을 사용하라

검색하기 쉬운 이름을 사용하라

인코딩을 피하라

- 29~ 31p

 

 

클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

 

메서드 이름은 동사나 동사구가 적합하다.

-32p

 

 

한 개념에 한 단어를 사용하라

말장난을 하지마라 

해법 영역에서 가져온 이름을 사용하라(전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.) 

의미 있는 맥락을 추가하라

불필요한 맥락을 없애라

- 33 ~ 37p