클린코드 1~2장 정리

1장. 깨끗한 코드

원초적 난제

모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다. 간단히 말해 빨리 가려고 시간을 들이지 않는다.
그러나, 오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다. 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드란?

비야네 스트롭스트룹 - C++ 창시자

논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다.
깨끗한 코드는 한 가지를 제대로 한다.

그래디 부치 - Object Oriented Analysis and Design With Application 저자

깨끗한 코드는 단순하고 직접적이다. 결코 설꼐자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.

가독성을 강조

'큰' 데이브 토마스 - OTI 창립자, 이클립스 전략의 대부

깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이스와 인수 테스트 케이스가 존재한다. 깨끗한 코드에는 의미있는 이름이 붙는다. 의존성은 최소이며 각 의존성을 명확히 정의한다.

마이클 페더스 - Working Effectively with Legacy Code 저자

깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다.

요약하면, 주의 -> 코드를 주의 깊게 짜는 방법, 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드

론 제프리스

• 모든 테스트를 통과한다.
• 중복이 없다.
• 시스템 내 모든 설계 아이디어를 표현한다.
• 클래스, 메서드, 함수 등을 최대한 줄인다.

워드 커닝햄 - 위키 창시자, 피트 창시자, 코드를 사랑하는 프로그래머들의 대부

코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 된다.

깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다는 의미 -> 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다.

2장. 의미 있는 이름

1. 의도를 분명히 밝혀라

변수나 함수 그리고 클래스 이름은 다음과 같은 질문에 모두 답해야 한다.

• 변수(혹은 함수나 클래스)의 존재 이유는?
• 수행 기능은?
• 사용 방법은?

만약 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 의미이다.

int d;  // 경과 시간(단위: 날짜)

이름 d는 아무 의미도 드러내지 않는다. 경과 시간이나 날짜라는 느낌이 안 든다.

다음 코드는 무엇을 할까?

public List<int[]> getThem(){
    List<int[]> list1 = new ArrayList<int[]>();
    for(int[] x : thelist)
        if(x[0] == 4)
            list1.add(x);
    return list1;
}

이 코드가 하는 일을 짐작하기 어렵다. 왜?🤦‍♀️
복잡한 문장도 없고, 공백과 들여쓰기도 적당하고, 변수도 세 개뿐이고, 화려한 클래스나 다형 메서드도 없습니다.
문제는 코드의 단순성이 아니라, 코드의 함축성이다.
📌 즉, 코드 맥락이 코드 자체에 명시적으로 드러나지 않는다.

1. theList에 무엇이 들었는가?
2. theList에서 0번째 값이 어째서 중요한가?
3. 값 4는 무슨 의미인가?
4. 함수가 반환하는 리스트 list1을 어떻게 사용하는가?

public List<Cell> getFlaggedCells(){
    List<Cell> flaggedCells = new ArrayList<int[]>();
    for(Cell cell : gameBoard)
        if(cell.isFlagged())
            flaggedCells.add(cell);
    return flaggedCells;
}

이렇게 단순히 이름만 고쳤는데도 함수가 하는 일을 이해하기 쉬워졌다.

2. 그릇된 정보를 피하라

코드에 그릇된 단서를 남겨서는 안 된다. -> 코드 의미를 흐린다.
나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.
ex) hp, aix, sco등
여러 계정을 그룹으로 묶을 때, 실제 List가 아니라면 accountList라 명명하지 않는다. 계정을 담는 컨테이너가 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는 셈이다.
그러므로 accountGroup, bunchOfAccount,Accounts라 명명한다.

서로 흡사한 이름을 사용하지 않도록 주의한다.
한 모듈에서 XYZControllerForEfficientHandlingOfStrings라는 이름과 XYZControllerForEfficientStorageOfStrings라는 이름을 사용한다면 헷갈릴 것이다.
유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.

3. 의미 있게 구분

컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
예를 들어, 동일한 범위 안에서 다른 두 개념에 같은 이름을 사용하지 못한다.
컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어 를 추가하는 방식은 적절하지 못한다. 이름이 달라야 한다면 의미도 달라져야 한다.
연속적인 숫자를 덧붙인 이름(a1, a2, ..., aN)은 의도적인 이름은 정반대다.

