클린코드 책을 읽고서 Chapter. 냄새와 휴리스틱

본 포스팅은 개인 정리 목적으로 작성된 글입니다.

잘못된 정보가 있을 수 있으며, 피드백은 겸허히 받겠습니다.

 

 

해당 챕터를 읽고 내용을 정리해봤다.

챕터자체 내용이 너무 많아 모든 내용을 포함하지는 않았다.

 

주석

C1: 부적절한 정보

다른 시스템에 저장할 정보는 주석으로 적절하지 못하다.

예를 들면 변경이력과 같은 장황한 날짜와 내용이 그렇다. 일반적으로 작성자, 최종 수정일 등 메타 정보만 넣는다.

 

C2: 쓸모 없는 주석

오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 쓸모가 없다. 쓸모 없어진 주석은 바로 삭제를 하자.

 

C3: 중복된 주석

소스코드만으로 충분히 파악이 가능한 내용을 주석을 통해 설명하는 것을 피하자.

예시로 아래와 같은 경우를 볼 수 있다.

또한 함수 주석의 경우 파라미터와 같은 정보만 주석에 설명하는 경우는 피한다.

C4: 성의 없는 주석

주석을 작성한다면 시간을 들여 단어선택 및 문법과 구두점을 올바로 사용한다. 즉 간결하고 명료해야 한다.

 

C5: 주석 처리된 코드

주석으로 처리된 코드는 바로 지우도록 하자.

 

환경

E1: 여러 단계로 빌드해야 한다.

빌드는 간단히 한 단계로 끝내야 한다. 이것저것 따로 체크해야 할 필요가 없어야 한다.

 

E2: 여러 단계로 테스트 해야 한다.

모든 단위테스트를 한 명령으로 돌려야 한다. IDE에서 버튼 하나로 모든 테스트가 가능하다면 가장 이상적이다.

 

함수

F1: 너무 많은 인수

함수에서 인수 개수는 작을수록 좋다. 아예 없는것이 가장 좋다.

 

F2: 출력 인수

일반적으로 인수는 입력으로 간주된다.

함수에서 뭔가의 상태를 변경해야 한다면 함수가 속한 객체의 상태를 변경해야 한다.

 

F3: 플래그 인수

boolean 인수는 함수가 여러 기능을 수행한다는 의미를 내포하고 있다. 최대한 지양하자

F4: 죽은 함수

아무도 호출하지 않는 함수는 바로 삭제한다. 소스 코드 관리 시스템이 모두 기억하고 있으니 걱정할 필요 없다.

 

일반

G1: 한 소스 파일에 여러 언어를 사용한다.

오늘날 프로그래밍 환경은 한 소스 파일 내에서 다양한 언어를 지원한다.

이상적으로 소스 파일 하나에 언어 하나만 사용하는 방식이 바람직 하다.

 

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

최소 놀람의 원칙에 의해 함수나 클래스는 다른 프로그래머가 당연하게 여길한만 동작과 기능을 제공해야 한다.

최소 놀람의 원칙이란?

코드가 읽는 이를 놀라게 해서는 안된다. 표준 코딩 컨벤션을 따르고, 주석과 명명이 의미 전달을 잘 해야하며, 잠재적으로 놀래킬 수 있는 부작용을 최소화 하라

 

이 부분에선 극단적으로 예를 한번 들어봤다. 아래 함수는 이름만 봐도 문자열의 길이를 리턴하는 함수라고 생각할 수 있을것이다.

하지만 함수의 내용을 보면 그렇지 않다.

문자열에 존재하는 띄어쓰기는 모두 붙여버리고, 문자열에 "-" 이 포함될 경우 공백으로 처리해 버려 실제 원하는 값과 다르게 나오게 된다.

즉, 함수이름처럼 문자열의 길이를 리턴한다고 당연히? 명시가 되어있다면 예상하는 대로 동작이 되야 한다.

 

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

흔히 개발자들은 머릿속에서 코드를 돌려보고 끝낸다. 자신의 직관에 의존할 뿐 해당코드를 증명하려 애쓰지 않는다.모든 조건을 테스트하는 테스트 케이스를 작성하라

 

