Clean Code

나쁜 코드가 쌓일 수록 간단한 변경은 없어진다.

매번 얽히고설킨 코드를 '해독’해서 얽히고설킨 코드를 더한다.

시간이 지나면서 쓰레기는 점점 깊어지고 커지고, 청소할 방법이 없어진다. 불가항력이다.

팀의 생산성을 떨어지고 마침대 0에 근접하게 된다.

전적으로 우리 프로그래머에게 있다.

관리자가 일정과 요구사항을 밀어붙이는 이유는 그들의 책임이다. 좋은 코드를 사수하는 일은 우리 프로그래머의 책임이다.

예를 들어, 우리가 의사라고 가정하다. 환자가 순을 씻지 말라고 요구한다. 시간이 너무 걸리니까. 하지만 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까.

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

기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

의도가 분명한 이름이 정말로 중요하다는 사실을 거듭 강조한다.

좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

"보통 나는 확정하기 전에 이름을 여러 차례 바꾼다. 개발 도구는 이름ㅇ르 바꾸기가 상당히 쉽다." - 론 제프리스

코드 맥락이 코드 자체에 명시적으로 드러나야 한다.

나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안된다.

서로 흡사한 이름을 사용하지 않도록 주의한다.

유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다.

일관성이 떨어지는 표기법은 그릇된 정보다.

대충 컴파일 통과하게끔 이름을 바꾸는 것을 피하라

불용어^{noise word}를 추가하는 방식도 적절하지 못하다. (e.g., a1, a2, …​)

a나 the와 같은 접두어를 사용하지 말라는 소리가 아니다.

변수 이름에 variable이라는 단어는 단연코 금물이다.

읽는 사람이 차이를 알도록 이름을 지어라

발음하기 어려운 이름은 토론하기도 어렵다. 바보처럼 들리기 십상이다.

우리는 형편없는 이름을 참아내고 있을 뿐이다.

발음하기 쉬운 이름을 사용하면(명확한 이름을 사용하면) 토론할 때 보다 지적인 대화가 가능해진다.

개인적으로 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. - 엉클 밥

이름 길이는 범위 크기에 비례해야 한다. (휴리스틱 N5)

넣은 정보는 많은데 굳이 인코딩 정보까지 넣을 필요가 없고 이름을 해독하기만 어려워질 뿐이다.

인코딩한 이름은 거의 발음하기 어렵고 오타가 생기기도 쉽다.

범위가 아주 작고 다른 이름들과 충돌되지 않는 선에서 i, j, k는 괜찮다.

전문가 프로그래머는 명료함이 최고라는 사실을 이해한다. 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드는 내놓는다.

제이콥 닐슨의 휴리스틱 평가방법 10가지 중 6번째 - 기억보다는 인식하게 할 것

클래스와 객체 이름은 명사나 명사구가 적합하고 동사는 사용하지 않는다.

Good: Customer, WikiPage, Account, AddressParser

Bad: Manager, Processor, Data, Info 등과 같은 많은 의미의 단어

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

Good: postPayment, deletePage, save

접근자^Accessor, 변경가^Mutator, 조건자^Predicate 는 javabean 표준에 따라 get, set, is 접두어를 붙힌다.

특정 문화에서만 사용하는 농담, 은어(?)는 피하는 편이 좋다.

의도룰 분명하고 솔직하게 표한하라.

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.

find, search, retrieve로 제각각 부르면 혼란스럽다.

메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택한다.

한 단어를 두 가지 목적으로 사용하지 마라.

일관성을 지키고자 add를 사용하더라도 맥락에 맞는 단어를 사용하라.

프로그래머를 코드를 최대한 이해하기 쉽게 짜야 한다. 집중적인 탐구가 필요한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.

코드를 읽는 사람도 프로그래머라는 사실을 명심한다.

모든 이름을 문제 영역^domain에서 가져오는 정책은 현명하지 못하다.

적설한 '프로그래머 용어’가 없다면 문제 영여역에서 이름을 가져온다.

우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.

모든 방법이 실패하면 마지막 수단으로 접두어를 붙힌다.

예를 들어, firstName, lastName street, city, state, zipcode 라는 변수가 있을 경우 state 가 주소의 일부라는 사실을 금방 알아챌까?

고급 휘발유 충전소(Gas Station Deluxe) 어플리케이션을 짠다고 해서 모든 클래스 이름에 GSD라는 접두어를 붙히지 말자.

IDE에서 G를 입력하고 자동 완성 키는 누르면 모든 클래스를 열거할 것이다.