public static void copyChars(char a1[], char a2[]){
    for(int i = 0; i < a1.length(); i++){
        a2[i] = a1[i];
    }
}

위 코드에서 함수 인수 이름으로 a1 -> source, a2 -> destination을 사용한다면 코드 읽기 가 훨씬 더 쉬워진다.
불용어를 추가하한 이름 역시 아무런 정보도 제공하지 못한다. Product라는 클래스가 있을 때, 다른 클래스를 ProductInfo 혹은 ProductData 라 부른다면 개념을 구분하지 않은 채 이름만 달리한 경우다.
읽은 사람이 차이를 알도록 이름을 지어야 한다.

4. 발음하기 쉬운 이름

class DtaRcrd102 {
    private Date genymdhms;
    private Date modymdhms;
    private final String pszqint = "102";
    /*...*/
}

class Customer {
    private Date generationTimestamp;
    private Date modificationTimestamp;
    private final String pszqint = "102";
    /*...*/
}

아래 코드는 지적인 대화가 가능해진다.

5. 검색하기 쉬운 이름

문자 하나를 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다는 문제점이 있다. 만약 e라는 변수가 있고, 이를 찾기 위해 검색한다면 e가 포함된 파일 이름이나 코드가 검색되어서 원하는 것을 찾기가 어렵다. 그러나 MAX_CLASSES_PER_STUDENT라고 이름을 명시한다면 훨씬 찾기가 쉽다.
이름을 의미있게 지으면 함수가 길어지지만, 찾기가 쉬워진다.

6. 인코딩을 피하라

유형이나 범위 정보까지 인코딩에 넣으면 그만큼 이름을 해독하기 어려워진다. 예시로 멤버 변수에 m_이라는 접두어를 붙이는 규칙이 있었다.
인터페이스 클래스와 구현 클래스를 구분하기 위해 인코딩이 필요한 경우도 있다. 나로서는 내가 다르는 클래스가 인터페이스라는 사실을 남에게 알리고 싶지 않기 때문에 인터페이스 클래스와 구현 클래스 중 하나를 인코딩해야 한다면 구현 클래스 이름을 선택한다. ShapeFactoryImp나 CShapeFactory가 IShapeFactory보다 좋다.

7. 클래스/메서드 이름

클래스 이름과 객체 이름은 명사나 명사구가 적합하다. Customer, WikiPage, Account, AddressParser등이 좋은 예다.
Manager, Processor, Data, Info등과 같은 단어는 피하고, 동사는 사용하지 않는다.

메서드 이름은 동사나 동사구가 적합하다. postPayment, deletePage, save 등이 좋은 예다.
점ㅂ근자, 변경자, 조건자는 javabean 표준에 따라 값 앞에 get, set, is를 붙인다.

8. 한 개념에 한 단어를 사용

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다. 예를 들어, 똑같은 메서드를 클래스마다 fetch, retrieve, get으로 제각각 부르면 혼란스럽다. 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.

하지만 때로는 같은 맥락이 아닌데도 일관성을 고려해 add라는 단어를 선택한다. 지금까지 구현한 add 메서드는 모두가 기존 값 두 개를 더하거나 이어서 새로운 값을 만든다고 가정하자. 새로 작성하는 메서드는 집합에 값 하나를 추가한다.
이 메서드를 add라 불러도 괜찮을까? -> 기존의 add 메서드와 맥락이 다르다. 그러므로 insert나 append라는 이름이 적당하다.

9. 의미 있는 맥락을 추가

예를 들어, firstName, lastName, street, houseNumber, city, state, zipcode라는 변수들을 보면 주소라는 사실을 금방 알아챌 수 있다. 하지만 어떤 메서드가 state라는 변수 하나만 사용한다면? 주소의 일부라는 사실을 금방 알아챌까?
이럴 때는 addr이라는 접두사를 추가해 사용하면 맥락이 좀 더 분명해진다.