개발자의 시크릿노트 책 [클린코드]

1. Clean code란 무엇인가?

---

 

"나는 우아하고 효육적인 코드를 좋아한다.

논리가 간단해야 버그가 숨어들지 못한다.

의존성을 최대한 줄여야 유지보수가 쉬워진다.

오류는 명백한 전력에 의거해 철저히 처리한다.

성능을 최적으로 유지해야 사람들이 원칙없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다.

깨끗한 코드는 한 가지를 제대로 한다."

 

- C++ 창시자이자 C++ Programming Language 저자 Bjarne Stroustrup -

 

---

 

"깨끗한 코드는 단순하고 직접적이다.

깨끗한 코드는 잘 쓴 문장처럼 읽힌다.

깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다.

오히려 명쾌한 추상화와 단순한 제어문으로 가득하다."

 

- Object Oriented Analysis and Design with Application 저자 Grady Booch -

 

---

 

"깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.

단위 테스트 케이스와 인수 테스트 케이스가 존재한다.

깨끗한 코드에는 의미있는 이름이 붙는다.

특정 목적을 당성하는 방법은 하나만 제공한다.

의존성은 최소이며 각 의존성을 명확하게 정의한다.

API는 명확하며 최소로 줄였다.

언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기에

코드는 문학적으로 표현해야 마땅하다."

 

- OTI 창립자이자 이클립스 전략의 대부 Dave Thomas -

 

---

 

"깨끗한 코드의 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있다.

깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다.

고치려고 살펴봐도 딱히 손 댈 곳이 없다.

작성자가 이미 모든 사항을 고려했으므로.

고칠 궁리를 하다보면 언제나 제자리로 돌아온다.

그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다."

 

- Working Effectively with Legacy Code 저자 Micheal Feathers -

 

---

 

"최근 들어 나는 켄트 백이 제안한 단순한 코드 규칙을 구현을 시작한다.

중요한 순으로 나열하자면 간단한 코드는 '모든 테스트를 통과한다',

'중복이 없다', '시스템 내 모든 설계 아이디어를 표현한다',

'클래스, 메서드, 함수 등을 최대한 줄인다' (후략)"

 

- Extrme Programming Installed와 Extreme Programming Adventure in C# 저자 Ron Jeffries -

 

---

 

"코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면

깨끗한 코드라 불러도 되겠다.

코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다."

 

- 위키 창시자, 익스트림 프로그래밍 공동창시자 Ward Cunningham -

 

---

 

"이 책은 우리 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다.

여기서 가르피는 교훈과 기법은 우리 진영이 믿고 실천하는 교리다. (중략)

우리가 가르치는 기법을 따른다면 깨끗하고 수준 높은 코드를 작성하리라 감히 장담한다.

 

- Clean Code 저자 Robert C. Martin -

 

---

 

 

강사가 생각하는 Clean Code란?

• 코딩 컨벤션
• 주석
• Naming
• 클래스/메소드 길이

 

 

 

2. Clean code가 필요한 이유

효율성 향상

누구나 보기에 편안한 코드 그리고 명확한 코드,

의도를 잘 드러내는 테스트 등은

더 이상 선택이 아니라 필수사항입니다.

 

 

 

3. Clean code를 학습하는 방법

 

직접 적용해보기

1. 내가 담당하는 프로젝트를 리팩토링해보기
2. 새로 만드는 코드를 Clean Code 룰에 맞춰 만들어보기
3. 프로젝트에 맞는 Clean Code 룰을 만들어보기

 

좋은 코드 읽어보기

1. 담당하고 있는 프로젝트에서 좋은 코드를 찾아보기
2. 오픈 소스로 제공하는 코드에서 좋은 코드를 찾아보기

 

 

 

 

Clean Code 책의 구성

클린코드의 정의

1장 깨끗한 코드

좁은 범위의 Clean Code (초급)

2장 의미있는 이름

3장 함수

4장 주석

5장 형식 맞추기

넓은 범위의 Clean Code (중급)

6장 객체와 자료구조

7장 오류 처리

8장 경계

9장 단위 테스트

10장 클래스

더 넓은 범위의 Clean Code (고급)

11장 시스템

12장 창발성

13장 동시성

14장 점진적인 개선

추가적인 Clean Code

15장 Junit 들여다보기

16장 SerialDate 리팩퍼링

17장 냄새와 휴리스틱

 

2장 의미있는 이름

• 의도를 분명히 밝혀라
• 그릇된 정보를 피하라
• 의미있게 구분하다
• 발음하기 쉬운 이름을 사용하라
• 검색하기 쉬운 이름을 사용하라
• 인코딩을 피하라
• 자신의 기억력을 자랑하지 마라
• 클래스 이름 - 명사
• 메서드 이름 - 동사
• 기발한 이름은 피하라
• 한 개념에 한 단어를 사용하라
• 말장난을 하지 마라
• 해법 영역에서 가져온 이름을 사용하라
• 문제 영역에서 가져온 이름을 사용하라
• 의미있는 맥락을 추가하라
• 불필요한 맥락을 없애라

 

 

3장 함수

