냄새와 휴리스틱(1)

환경, 함수에 관한 휴리스틱

책너두 5기 40일차

로버트 C. 마틴의 클린코드 p. 370~ p.378

내용정리

17. 냄새와 휴리스틱

환경

1. 여러 단계로 빌드해야 함

빌드는 간단히 한 단계로 끝나야 한다. 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다.

2 . 여러 단계로 테스트해야 함

모든 단위 테스트는 한 명령으로 돌려야 한다.

함수

1. 너무 많은 인수

함수에서 인수 개수는 적을수록 좋고 아예 없으면 가장 좋다.

2. 출력 인수

인수는 출력보단 입력으로 간주할 수 있어야 한다.

3. 플래그 인수

boolean 인수는 함수가 여러 기능을 수행한다는 증거이다.

4. 죽은 함수

아무도 호출하지 않는 함수는 삭제한다.

일반

1. 한 소스 파일에 여러 언어를 사용

좋게 말하자면 혼란스럽고, 나쁘게 말하자면 조잡하다.

2. 당연한 동작을 구현하지 않는다.

최소 놀람의 원칙(The Principle of Least Surprise)에 의거해 다른 프로그래머가 당연하게 여길 것은 제공해야 한다.

3. 경계를 올바로 처리하지 않는다.

모든 경계 조건을 찾아내고, 모든 경계 조건을 테스트하는 테스트 케이스를 작성하라.

4. 안전 절차 무시

실패하는 테스트 케이스를 나중으로 미루는 태도는 위험하다.

5. 중복

가장 중요한 규칙이다. ‘단 한 번만’은 가장 우선시되야한다. 중복이 발견되면 추상화할 기회로 간주하라. 어디서든 중복을 발견하면 없애라

6. 추상화 수준이 올바르지 못하다

모든 저차원 개념은 파생 클래스에 넣고, 모든 고차원 개념은 기초 클래스에 넣는다. 고차원 개념과 저차원 개념을 섞어서는 안된다.

7. 기초 클래스가 파생 클래스에 의존한다.

기초 클래스와 파생 클래스로 나누는 이유는 고차원 기초 클래스 개념을 저차원 파생 클래스 개념으로부터 분리해 독립성을 보장하기 위해서다. 그러므로 기초 클래스가 파생 클래스를 사용한다면 문제가 있는 것이다. FSM(Finite State Machine)의 예외는 가끔 있긴 하다.

8. 과도한 정보

잘 정의된 모듈은 인터페이스가 작지만 많은 동작이 가능하며 많은 함수를 제공하지 않아 결합도(coupling)가 낮다. 자료, 유틸리티 함수, 상수와 임시 변수를 숨기고 메서드나 인스턴스 변수가 넘쳐나는 클래스는 피하라. 인터페이스를 매우 작게 그릭 ㅗ매우 깐깐하게 만들어라. 정보를 제한해 결합도를 낮춰라.

9. 죽은 코드

실행되지 않은 코드를 의미한다. 제거하라.

10. 수직 분리

변수와 함수는 사용되는 위치에 가깝게 정의한다. 비공개 함수는 처음으로 호출한 직후에 정의한다.

11. 일관성 부족

어떤 개념을 특정 방식으로 구현했다면 유사한 개념도 같은 방식으로 구현한다. ‘최소 놀람의 원칙(The Principle of Least Surprise)’에도 부합한다.

12. 잡동사니

비어 있는 기본 생성자, 아무도 사용하지 않는 변수, 아무도 호출하지 않는 함수, 정보를 제공하기 못하는 주석 등은 없애라.

13. 인위적 결합

서로 무관한 개념을 인위적으로 결합하지 마라. 직접적인 상호작용이 없는 두 모듈에서 일반적으로 일어난다. 뚜렷한 목적 없이 변수, 상수, 함수를 당장 편한 위치(잘못된 위치)에 넣은 결과이다.

14. 기능 욕심

클래스 메서드는 남의 것 말고 자기 클래스의 변수와 함수에 관심을 가져야 한다. 메서드가 다른 객체의 참조자(accessor)와 변경자(mutator)를 사용해 객체 내용을 조작한다면 메서드가 그 객체 클래스의 범위를 욕심내는 탓이다.


읽고 나서

오늘도 코드를 짤떄 주의해야 할 것, 안좋은 방향의 냄새에 관한 이야기다. 머리에 심어두자.