읽기 좋은 코드가 좋은 코드다.

현재 재직 중인 회사의 개발팀 권장도서 중 하나이다. 장거리 출퇴근을 통해 읽은 두 번째 책이다.

이 책을 읽고 지난 작업을 돌이켜보니, 작성했던 코드가 읽기 좋은 코드는 아니었음에는 틀림이 없는 것 같다.

굳이 변명하자면, 한정된 자원(연기도 불가능한 촉박한 기간, 나눠서 할 인원도 없는 인력풀 등) 안에 기능이 제공되어야 하는 환경에서, 코드의 질을 높이겠다고 기간을 더 달라던가 기능을 축소하겠다는 말은, 완성된 기능이 반드시 먼저 제공되어야 함만을 바라보는 여러 이해관계자에게는 단순한 개발자의 사치로밖에 느껴지지 않았을 거라 믿어 의심치 않는다.(설령 대면 상태에서는 알았다고 시큰둥하게 넘어가더라도, 뒤에서는 도대체가 이해할 수가 없다는 표정과 뒷말이 오가는 경우가 다반사이다;;)

그럼에도 불구하고, 나 스스로의 발전을 위해서는 "노력 했었어야 하지 않았나" 반성하게 된다.

요즘들어 변수이름/함수이름을 짓는데에도 한시간 이상이 걸리고, 함수를 공통으로 뽑아낼때도 꽤 많은 시간을 고민해보는 횟수들이 잦아지면서, 다시 한번 좋은 코드에 대해 반복학습이 필요함을 느낀다.

아래는 이 책을 읽으면서, 좋은 코드를 작성하기 위한 하나하나의 상세한 방법(기술)보다는, 큰 맥락에서 늘 가지고 있어야 하는 태도와 관점을 정리한 내용이다.

#01. 코드는 이해하기 쉬워야 한다.

• 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.
• 어떤 사람이 여러분의 코드를 완전히 이해한다는 것은 그가 코드를 자유롭게 수정하고, 버그를 짚어내고, 수정된 내용이 여러분이 작성한 다른 부분의 코드와 어떻게 상호작용하는지 알 수 있어야 한다는 사실을 의미한다.
• 적은 분량으로 코드를 작성하는 것이 좋은 목표긴 하지만, 이해를 위한 시간을 최소화하는 게 더 좋은 목표다.

#02. 이름에 정보 담기

• tmp라는 이름은 대상이 짧게 임시적으로만 존재하고, 임시적 존재 자체가 변수의 가장 중요한 용도일때에 한해서 사용해야 한다.
• 좁은 범위(scope)에서만 사용되는 변수의 이름에 많은 정보를 담을 필요가 없다.
• 즉, 변수의 타입이 무엇인지, 초기값이 무엇인지, 그것이 어떻게 사라지는지 등과 같은 변수가 담고 있는 모든 정보가 쉽게 한눈에 보이므로 짧은 이름을 사용해도 상관없다.
• 특정 프로젝트에 국한된 의미를 가진 약어 사용은 좋은 생각이 아니다. 이런 이름은 프로젝트에 새로 합류한 사람에게 비밀스럽고 위협적인 모습으로 다가온다. 
• 시간이 흐르고 흐르면, 심지어 이름을 만들어낸 장본인에게조차 비밀스럽고 위협적인 모습을 지니게 된다.

#03. 오해할 수 없는 이름들

• 어떤 이름을 정하기 전에 항상 최악의 경우를 가정하고 이름의 의미가 잘못 이해되는 가능성을 고려해봐야 한다. 
• 최선의 이름은 이러한 오해가 쉽게 일어나지 않는다.

#04. 미학

