[클린코드] 0~3장 정리(들어가면서, 깨끗한 코드, 의미 있는 이름, 함수)

<클린코드> 책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.

0장. 들어가면서

- 깨끗한 코드를 작성하는 방법은 배우기 어렵다. 단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다. 고생을 해야 한다. 스스로 연습하고 실패도 맛봐야 한다. 남들이 시도하다 실패하는 모습도 봐야한다. 그들이 넘어지고 일어서는 모습도 봐야한다. 결정을 내리느라 고민하는 모습, 잘못된 결정으로 대가를 치르는 모습도 봐야한다.

 

- 이 책을 읽는 동안 마음 고생할 준비를 하기 바란다. 비행기 안에서 심심풀이로 읽어보는 기분 좋은 책이 아니다. 열심히, 아주 열심히 독파해야 하는 책이다.

1장. 깨끗한 코드

- 비유를 하나 들겠다. 자신이 의사라 가정하자. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까. 확실히 환자는 상사다. 하지만 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자 말을 그대로 따르는 행동은 (범죄일 뿐만 아니라) 전문가답지 못하니까.

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

 

- 진짜 전문가는 잘 안다. 나쁜 코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다. 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

- "깨끗한 코드를 어떻게 작성할까?" 깨끗한 코드가 무엇인지 모르면 깨끗한 코드를 만들려고 애써봤자 소용이 없다.

 

- 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 집중한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.

 

- 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 아무리 코드가 우아해도, 아무리 가독성이 높아도, 테스트 케이스가 없으면 깨끗하지 않다.

 

- 깨끗한 코드는 주의 깊게 작성한 코드다. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다. 세세한 사항까지 꼼꼼하게 신경쓴 코드다. 주의를 기울인 코드다.

 

- 중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기. 내게는 이 세가지가 깨끗한 코드를 만드는 비결이다.

 

- 이 책은 우리 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다. 여기서 가르치는 교훈과 기법은 우리 진영이 믿고 실천하는 교리다. 우리가 가르치는 교훈을 따른다면 우리가 만끽한 이익을 여러분도 만끽하리라 감히 장담한다.

 

- 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. '코드 감각'을 확실히 얻는다는 보장도 없다. 단지 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교과 도구를 소개할 뿐이다.

2장. 의미 있는 이름

- 프로그래머에게 List라는 단어는 특수한 의미다. 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이다. 그러므로 accountGroup, bunchOfAccounts, 아니면 단순히 Accounts라 명명한다. 나중에 살펴보겠지만, 실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는편이 바람직하다.

-> (내 생각) 지금껏 -List라는 postfix를 사용하여 복수개의 데이터를 담는 변수 내지 그 변수를 리턴하는 함수의 네이밍에도 많은 부분 사용했었는데, 생각해보니 List라는 자료구조를 생각하며 작성했던 건 아니었다. 앞으로는 -s를 postfix로 사용하는 것이 더 좋을 것 같다고 생각하게 되었다.

 

- 불용어를 추가한 이름은 아무런 정보를 제공하지 못한다. Product라는 클래스가 있다고 가정하자. 다른 클래스를 ProductInfo 혹은 ProductData라 부른다면 개념을 구분하지 않은 채 이름만 달리하는 경우다. Info나 Data는 a, an, the와 마찬가지로 의미가 불분명한 불용어다. 물론, 각각을 사용함에 따라 의미가 분명히 다르다면 사용해도 무방하다.

-> (내 생각) 객체지향에 기반한 설계가 제대로 이루어지지 않았을 때 이러한 역할이 불분명한 클래스들이 생겨나는 것이 아닌지 생각해보게 된다. 협력을 기반으로 한 설계가 이루어지지 않는다면 단순한 절차지향코드를 작성하게 되고 이러한 작성을 통해 그 절차에 필요한 임시 자료구조가 양산된다고 생각한다.

 

- 긴 이름이 짧은 이름보다 좋다고 생각한다. 검색하기 쉬운 이름이 상수보다 좋다. 이름을 의미있게 지으면 함수가 길어진다. WORK_DAYS_PER_WEEKF를 찾기가 얼마나 쉬운지 생각해보라. 그냥 5를 사용한다면 5가 들어가는 이름을 모두 찾은 후 의미를 분석해 원하는 상수를 가려내야 하리라.

 

- 변수 이름에 타입을 인코딩하는 것을 피하라. 아래와 같은 경우가 있다.

public phoneString: PhoneNumber;
// 타입이 바뀌어도 이름은 바뀌지 않는다.

 

- 개인적으로 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다. 옛날 코드에서 많이 사용하는 접두어 I는 (잘해봤자) 주의를 흐트리고 (나쁘게는) 과도한 정보를 제공한다.

 

- 똑똑한 프로그래머와 전문가 프로그래머 사이에서 나타나는 차이점 하나만 만들자면, 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내놓는다.

 

- 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

 

- 생성자(Constructor)를 중복정의(overload)할 때는 정적 팩토리 메서드를 사용한다. 메서드는 인수를 설명하는 이름을 사용한다. 예를 들어, 다음 두 예제를 살펴보자.

const fulcrumPoint: Complex = Complex.FromRealNumber(23.0);

// 위 코드가 아래 코드보다 좋다.

const fulcrumPoint: Complex = new Complex(23.0);

 

