읽기일기

Clean Code, 클린코드 (20140908, 마지막)


Clean Code 클린 코드, 로버트 C. 마틴 지음, 박재호.이해영 옮김/케이앤피북스

바쁘다는 핑계로 먼지가 뽀얗게 앉은 책을 꺼내 다시 처음부터 보았다. 대체로 알찬 내용이긴 하지만 약간 Java에 종속적인 부분이 있어 잘 적응하지 못했나보다. 주로 C++를 다루는 나에게는 곧바로 적용하기에 힘든 부분이었는지도 모른다. C#, Java 정도가 되어야 책에 나온 그대로 세련되게 적용할 수 있을 것만 같다. 끝까지 읽어본 결과 대략 20 ~ 30% 정도의 내용은 C#, Java 사용자가 와닿을만한 내용인 듯 하다. 덧붙여 그 성격 상 소스코드의 양이 좀 되나 아주 편하게 볼 수 있는 편집은 아니었던 것 같다. 줄 간격을 조금 더 주었으면 어땠을까?

내용은 물론, 튜토리얼 형식으로 실제로 리팩토링을 진행하는 내용도 담고 있어 책은 훌륭한 편인데, 그 내용들이 모두  17. 냄새과 발견법에 요약되어있다. 그 내용을 간단히 정리해둔다.


1. 주석

대체로 주석은 꼭 필요한 것이 없으면 삭제하라는 것이 일관적인 주장이다.

C1. 부적절한 정보 : 소스코드에 대한 내용 외의 다른 시스템에 맡길 수 있는 정보는 주석에서 제거
C2. 쓸모없는 주석 : 삭제
C3. 중복된 주석 : 소스코드 자체로도 설명되는 주석은 삭제
C4. 성의 없는 주석 : 삭제
C5. 주석 처리된 코드 : 소스 관리 시스템이 흔적을 남기므로 삭제

2. 환경

E1. 빌드에 여러 단계가 걸린다 : 체크아웃 후 바로 빌드가 가능해야 함
E2. 테스트에 여러 단계가 걸린다 : 한 명령으로 모든 테스트 가능해야 테스트를 꺼리게 되지 않음

3. 함수

F1. 너무 많은 인수 : 인수는 작을 수록 좋다. 많아도 2개를 넘기지 않길
F2. 출력 인수 : 출력 인수는 알아보기 힘들다. 차라리 객체 상태를 변경할 것
F3. 플래그 인수 : 플래그 인수 또한 알아보기 힘드며, 함수가 여러 기능을 한다는 뜻이므로 과감히 그 둘을 따로 분리
F4. 죽은 함수 : 호출하지 않는 함수는 삭제

4. 일반

G1. 한 소스에 여러 언어를 사용한다 : 주석에 HTML등을 사용하면 가독성이 좋지 않음
G2. 당연한 동작을 구현하지 않는다 : 함수는 다른 프로그래머가 당연하게 여길만한 동작과 기능을 제공해야 함 (신뢰성)
G3. 경계를 올바로 처리하지 않는다 : 데이터의 허용 경계를 말함
G4. 안전 절차 무시 : 크리티컬한 변수를 직접 제어하거나, 컴파일러 경고를 꺼두거나, 실패하는 테스트를 미뤄두지 말 것
G5. 중복 : 최근 15년 동안 나온 디자인 패턴은 대다수가 중복 제거하는 방법. 중복된 코드는 기회임.
G6. 추상화 수준이 올바르지 못하다
G7. 기본 클래스가 파생 클리스에 의존한다 : 파생클래스 그 의도 자체를 거스르는 상태
G8. 과도한 정보 : 외부로 노출된 인터페이스를 제한하여 결합도를 낮추자.
G9. 죽은 코드 : 실행되지 않는 코드는 삭제
G10. 수평 분리 : 변수나 함수는 사용되는 위치 가까이에서 정의
G11. 일관성 부족 : 함수 이름이나 변수 명 등에서 일관성을 유지하자.
G12. 잡동사니 : 사용하지 않는 변수, 함수, 쓸데없는 주석은 삭제
G13. 인위적 결합 : 서로 무관한 개념을 인위적으로 결합하지 않는다. static, enum은 특정 클래스에 속할 필요가 없음
G14. 기능 욕심 : 클래스가 다른 클래스 변수와 함수에 관심을 가져서는 안됨
G15. 선택기 인수 : 인자로 플래그나 enum, int로 함수 동작을 제어하지 않도록
G16. 애매한 의도 : 행을 바꾸지 않고 표현한 수식, 헝가리식 표기법, 매직 넘버는 알아보기 힘드니 수정
G17. 잘못 지운 책임
G18. 부적절한 static 함수
G19. 서술적 변수 : 변수 이름을 서술적(descriptive)으로
G20. 이름과 기능이 일치하는 함수
G21. 알고리즘을 이해하라
G22. 논리적 의존성은 물리적으로 드러내라
G23. If/Else 혹은 Switch/Case 문보다 다형성을 사용하라
G24. 표준 표기법을 따르라 : 팀 표준 표기법
G25. 매직 숫자는 명명된 상수로 교체하라
G26. 정확하라 : 코드에서 뭔가를 결정할 때는 모든 상황을 고려하여 정확히 결정
G27. 관례보다 구조를 사용하라 : 설계 결정을 강제할 때는, 관례보다 구조 자체로 강제하면 좋다.
G28. 조건을 캡슐화하라 : 조건의 의도를 분명히 밝히는 함수로 표현
G29. 부정 조건을 피하라 : 긍정 조건이 이해하기가 더 쉬움
G30. 함수는 한 가지만 해야한다
G31. 숨겨진 시간적인 결합 : 서로 독립된 함수지만 순서대로 실행해야 할 경우 제약을 두지 않으면 순서를 잘못 호출할 위험이 있음. 인수 등을 종속적으로 사용하도록 하여 제약을 두도록 한다.
G32. 일관성을 유지하라 : 구조적 일관성
G33. 경계 조건을 캡슐화 하라
G34. 함수는 추상화 수준 한 단계만 내려가야 한다 : 함수의 추상화가 뒤섞이지 않도록
G35. 구성 정보는 최상위 단계에 두어라 : 상수를 저차원 함수에 숨기지 말고 고차원에 두어야 저차원 함수를 뒤적이지 않게 됨
G36. 추이적 탐색을 피하라 : 모듈은 주변 모듈을 모를 수록 좋음

5. 자바

J1. 긴 import 목록을 피하고 와일드카드를 사용하라
J2. 상수는 상속하지 않는다
J3. 상수 대 Enum : public static final int 대신 Enum을 사용할 것.

6. 이름

N1. 서술적인 이름을 사용하라
N2. 적절한 추상화 수준에서 이름을 선택하라
N3. 가능하다면 표준 명명법을 사용하라
N4. 명확한 이름
N5. 긴 범위는 긴 이름을 사용하라
N6. 인코딩을 피하라 : 접두어는 대부분 불필요
N7. 이름으로 부수 효과를 설명하라 : 함수가 하는 모든 기능을 서술할 것

7. 테스트

T1. 불충분한 테스트 : 잠재적인 모든 부분 테스트
T2. 커버리지 도구를 사용하라
T3. 사소한 테스트를 건너뛰지 마라
T4. 무시한 테스트는 모호함을 뜻한다
T5. 경계 조건을 테스트하라
T6. 버그 주변은 철저하게 테스트하라
T7. 실패 패턴을 살펴라
T8. 테스트 커버리지 패턴을 살펴라
T9. 테스트는 빨라야 한다

 


Add a Comment Trackback