Clean Code - 1

밥 아저씨(Robert C. Martin)의 명저서이자 Clean 시리즈의 대표작인 Clean Code를 정리해 봅니다.

 

서론 (Clean Code가 필요한 이유)

밥 아저씨는 '깨끗한 코드란 무엇인가?'라는 질문에 대한 답을 내놓기 앞서 더러운(악취가 나는) 코드의 문제점을 통해 깨끗한 코드의 필요성에 대해 먼저 설명합니다. 

 

많은 개발자들은 오로지 당장의 구현에 집중해 코드를 짜곤 합니다. 이러한 방식은 코드를 짜는 데 있어 큰 고민을 필요로 하지 않기 때문에 당장의 생산성을 끌어올리는 데에는 좋을지 모르지만 새로운 기능들이 추가되고, 프로젝트의 복잡도가 증가할수록 단순한 수정에도 많은 노력이 필요하게 되면서 생산성 저하로 이어지게 됩니다.

 

Clean Code에는 코드를 깨끗하게 유지하기 위한 수 많은 규칙들을 이야기합니다. 규칙들이 너무나 많기 때문에 이 규칙들을 모두 지키긴 어렵다는 게 제 개인적인 생각입니다. 모든 규칙을 지키기 위해 애쓰는 행위 자체가 상당한 생산성 저하를 가져올 수 있기 때문이지요. 저자인 밥 아저씨 또한 본인이 모든 규칙을 지키고 있진 못하며, 규칙마다 논쟁의 여지가 있을 수 있음을 책을 통해 이야기하고 있습니다.

따라서 이 글은 제가 개인적으로 중요하게 생각하는 규칙들에 대한 정리입니다.

 

 

 

의미 있는 코드

밥 아저씨는 모든 코드가 의미를 담고 있거나, 의도를 들어내고 있어야 한다고 강조합니다. 각 클래스명, 함수명, 변수명은 모두 그 의도와역할을 명확하게 드러내고 있어야 하며 로직 또한 그 의미가 분명히 드러나 있어야 합니다.

 

// 의도가 분명하지 않은 이름들과 매직넘버
public List<int[]> getThem() {
    List<int[]> list1 = new ArrayList<>();
    for (int[] x: theList) 
    	if (x[0] == 4) list.add(x);
    return list1;
}


// 각 함수, 변수명에 그 의도를 들어내고 있고,
// 4 또한 constant를 통해 그 의미를 나타내고 있다
public List<int[]> getFlaggedCells() {
    List<int[]> flaggedCells = new ArrayList<>();
    for (int[] cell: gameBoard) 
    	if (cell[STATUS_VALUE] == FLAGGED) flaggedCells.add(cell);
    return flaggedCells;
}

두 함수는 동일한 기능을 수행하고 있습니다. 하지만 함수 역할은 getFlaggedCells()가 훨씬 명확하게 들어나 있고, 이 코드를 읽는 개발자 또한 훨씬 빠르게 의미를 파악할 수 있을 것입니다.

 

클래스 이름엔 명사나 명사구, 함수 이름엔 동사나 동사구가 적절합니다. 다른 사람이 보았을 때 쉽게 파악할 수 있는 단어들을 사용하되 한 개념에 대해선 한 단어로 통일되게 나타내어야 합니다. 심지어 밥 아저씨는 공백에도 의미가 있어야 한다고 이야기합니다.

 

 

함수

작게, 한 가지 만을 제대로 하도록 만들어야 한다

함수들은 최대한 작은 단위로 나누어야 합니다. 중첩 구조가 생기지 않을 만큼, 동일한 의미로 묶을 수 있는 최소한의 단위들로 함수를 만들어야 합니다. 밥 아저씨는 이상적인 함수의 크기로 4줄 정도를 이야기하고 있으며, 이렇게 됐을 때 한 함수가 정확하게 하나의 이야기 만을 할 수 있었다고 이야기합니다.

 

이렇게 작게 나누는 것의 장점은 단순히 중복을 피하는 데에만 있지 않습니다. 함수는 각 코드 블록을 네이밍 해주는 효과도 가지고 있어 의미 파악이 쉬워지며, 함수가 작아질수록 unit test가 쉬워집니다.

 

서술적인 이름을 사용하라

조금은 장황하게 보이더라도 서술적인 이름으로 함수의 역할을 명확하게 들어내는 게 좋습니다.

 

파라미터를 최소화하라

함수의 파라미터가 많아지게 되면 개발자는 그 함수를 파악하기 어려워집니다. 또한 파라미터가 많은 함수는 testable하지 못합니다. 함수가 많아질수록 각 파라미터와 조합에 대한 테스트가 추가로 필요하게 될 것입니다.

가능한 한 작은 단위의 여러 함수로 나누는 것이 좋고, flag 인자는 특히나 그러합니다.

 

Side effect를 피하라

함수 내부에서 일어나고 있는 side effect에 대해 알지 못한 상황에서 함수를 사용하게 된다면 이는 큰 문제로 이어질 수 있습니다. 또한 출력 인수 사용을 피하라고 이야기합니다. 함수에서 상태를 변경해야 한다면 함수가 속한 객체의 상태를 변경하는 방향이 좋습니다.

 

책에서는 언급하고 있지 않지만 side effect를 피하고 함수를 순수 함수로 유지하는 것은 testabillity를 높이고자 하는 측면에서도 큰 도움이 됩니다.

 

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

위의 '의미 있는 코드'의 내용과 비슷합니다.