- 해법 영역에서 가져온 이름을 사용하라. VISITOR 패턴에 친숙한 프로그래머는 AccountVisitor라는 이름을 금방 이해한다. JobQueue를 모르는 프로그래머가 있을까? 프로그래머에게 익숙한 기술개념은 아주 많다. 기술 개념에는 기술 이름이 가장 적합한 선택이다.

 

- 문제 영역에서 가져온 이름을 사용하라. 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.

 

- 의미 있는 맥락을 추가하라. addr라는 접두어를 추가하여 addrFirstName, addrLastName, addrState라 쓰면 맥락이 좀 더 분명해진다. 변수가 좀 더 큰 구조에 속한다는 사실이 적어도 독자에게는 분명해진다. 물론 Address라는 클래스를 생성하면 더 좋다. 그러면 변수가 좀 더 큰 개념에 속한다는 사실이 컴파일러에게도 분명해진다.

-> (내 생각) 맥락이라는 단어는 정말 마법과 같다. 코드에 생명력을 불어넣는 느낌이다. 딱딱하게 작성되어 있는 단위 기능을 하는 함수들도 어느 맥락에 들어가느냐에 따라 다양한 역할을 하게 된다. 이 세상에서 '스토리 텔링'이 사랑을 받는 이유처럼 맥락을 분명히 가져가는 코드들은 자연스럽게 몰입이 가능하게 만들고 그로 인해 사랑을 받을 수 있다고 생각한다.

 

- 불필요한 맥락은 없애라. 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다. 이름에 불필요한 맥락을 추가하지 않도록 주의한다.

 

- (내 생각) 개발자는 좋은 문맥 생성(아마 이를 통해 자연스러운 네이밍 능력 향상은 따라오겠지?)을 위해서라도 책 읽기와 글쓰기를 게을리하면 안될 것 같다.

3장. 함수

- 작게 만들어라! 지금까지 경험을 바탕으로 그리고 오랜 시행착오를 바탕으로 나는 작은 함수가 좋다고 확신한다.

 

- 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

 

- 함수가 '한 가지'만 하는지 판단하는 방법이 하나 더 있다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.

 

- 일반적으로 나는 switch 문을 단 한 번만 참아준다. 다형적 객체를 생성하는 코드 안에서다. 이렇게 상속 관계로 숨긴 후에는 절대로 다른 코드에 노출하지 않는다. 물론 불가피한 상황도 생긴다. 나 자신도 이 규칙을 위반한 경험이 여러 번 있다.

 

- 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항)는 가능한 피하는 편이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다.

 

- 함수에 인수 1개를 넘기는 이유로 가장 흔한 경우는 두 가지다.

• 인수에 질문을 던지는 경우(Query)
• 인수를 뭔가로 변환해 결과를 반환하는 경우

- 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 왜냐? 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까! render(true)라는 코드는 헷갈리기 십상이다. IDE에서 코드 위로 커서를 가져가면 render(boolean isSuite)라는 정보가 뜨지만 그다지 큰 도움은 안 된다. 원래는 renderForSuite()와 renderForSingleTest()라는 함수로 나눠야 마땅하다.

 

- 인수가 2개인 함수는 1개인 함수보다 이해하기 어렵다. 예를 들어, writeField(name)는 writeField(outputStream, name)보다 이해하기 쉽다. 둘 다 의미는 명백하지만 전자가 더 쉽게 읽히고 더 빨리 이해된다. 후자는 잠시 주춤하며 첫 인수를 무시해야 한다는 사실을 깨닫는 시간이 필요하다. 그리고 바로 그 사실이 결국은 문제를 일으킨다. 왜냐고? 어떤 코드든 절대로 무시하면 되니까. 무시한 코드에 오류가 숨어드니까.

 

- 인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어본다. 객체를 생성해 인수를 줄이는 방법이 눈속임이라 여겨질지 모르지만 그렇지 않다. 변수를 묶어 넘기려면 이름을 붙여야 하므로 결국은 개념을 표현하게 된다.

 

- 시간적인 결합은 혼란을 일으킨다. 특히 부수 효과로 숨겨진 경우에는 더더욱 혼란이 커진다. 만약 시간적인 결합이 필요하다면 함수 이름에 분명히 명시한다.

 

- 일반적으로 출력 인수는 피해야 한다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체 상태를 변경하는 방식을 택한다.

 

- 함수를 작게 만든다면 간혹 return, break, continue를 여러 차례 사용해도 괜찮다. 오히려 때로는 단일 입/출구 규칙보다 의도를 표현하기 쉬워진다. 반면, goto 문은 큰 함수에서만 의미가 있으므로, 작은 함수에서는 피해야만 한다.

 

- 함수를 어떻게 짜야할까? 처음에는 길고 복잡하다. 들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 나는 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스도 만든다. 그런 다음 나는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다.

 

- 이 장은 함수를 잘 만드는 기교를 소개했다. 여기서 설명한 규칙을 따른다면 길이가 짧고, 이름이 좋고, 체계가 잡힌 함수가 나오리라. 하지만 진짜 목표는 시스템이라는 이야기를 풀어가는 데 있다는 사실을 명심하기 바란다. 여러분이 작성하는 함수가 분명하고 정확한 언어로 깔끔하게 같이 맞아떨어져야 이야기를 풀어가기가 쉬워진다는 사실을 기억하기 바란다.