• 작게 만들어라
• 한 가지만 해라
• 함수당 추상화 수준은 하나로
• Switch문의 사용법
• 서술적인 이름을 사용하라
• 함수 인수
• 부수 효과를 일으키지 마라
• 명령과 조회를 분리하라
• 오류 코드보다 예외를 사용하라
• 반복하지 마라
• 구조적 프로그래밍
• 함수를 어떻게 짜죠?

 

 

4장 주석

좋은 주석

• 법적인 주석
• 정보를 제공하는 주석
• 의도를 설명하는 주석
• 의미를 명료하게 밝히는 주석
• 결과를 경고하는 주석
• TODO 주석
• 중요성을 강조하는 주석
• 공개 API에서 Javadocs

 

 

5장 형식 맞추기

형식 맞추기

• 적절한 길이를 유지하라
• 가로 형식 맞추기
• 팀 규칙

수직거리

• 서로 밀접한 개념은 세로로 가까이 둬야 한다.
• 서로 밀접한 개념은 한 파일에 속해야 마땅하다.

 

 

6장 객체와 자료구조

• 자료 추상화
• 자료/객체 비대칭
• 디미터 법칙
• 자료 전달 객체

자료/객체 비대칭

• 절차적인 코드는 기존 자료 구조를 변견하지 않으면서 새 함수를 추가하기 쉽다.
• 반면 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.

디미터 법칙

• 클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다.

 

 

7장 오류 처리

• 오류 코드보다 예외를 사용하라
• Try-Catch-Finally문부터 작성하라
• 미확인(unchecked) 예외를 사용하라
• 예외에 의미를 제공하라
• 호출자를 고려해 예외 클래스를 정의하라
• 정상 흐름을 정의하라
• null을 반환하지 마라
• null을 전달하지 마라

미확인(unchecked) 예외를 사용하라

• 논쟁은 끝났다. 여러 해 동안 자바 프로그래머들은 확인된(checked) 예외의 장단점을 놓고 논쟁을 벌여왔다.
• 자바 첫 버전이 확인된 예외를 선보였던 당시는 확인된 예외가 멋진 아이디어로 여겨졌다. (중략)
• 하지만 확인된 예외는 OCP(Open Closed Principle)을 위반한다. (중략)
• 확인된 예외가 캡슐화를 깨버리는 현산은 참으로 유감스럽다.

null을 반환하지 마라

• null을 반환하는 습관은 나쁜 코드이다.
• null 확인은 누락되기도 쉽고, null 확인 코드가 너무 많아지는 것도 문제이다.

 

 

8장 경계

• 외부 코드 사용하기
• 경계 살피고 익히기
• log4j 익히기
• 학습 테스트는 공짜 이상이다
• 아직 존재하지 않는 코드를 사용하기
• 깨끗한 경계

학습 테스트는 공짜 이상이다

• 투자하는 노력보다 얻는 성과가 더 크다
• 패키지 새 버전이 나온다면 학습 테스트를 돌려 차이가 있는지 확인한다.

 

 

9장 단위 테스트

• TDD 법칙 세 가지
• 깨끗한 테스트 코드 유지하기
• 깨끗한 테스트 코드
• 테스트 당 assert 하나
• FIRST 원칙

TDD 법칙 세가지

• 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
• 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
• 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

TDD의 원칙 - FIRST

• Fast 빠르게
• Independent 독립적으로
• Repeatable 반복 가능하게
• Self-Validating 자가 검증하는
• Timly 적시에

 

 

10장 클래스

• 클래스 체계
• 클래스는 작아야 한다
• 변경하기 쉬운 클래스

 

 

11장 시스템

• 시스템 제작과 시스템 사용을 분리하라
• 확장
• 자바 프록시
• 순수 자바 AOP 프레임워크
• AspectJ 관점
• 테스트 주도 시스템 아키텍쳐 구축
• 의사 결정을 최적화하라
• 명백한 가치가 있을 때 표준을 현명하게 사용하라
• 시스템은 도메인 특화 언어가 필요하다

 

 

12장 창발성

창박적 설계로 깔끔한 코드를 구현하자

• 모든 테스트를 실행한다
• 중복을 없앤다
• 프로그래머 의도를 표현한다
• 클래스와 메서드 수를 최소로 줄인다

단순한 설계 규칙

• 모든 테스트를 실행하라
• 리팩터링

중복을 없애라

표현하라

클래스와 메서드 수를 최소로 줄여라

 

 

13장 동시성

동시성이 필요한 이유

동시성 방어 원칙

• 단일 책임 원칙 (SRP)
• 자료 범위를 제한하라
• 자료 사본을 사용하라
• 스레드는 가능한 독립적으로 구현하라

라이브러리를 이해하라

실행 모델을 이해하라

동기화하는 메서드 사이에 존재하는 의존성을 이해하라

동기화하는 부분을 작게 만들어라

올바른 종료 코드는 구현하기 어렵다

스레드 코드 테스트하기

• 말이 안되는 실패는 잠정적인 스레드 문제로 취급하라
• 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
• 다중 스레드를 쓰는 코드 부분을 다양한 환경이 쉽게 끼어 넣을 수 있게 스레드 코드를 구현하라
• 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라
• 프로레서 수보다 많은 스레드를 돌려보다
• 다른 플랫폼에서 돌려보라
• 코드에 보조 코드를 넣어 돌려라
• 강제로 실패를 일으키게 해보라
• 직접 구현하기
• 자동화