IDE는 개발자를 지원하는 도구이며, IDE를 잘 활용하게끔 인터페이스, 네이밍이 되어야 한다.(이것이 우선되어야 하는 건 아니다.)

같은 주소^Address라도 포트 주소, MAX 주소를 구분해야 한다면 PostalAddress, MAC과 같이 작성하면 의미가 좀 더 분명해진다. 이것이 이름을 붙이는 이유가 아니던가?

좋은 이름을 선택하려명 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 이것이 제일 어렵다.

사람들이 이름을 바꾸지 않으려는 이뉴 하나는 다른 개발자가 반대할까 두려워서다.

우리들 대다수는 자신이 짠 클래스 이름과 메서드 이름을 모두 암기하지 못한다. 암기는 요즘 나오는 도구에게 맡기고, 가독성있는 코드를 짜는 데 집중해야 마땅하다.

여느 코드 개선 노력과 마찬가지로 이름 역시 나름대로 바궜다가는 누군가 질책할지도 모른다. 그렇다고 코드를 개선하려는 노력을 중단해서는 안 된다.

자료 구조체의 전형적인 형태는 public 변수만 있고 method가 없는 클래스

좀 더 일반적인 형태는 빈(bean) 구조.

DTO의 특수한 형태

public 변수가 있거나 private 변수에 get/set 함수가 있는 자료 구조지만, 대개 save나 find와 같은 탐색 함수도 제공.

활성 레코드드는 데이터베이스 테이블이나 다른 소스에서 자료를 직접 변환한 결과다.

불행히도 활성 레코드에 비지니스 규칙 메서드를 추가해 이런 자료 구조를 개체로 취급하는 개발자가 흔하다.

하지만 이는 바람직하지 않다. 그러면 자료 구조도 아니고 객체도 아닌 잡종 구조가 나오기 때문이다.

활성 레코드는 자료 구조로 취급하면 된다.

시스템을 구현할 때.

우수한 소프트웨어 개발자는 편견없이 이 사실을 이해해 직면한 문제에 최적인 해결책을 선택한다.

먼저 오류^error와 예외^exception를 구분할 줄 알아야 한다.

여러 해 동안 checked와 unchecked 예외의 장단점을 가지고 논쟁이 이뤄졌다.

예전에는 checked 예외가 좋다고 여겨졌다. 실제로도 장점이 존재한다.

but, 오늘날에는 안정적인 소프트웨어를 만드는 요소로 checked 예외가 반드리 필요하지 않다는 사실이 분명해졌다.

C#, C++, python, rube 에서는 checked 예외를 지원하지 않는다. 그럼에도 안정적인 소프트웨어를 구현하기에 무리가 없다.

checked 예외가 치르는 비용에 상응하는 이익을 제공하는지 (철저히) 따져봐야 한다.

checked 예외는 OOP^{Open Closed Principle}를 위반한다.

때로는 확인된 예외도 유용하지만, 일반적인 어플리케이션은 의존성이라는 비용이 이익보다 크다.

"예외의 상태 메세지에 실패 관련 정보를 담아라." - 이펙티브자바 3판. 아이템 75

"추상화 수준에 맞는 예외를 던져라." - 이펙티브자바 3판. 아이템 73

오류를 분류하는 방법은 수없이 많다. (발생한 위치, 발생한 컴포넌트, 유형 등..)

오류를 정의할 때, 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.

흔히 예외 클래스가 하나만 있어도 충분한 코드가 많다. 예외 클래스에 포함된 정보로 오류를 구분해도 괜찮은 경우가 그렇다.

한 예외는 잡아내고 다른 예외는 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용한다.

예외 처리를 할 때 특수 사례 패턴^{SPECIAL CASE PATTERN}을 사용하면 유용하다.

클라이언트 코드가 예외적인 상황을 처리할 필요가 없고, 클래스나 객체가 예외적인 상황을 캡슐화해서 처리한다.

에러를 코드로 반환하라는 얘기는 아닌 것 같다. 정상 처리할 수 있는 데이터로 반환하라는 얘기이다.

메서드에 null을 반환하는 것보다 예외를 던지거나 특수 사례 객체를 반환하면 유용하다.

많은 경우 특수 사계 객체가 손쉬한 해결책이다.

파라미터가 null 이 들어올 경우 InvalidArgumentException 을 던질 수 있다. 하지만 외부에서 해당 예외 처리가 필요해진다.

assert 문을 사용할수도 있지만, 이는 문서화를 통해 코드를 읽기에는 편하지만 문제를 해결하지는 않는다.

대다수 프로그래밍 언어는 호출자가 실수도 넘기는 null을 적절히 처리하는 방법이 없다.

애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다.

깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.