G4: 안전 절차 무시

흔히 개발을 하다보면 소스 코드에 워딩을 보는 경우가 있을것이다.

일종의 경고 및 권고사항인데, 이러한 메시지를 무시하지 말아야 한다.

 

G5: 중복

중복은 최소화 해야 한다.

코드에서 중복을 발견할 때 마다 추상화할 기회로 간주하라, 중복된 코드는 하위 루틴이나 다른 클래스로 분리하라

 

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

추상화로 개념을 분리할 때는 철저해야 한다.

모든 저차원 개념은 파생 클래스에 넣고, 고차원 개념은 기초 클래스에 넣는다.

예를들어 세부 구현과 관련한 상수,변수,함수 는 기초 클래스에 넣으면 안된다. 

기초 클래스는 구현 정보에 무지해야 마땅하다.

 

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

기초 클래스는 파생 클래스를 아예 몰라야 마땅하다.

 

 * G6 와 G7을 간단하게 소스코드로 살펴보자. (아래 예제는 안드로이드 입니다.)

BaseActivity 라 명명 지은 해당 클래스는 모든 Activity 가 참조하는 기초 클래스가 됩니다.

해당 클래스는 모든 Activity에서 기본적으로 설정이 되야 하는 의존성 주입 및 레이아웃 세팅이 이루어져 있습니다.

 

LoginActivity 는 BaseActivity를 상속하는 파생 클래스 입니다.

실제 구현에 필요한 저차원의 데이터를 세팅하고 작업이 이루어 집니다.

또한 BaseActivity 는 LoginActivity 에 대해 아무런 정보도 알지 못합니다.( 의존하지 않는다 )

 

G8: 과도한 정보

잘 정의된 모듈은 인터페이스가 아주 작다. 중요한건 작은 인터페이스로도 많은 동작이 가능하다.

잘 정의된 인터페이스는 많은 함수를 제공하지 않는다.

 

G9: 죽은 코드

죽은 코드란 실행되지 않는 코드를 가리킨다. 과감히 제거하자.

 

G10: 수직 분리

변수와 함수는 사용되는 위치에 가깝게 정의한다.

지역변수는 처음으로 사용하기 직전에 선언하며, 수직으로 가까운 곳에 배치해야 한다.

선언한 위치로부터 몇 백줄 아래에서 사용하면 안 된다.

 

G11: 일관성 부족

어떠한 기능을 특정 방식으로 구현했다면, 유사한 기능도 같은 방식으로 구현한다.

어떠한 변수이름을 특정하게 지정하였다면 , 유사한 변수이름도 같은 방식으로 구현한다.

일관성을 통일화 시켜 코드를 읽고 수정하기 편하도록 만들어야 한다.

 

G12: 잡동사니

비어있는 기본생성자는 필요가 없다. 또한 아무도 사용하지 않는 변수, 함수, 정보제공이 원할하지 않는 주석도 이에 해당한다.

모두 제거하라

 

 

G13: 인위적 결합

서로 무관한 개념을 인위적으로 결합하지 않는다. 예를 들어 일반적인 enum이나 static 함수는 특정 클래스에 속할 이유가 없다.

시간을 들여 올바른 위치에 선언하는 것을 고민해야 한다.

 

G14: 기능욕심

클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야 한다.

다른 클래스의 변수와 함수에 관심을 가져서는 안된다.

메서드가 다른 객체를 참조하여 그 객체의 내용을 조작한다면 객체 클래스의 범위를 욕심 내는 것이다.

 

G19: 서술적 변수

프로그램 가독성을 높이는 가장 효과적인 방법 중 하나다.

아래 간단한 예시를 보자.

서술적 변수를 사용하여 key 와 value를 선언하여 구분짓는다.

서술적 변수를 사용하지 않는 코드보다 가독성이 높아진다.

 

G28: 조건을 캡슐화하라

조건의 의도를 분명히 밝히는 함수로 표현하라

G29: 부정 조건은 피하라

부정 조건은 긍정조건보다 이해하기 어렵다. 가능하면 긍정 조건으로 표현한다.