• 잘 생각해보면 여러분이 보내는 시간 대부분은 코드를 그저 바라보는 데 소요된다.
• 코드를 흝어보는 데 걸리는 시간이 적을수록, 사람들은 코드를 더 쉽게 사용할 수 있다.
• 지난 프로젝트에서 '잘못된' 스타일을 사용하는 경우도 많았지만, 일관성 유지가 훨씬 더 중요했으므로 해당 프로젝트의 스타일을 따랐다.
• 일관성 있는 스타일은 '올바른' 스타일보다 더 중요하다.

#05. 주석에 담아야 하는 대상

• 주석의 목적은 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하게 돕는 데 있다.
• 나쁜 이름에 대한 변명을 주석이 할 이유는 없다.
• 좋은 이름은 함수가 사용되는 모든 곳에서 드러나므로 좋은 주석보다 더 낫다.
• 코드가 가진 나쁜 가독성을 메우려고 노력하는 '애쓰는 주석'을 원하지 않는다.
• 이러한 규칙을 대게 [좋은 코드 > 나쁜코드 + 좋은 주석]이라는 공식으로 설명한다.
• 여러분이 작성한 코드를 다른 누군가가 읽는다면 "아니, 이게 뭐 하는 코드야?"라고 생각하는 순간이 있기 마련이다.
• 여러분이 해야 하는 일은 바로 그런 부분에 주석을 다는것이다.
• 사람들이 코드를 더 쉽게 읽을 수 있다면 그것이 무엇이든 상관없이 기꺼이 설명하라는 것이다.
• 그 내용이 무엇, 어떻게, 혹은 왜(또는 셋 모두) 중에서 어느 것을 포함해도 상관없다.
• 주석을 작성하는 과정
• 마음에 떠오르는 생각을 무조건 적어본다.
• 주석을 읽고 무엇이 개선되어야 하는지 (그런 부분이 있다면) 확인한다.
• 개선한다.

#06. 명확하고 간결한 주석 달기

• 주석 달기는 코드를 작성하면서 생각했던 바를 나중에 코드를 읽는 사람에게 전달해주는 것이다.

#07. 읽기 쉽게 흐름제어 만들기

• 영어 어순과 일치한다.
• 왼쪽 : 값이 더 유동적인 '질문을 받는' 표현
• 오른쪽 : 더 고정적인 값으로, 비교대상으로 사용되는 표현
• 좋은 예) 당신이 적어도 18세라면..
• 나쁜 예) 만약 18년이 당신의 나이보다 작거나 같다면..
• 부정이 아닌 긍정을 다루어라.
• 좋은 예) if (debug)
• 나쁜 예) if (!debug)
• 간단한 것을 먼저 처리하라.
• 더 흥미롭고, 확실한 것을 먼저 다루어라.
• 줄 수를 최소화하는 일보다 다른 사람이 코드를 읽고 이해하는 데 걸리는 시간을 최소화하는 일이 더 중요하다.
• 기본적으로 if/else를 이용하라.
• 삼항 연산은 매우 간단할 때만 사용해야 한다.
• 함수 중간에서 반환하는 것은 완전히 허용되어야 한다.
• 중첩이 일어날 때마다 코드를 읽는 사람의 마음 속에 존재하는 '정신적 스택'에 추가적인 조건이 입력된다.
• 수정해야 하는 상황이라면 여러분의 코드를 새로운 관점에서 바라보라. 뒤로 한걸음 물러서서 코드 전체를 보라.

#08. 거대한 표현을 잘게 쪼개기

• 한 줄짜리 거대한 표현으로 작성하는것이 매우 영리하다고 생각되고, 짧은 코드에 논리를 집어넣는 행위에는 어떤 즐거움이 있기 때문에 이해할 만한 일이다.
• 문제는 바로 그런 코드가 나중에 코드를 읽는 사람에게는 정신적인 장애물이 된다는 데 있다.

#09. 변수와 가독성

