(CleanCode) 1장~3장

<목차>

• 1장 깨끗한 코드
• 2장 의미있는 이름
• 3장 함수

1장 깨끗한 코드

나쁜 코드에 발목이 잡혀 고생한 기억이 있는가? → YES..

코드가 정말이지 너무나도 엉망이라 몇 시간으로 예상한 업무가 몇 주로 늘어진 경험이 있는가? → YES....

한 줄만 고치면 되리라 예상했다가 모듈을 수백 개 건드린 경험이 있는가? → YES...........

나의 코드가 나쁜 코드인 이유에는 수 많은 이유가 있겠지만 항상 나의 답변은 일정이 촉박해서, 고객사의 무리한 요구, 코드리뷰 문화의 부재..등등 여러가지 이유를 갖다대었다.

하지만 로버트 씨는 그것이 전적으로 나의 잘못인 경우를 꼬집어주었다. 나의 코드가 나쁜 이유는 바로 내가 전문가잡지 못한 프로그래머였기 때문...!

일정이 촉박하던, 고객사가 갑질을 하던 좋은 코드를 사수하는 일은 전적으로 프로그래머의 책임 영역이라는 것이라는 것이다. 이 말에 나는 동의를 하지 않을 수가 없었다..

깨끗한 코드란?

• 바야네 스트롭스트룹

→ 우아하고 효율적인 코드. 간단한 논리구조. 의존성을 줄여 유지보수를 쉽게. 등등

→ 철저한 오류처리 ex. 메모리 누수, 경쟁상태, 일관성 없는 명명법 등...

• 그래디 부치

→ 가독성 좋은 코드 (명쾌한 추상화와 단순한 제어문)

• big 데이브 토마스

→ 가독성 + 다른사람이 고치기 쉬운 코드

• 마이클 페더스

→ 주의를 기울여 짠 코드. 즉 모든 상황을 고려하여 고칠 필요가 없을정도로 주의를 기울인 코드.

• 론 제프리스

→ 중복을 제거한 코드

→ 표현력 좋은 코드

→ 초반부터 간단한 추상화 고려하기

읽기 쉬운 코드를 짜야 하는 이유 : 우리는 코드를 작성하면서 기존의 코드를 끊임없이 읽고 분석한다. 읽기 쉬운 코드일수록 새 코드를 짜기가 수월해진다.

2장 의미있는 이름

작년 프로젝트를 진행했을 때 전 사수에게 변수명으로 혼났던 기억을 떠올리며...

의도를 분명히 밝히기

• 의도를 밝히는 코드 int d; //경과 시간 → int daysSinceCreation;
• 코드의 맥락이 명시적으로 드러날 수 있게 함축성 있는 코드를 짜야한다.

그릇된 정보를 피하기

• 널리 쓰이는 단어를 다른 의미의 변수로 사용하는것은 지양해야한다.
• 컨테이너의 유형은 넣지 않는것이 바람직하다. ex) List 대신 group
• 서로 흡사한 이름은 사용하지 않아야한다.
• 소문자 l, 대문자 O 는 숫자 1과 0으로 혼동을 줄 수 있다.

의미있게 구분하기

컴파일러나 인터프리터만 통과하려는 목적으로 코드를 구현하지 말자 → 완전 뜨끔한 부분..정말 안좋은 습관.

• 연속된 숫자를 덧붙인 코드

ex) 저자의 의도가 전혀 드러나지 않는 코드

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

→ 인수의 이름을 source와 destination 를 사용했다면 읽기 쉬운 코드가 된다.

• 불용어(nois word)를 추가하는 방식

→ Customer 클래스와 CustomerObject 클래스의 이름이 공존한다면 이들은 아무런 정보도 제공하지 못한다. 읽는 사람이 차이를 알도록 이름을 짓자.

그 외 안좋은 명명의 예들..) getActiveAccont() getActiveAccounts() getActiveAccountInfo()

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

말 그대로 발음하기 쉬운 이름 사용하자.

ex) genymdhms(generate date, year, month, day, hour, minute, second) → 어떻게 읽냐..

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

문자 하나를 사용하는 이름과 상수는 텍스트코드에서 눈에 쉽게 뜨지 않는다.

기억력 자랑하는 변수명 짓지말기

자신만 아는 변수명은 그 누구에게도 도움이 되지 않는다.

클래스 이름

→ 명사나 명사구로 짓기. 동사는 사용하지 않는다.

ex)

Customer, WiKiPage, Account, AddresParser ← 좋은 예

Manager, Processor, Data, Info ← 나쁜 예

메서드 이름

→ 동사나 동사구가 적합.

→ 접근자, 변경자, 조건자는 자바 표준에따라 get, set, is 를 붙인다.

기발한 이름 피하기

변수명으로 농담따먹기 하지 말자. 나만 웃길 확률이 크다.

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

똑같은 메서드를 클래스마다 다르게 부르면 혼란스럽다. 일관성 있는 어휘를 사용하여 코드를 짜자.

한 단어를 두가지 목적으로 사용하지 않기

만약 두 개의 값을 더해서 새 값을 만드는 경우와, 집합에 값을 추가하는 경우가 있다고 했을 때, 두 가지 모든 경우에 add 라는 메서드 명을 부여하면 혼란스럽다. add / append or insert 라는 이름으로 적절히 구분해서 다르게 부여되어야한다.

해법 영역과 문제영역(domain)을 적절히 구분하여 이름을 가져오자

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

문제영역에서 가져온 이름 : 적절한 프로그래머 용어가 없을 시, 도메인 용어를 가져온다. 전문가에게 의미를 물어 파악할 수 있음

3장 함수

• 함수는 무조건 작게 만들기

→ 이중 중첩 구조가 생길만큼 함수가 크면 안된다. 함수에서 들여쓰기 수준은 2단을 넘어가면 안됨.

• 함수의 기능은 한가지만 하기
• 함수 당 추상화 수준은 하나로 하기
• 코드는 위에서 아래로 이야기퍼럼 읽혀야한다. 내려가기 규칙
• switch 문은 다형성 객체 코드 안에서 한번으로 끝내기
• 서술적인 이름 사용하기.
• 입력 인수는 없을수록 좋다.