Clean Code 내용 정리 - 1

대학시절 프런트 개발을 하다가, ebay에서 웹 개발을 하면서 백엔드 개발을 주로 하다 보니, Java나 C#으로 개발을 주로 하게 되었는데, 모르는 부분도 많고 함께 프로젝트를 만들기 때문에 좀 더 좋은 개발을 하고 싶어서, 1년 전에 샀던 책을 다시 펴서 정리한다.

1장. Clean Code

나쁜 코드가 만드는 결과

• 개발 속도의 감소
• 팀 생산성의 하락, 이후 재개발 필요
• 유지 보수의 어려움

깨끗한 코드란?

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

2장. 의미 있는 이름

핵심은 다음과 같다.

1. 의도를 분명히 밝히기.

   • ex) int elapsedTimeInDays, daysSinceCreation 등등

2. 그릇된 정보를 피하기.

   • 일관성을 지켜야한다.
3. 의미 있게 구분하기.
4. 발음하기 쉬운 이름을 사용하기.
5. 검색하기 쉬운 이름을 사용하기.

6. 인코딩을 피하기.

   • 헝가리식 표기법
   • 멤버 변수 접두어
   • 인터페이스 클래스와 구현 클래스
7. 자신의 기억력을 자랑하지 말기.
8. 클래스 이름은 명사나 명사구.
9. 메서드 이름은 동사나 동사구.
10. 기발한 이름을 피하기
11. 한 개념에 한 단어 사용
12. 말장난하지 말기
13. 해법 영역에서 가져온 이름 사용하기

-   전산, 알고리즘, 패턴, 수학 용어들은 사용해도 괜찮다.

14. 문제 영역에서 가져온 이름 사용하기

-   적절한 프로그래머 용어가 없다면, 문제 영역에서 가져온다.

15. 의미 있는 맥락을 추가

-   스스로 의미가 분명하게 해 주기. -> 클래스, 함수, 이름 공간에 넣어 맥락 주기
-   모든 방법이 어렵다면 접두어 사용하기

16. 불필요한 맥락 없애기.

핵심 중 하나는, 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고, 문화적인 배경이 같아야 한다.

3장. 함수

함수의 규칙은 다음과 같다.

1. 작게 만들기

   • 일반적으로 2줄, 3줄, 4줄이 이상적으로 좋다.

   • 블록과 들여 쓰기.

     • if/else/while 문 등에 들어가는 블록은 한 줄이여야 함.

2. 한 가지만 하기

   • 함수는 한 가지를 해야 하고 한 가지를 잘해야 한다.

3. 함수 당 추상화 수준은 하나로

   • 한 함수에 추상화 수준을 섞으면 코드를 읽는 사람이 헷갈림

   • 내려가기 규칙 : 위에서 아래로 코드 읽기

     • 마치 이야기처럼

4. Switch 문

   • 다형성 사용해서 최대한 숨기고 반복하지 않게 하기.

     • 객체 안에서 숨기기
     • 최대한 한 번만 사용하기

5. 서술적인 이름 사용

   • 서술적인 이름이 설계에서 더 뚜렷한 의미를 가지고 개선하기 쉬워짐
   • 일관성 유지하기

6. 함수 인수

   • 함수에서 이상적인 인수는 0개이다.

   • 1개(단항), 2개(이항)까지고 좋고, 3개(삼항)는 가능한 피하고, 4개(다항)는 이유가 필요하다.

     • 점점 더 읽기 어려워짐.
     • includeSetupPageInfo(new PageContent) 보다는 includeSetupPage()가 더 읽기 좋음

     • 단항 형식의 좋은 예

       • boolean fileExists("MyFile")

     • 이항 함수의 좋은 예

       • Point p = new Point(0, 0)

   • 동사와 키워드

     • 함수의 의도나 인수의 순서와 의도를 제대로 표현하려면 좋은 함수가 필수

     • 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다.

       • ex) writeField(name) 등
       • assertEquals보다는 assertExpectedEqualsActual(expected, actual) 이 더 좋다.

7. 부수 효과를 일으키지 마라

   • 즉, 함수에서 한 가지를 하겠다고 하고, 다른 기능을 넣지 마라

   • 출력 인수

     • 일반적으로는 출력 인수를 피해라.
     • appendFooter(s) 보다는 report.appendFooter()처럼 작성하기.

8. 명령과 조회를 분리하기

   • 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야 한다.

9. 오류 코드보다 예외를 사용하라

   • 명령 함수에서 오류 코드를 반환하는 방식은 명령/조회 분리 규칙을 미묘하게 위반한다.

   • Try/Catch 블록 뽑아내기.

     • 흉측함, 별도 함수로 뽑아내는 편이 좋다.

   • 오류 처리도 한 가지 작업

     • 오류 처리도 오류만 처리해야 한다.

   • 오류 클래스를 따로 선언하면, 해당 클래스는 의존성 자석이 되기 때문에 다른 코드에서 import 해서 사용해야 한다.

     • 즉, 오류 클래스가 변한다면 클래스 전부를 다시 컴파일하고 다시 배치해야 한다.
     • 따라서 일반적으로는 예외를 사용하기
10. 반복하지 말기

-   AOP(Aspect Oriented Programming), COP(Component Oriented Programming) 등 모두가 어떤 면에서는 **중복 제거 전략**이 들어간다.

11. 구조적 프로그래밍

-   모든 함수와 함수 내 모든 블록에 **입구와 출구가 하나만 존재해야 한다**
-   루프 안에서 break나 continue를 사용해서는 안된다. goto는 아시다시피 절대로 안됨
-   해당 문제는 함수가 아주 클 때 상당한 이익을 제공.

12. 함수는 짜는 방법

-   일종의 글짓기와 비슷
-   초안은 길고 복잡할 수 있지만,
    수정하면서 코드를 다듬고 함수를 만들고, 이름을 바꾸고 중복을 제거하고 메서드를 제거하기

결론

모든 시스템은 특정 응용 분야 시스템을 기술할 목적으로 프로그래머가 설계한 DSL(Domain Specific Language, 도메인 특화 언어)로 만든다. 이러한 기술 들은 함수를 잘 만드는 방법이다. 그러나 정말로 중요한 것은 시스템이다.