• 변수가 적용되는 범위를 최대한 좁게 만들어라.
• 코드를 읽는 사람이 한꺼번에 생각해야 하는 변수의 수를 줄여주기 때문이다.
• 많은 메소드를 정적(static)으로 만들어서 클래스 멤버 접근을 제한해라.
• 이 메소드의 코드가 저 클래스 멤버 변수들로부터 독립적이라는 사실을 알려주는 매우 좋은 방법이다.
• static 선언으로 외부에서 해당 메소드의 직접 참조여부를 제공한다고만 생각했으나, 클래스 멤버 변수와 독립적인 관계라는 의미를 제공한다것이 새로웠음
• 커다란 클래스를 여러 작은 클래스로 나누는 목적은 데이터, 즉 변수를 서로 분리하는데 있기 때문이다.
• 변수값이 달라지는 곳이 많을수록 현재값을 추측하기 더 어려워진다.

#10. 상관없는 하위문제 추출하기

• 주어진 함수나 코드 블록을 보고, 스스로에게 질문하라. "상위수준에서 본 이 코드의 목적은 무엇인가?"
• 코드의 모든 줄에 질문을 던져라. "이 코드는 직접적으로 목적을 위해서 존재하는가? 혹은 목적을 위해서 필요하긴 하지만 목적 자체와 직접적으로 상관없는 하위문제를 해결하는가?"
• 만약 상당히 원래의 목적과 직접적으로 관련되지 않은 하위문제를 해결하는 코드 분량이 많으면, 이를 추출해서 별도의 함수로 만든다.
• 추출한 하위문제는, 해당 하위문제를 사용하는 상위의 프로젝트를 전혀 몰라야 한다.
• 자잘한 함수를 사용하면 오히려 가독성을 해친다.
• 작은 함수들이 다른 프로젝트에서도 사용된다면 추출하는 것이 그리 나쁘지만은 않다. 하지만 그런 순간이 오기 전에는 그럴 필요가 없다.

#12. 생각을 코드로 만들기

• '쉬운 말'로 자신의 생각을 지식이 부족한 사람에게 전달하는 기술은 매우 소중하다.
• 프로그램이 수행하는 일을 설명해주는 가장 주된 방법은 결국 소스코드라는 관점을 가진다. 때문에 코드도 역시 '쉬운 말'로 작성해야 한다.

#13. 코드 분량 줄이기

• 가장 읽기 쉬운 코드는 아무것도 없는 코드다.
• 완벽하고 다양한 경우를 모두 대비하여 해결하려 하지 말라.
• 간단한 코드만으로도 약 90%의 실행속도 향상을 이루거나, 원래 분량의 1/4에 해당하는 상대적으로 짧은 코드로 문제의 절반을 해결하는 경우도 종종있다.
• 매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라.

#14. 테스트와 가독성

• 테스트 코드를 실제 코드가 어떻게 동작하며 어떻게 사용되어야 하는지에 관한 비공식적인 문서라고 생각한다.
• 따라서 테스트 코드가 읽기 쉬우면, 개발자는 실제 코드가 어떻게 동작하는지 그만큼 더 쉽게 이해할 수 있다.
• 다른 프로그래머가 수정하거나 새로운 테스트를 더하는 걸 쉽게 느낄 수 있게 테스트 코드는 읽기 쉬워야 한다.
• 코드가 왜 현재 테스트에서 실패하는지 쉽게 진단할 수 있어야 하고, 새로운 테스트도 쉽게 덧붙일 수 있어야 한다.
• 테스트에서는 길고 다소 복잡해 보이는 이름(테스트 함수명)을 붙이는 걸 두려워할 필요가 없다.
• 이는 실제 코드베이스에서 호출되는 함수가 아니다. 따라서 '함수명을 너무 길지 않게 해야 한다'는 일반적인 원리가 적용되지 않는다.
• 지금 작성하는 코드의 테스트 코드를 나중에 작성할 거라는 사실을 염두에 두면 재미있는 일이 벌어진다.
• 지금 작성하는 코드를 나중에 테스트하기 쉽도록 설계하게 되는 것이다.