[Clean Code] 2. 의미 있는 이름

도서, [Clean Code]를 읽고 정리한 글입니다 . ..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................

본 게시글은 도서, Clean Code를 읽고 정리한 글입니다.

Clean Code(클린 코드) | 로버트 C. 마틴 - 교보문고

0. 서론

Clean Code를 읽고, 최근에 진행한 프로젝트에 적용해보려 합니다. 

 

각 내용과 관련된 코드 내용은 프로젝트에서 고친 부분이 있다면, 그 부분을 예시로 들고
그렇지 않다면 다른 예시를 사용할 예정입니다.

 

 

1. 의도를 분명히 밝혀라

좋은 이름을 지으려면 시간이 걸리기 마련이지만, 좋은 이름으로 인해 절약하는 시간이 더 많다.

 

그러므로 이름을 주의 깊게 짓고, 더 나은 이름이 떠오른다면, 고쳐라.

 

지은 이름과 관련된 주석을 달아야 한다면, 이름의 의도를 분명하게 나타내지 못했다는 뜻이다.

 

의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.

 

for (MemberNPC memberNPC : npcList) {
    
    // ... 이전 코드 내용
    
    List<Talk> talkList = talkRepository.findTalkList(memberNPC.getId());

    int count = 0;

    for (Talk talk : talkList) {
        if (!talk.getTalkDetailList().isEmpty())
            count++;
    }

    if(count == 0)
        continue;

    // ... 이후 코드 내용
}

 

위 부분은 프로젝트에서 talk 객체가 talkDetail이라는 객체 리스트를 가지고 있을 때 그 횟수를 세는 로직이다.

 

내 프로젝트 속 위 내용에서 `count`는 무언가를 세는 것은 알겠지만, 그래서 어떤 것을 세어야 하는지 잘 모르겠다. 

(물론 그 외에도 !와 .isEmpty()를 다른 방식으로 쓰는 방향으로 리팩토링 할 수 있겠지만, 우선 해당 챕터에 어울리는 내용만 수정하겠다.)

 

따라서 아래와 같이, 의미가 드러나도록 count 변수를 수정한다.

 

for (MemberNPC memberNPC : npcList) {
    
    // ... 이전 코드 내용
    
    List<Talk> talkList = talkRepository.findTalkList(memberNPC.getId());

    int talkDetailListCount = 0;

    for (Talk talk : talkList) {
        if (!talk.getTalkDetailList().isEmpty())
            count++;
    }

    if(talkDetailListCount == 0)
        continue;

    // ... 이후 코드 내용
}

 

 

2. 그릇된 정보를 피하라

코드의 의미를 흐리는, 그릇된 단서를 남겨서는 안된다.

 

널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해서도 안된다.

 

예를 들어, hp라는 이름은 직각 삼각형의 빗변 (hypotenuse)의 줄임말로서 이름의 기능을 수행할 수 있지만, 

 

Unix 플랫폼이나, Unix 변종을 가리키는 의미로 통상적으로 사용되기 때문에 이는 좋은 이름이라고 보기 어렵다.

(비슷한 의미로, MySQL을 사용할 때 해당 DataBase에서 예약어로서 사용하는 단어들을 Table 이름으로 정했다가 낭패를 보는 경우가 있다.)

 

 

 

또한, 당연하게 느껴질 수도 있겠지만 단일 개수의 어떤 것을 가지고 있지만 List라는 이름을 붙이는 것은 당연히 좋지 않다.

 

 

 

서로 흡사한 이름을 사용하지 않도록 하자. 특히 이 문제는 이름이 길어질수록 두드러진다. 남들이 보면 못 구분한다.

 

 

 

소문자 L, 대문자 O와 같이 다른 문자와 헷갈릴 수 있는 이름은 끔찍하다.

 

 

3. 의미 있게 구분하라

동일 범위 내에서 다른 여러 개념에 같은 이름을 사용하면 안된다. 이는 나중에 이름을 바꾸게 될 때, 잘 못 건들 확률이 매우 높다.

 

연속적인 숫자를 덧붙인 이름은 삼가해야 한다.

이런 이름은 저자의 의도가 전혀 드러나지 않는, 나열한 알아볼 수 없는 이름들 중 하나가 될 뿐이다.

 

또한 불용어를 사용하면 좋지 않다. 불용어란, 개념은 잘 구분되지 않는데 이름만 달라지는 경우다.

대표적인 예시로 Info와 Data. 그리고 a, an, The.

variable, String, table, Object, amount 와 같은 것들은 아무 의미가 없다,

 

getNPC();
getNPCInfo();
getNPCData();

 

 

위 예시를 보면, 만약 NPC의 정보를 가져오는 부분에서 에러가 났다고 하자. 그런데, 어디 메서드가 정확하게 문제인지 다른 사람이 찾을 수 있겠는가?

 

 

4. 발음하기 쉬운 이름을 사용하라.

이는 협업에서 더욱 두드러진다. 

회의를 한다 치는데, 요상한 발음의 이름이라면...

 

프로그래밍은 사회 활동이다!

 

말하면서도 바로 의미를 찾을 수 있는 그런 이름을 찾아보자.

 

 

5. 검색하기 쉬운 이름을 사용하라

IDE에서 Ctrl + F로 찾든, Linux 환경에서 grep으로 찾든, 프로젝트가 대규모가 될 수록 검색 기능을 활용할 일이 많아지기 마련이다. 

 

이 때 원하는 값을 찾기 위해 검색을 했는데 결과가 아래와 같다면 ...

IntelliJ Ctrl + F

 

146개를 찾아볼 시간은 dto의 이름을 다른 것으로 생각해서 짜는 것에 비해 훨씬 방대할 것이다.

 

일반적으로 의미있게 이름을 짓게 될 수록 길이가 길어지는 경향이 있다. 

이 저자는 이름의 길이가 길어지는 것이 좋다고 생각한다.

나는 너무 긴 것도 가독성의 문제, 읽기 어렵다는 문제가 있을 수 있다고 생각한다. 

역시 밸런스를 찾는 것이 가장 어려우면서도 중요하다고 볼 수 있다.

 

 

6. 인코딩을 피하라

마치 `헝가리식 표기법` 같은 것으로 변환해서 표기한다면..?

물론 난 저게 뭔지도 모르지만 생각만해도 아찔하다.

 

멤버 변수 접두어

위는 옛날 개념이다.

 

인터페이스 클래스와 구현 클래스

옛날에는 인터페이스의 이름에 접두어를 붙였지만, 저자는 차라리 구현 클래스에 Imp와 같은 접미사를 붙이는 것을 추천한다. 내가 다루는 클래스가 인터페이스라는 사실을 남에게 알리고 싶지 않기 때문이다.

 

나는 개인적으로 구현 클래스의 끝에 Impl을 붙이는 방식을 더 선호한다.

 

 

7. 자신의 기억력을 자랑하지 마라

독자가 코드를 읽으면서 변수 이름을 자신의 방식대로 변환해야 하는 이름이라면 당연히 바람직하지 못하다.

 

Loop의 i, j, k와 같은 변수는 프로그래밍 관습으로, 이는 괜찮다. 다른 개발자들도 당연히 알아볼 것이니까.

다만, 위 경우다 루프의 범위가 클 때는 곤란하다. 헷갈림을 유도한다.

 

명료함, 이는 프로그래머의 능력이다. 이 능력이 좋은 고수는 남들이 이해하기 쉬운 코드를 만든다.

 

 

8. 기발한 이름은 피하라

기발한 이름은 어디까지나, 개발한 사람의 기발함이다. 자신의 기발함을 남에게 대입하지 마라. 그들은 이해하지 못할 확률이 높고, 그렇다고 그들이 잘 못 된것도 아니다. 

 

 

9. 한 개념에 한 단어를 사용하라

정보를 가져오는 개념의 단어에 fetch / get / retrieve 다양하게 있는데, 이를 혼용하는 경우가 있다.

혼란을 불러온다.

 

최근 IDE는 자동 완성 기능을 통해 훌륭한 이름 예시들을 추천해 주므로, 본인이 상황에 맞게 혼용하지 않도록 잘 고르면 되겠다.

 

 

10. 말장난을 하지 마라

여기선 말장난이란 표현을 써서 이해하기 어렵다. 

그냥 단순하게 말 하면, 다른 개념에 한 단어를 사용하지 말라는 것이다. 위 9번 예시를 보고, 무방비하게 같은 단어를 다른 개념일때도 사용하는 경우가 있는데, 이렇게 하지 말자는 것.

 

일관성도 다른 맥락에서는 말장난일 뿐이다.

 

 

11. 해법 영역에서 가져온 이름을 사용하라

코드를 읽는 사람 또한 개발자기에, 알고리즘 이론 / 전산 용어 / 패턴 이름 / 수학 용어를 사용해도 좋다는 뜻이다.

 

 

12. 문제 영역에서 가져온 이름을 사용하라

사실 이는 위 11번과 상충된다. 적절한 프로그래밍 용어가 없다는 전제 하에 이렇게 하라고 저자는 말한다.

 

솔직히 아직 개발 지망생인 나로서는 조금은 이해가 어려운 부분이다.

무조건적인 프로그래밍 용어의 사용이 진정으로 다른 개발자의 이해를 돕는가.

잘 모르겠다. 경험이 쌓이다 보면 서서히 이해가 될까?

 

 

13. 의미 있는 맥락을 추가하라

스스로 맥락을 의미 있는 맥락을 가지는 용어 / 이름들이 많지는 않기에, 의미 있는 맥락을 적절히 추가하는 것은 좋은 이름에 도움이 된다는 뜻이다.

 

예를 들어, 

name, weight, legCount, crySound 등이 있다면 동물로 유추할 수는 있다. 하지만 때로는 유추하기 어렵다고 느낄 수도 있다. (물론 이는 잘못된 것이 아니다. 사람마다 다르다.)

 

이런 경우에 animal 이라는 의미 있는 맥락을 추가한다면, 이해하기 더욱 쉬워질 것이다.

animalName, animalWeight, animalLegCount, animalCrySound ...

 

 

14. 불필요한 맥락을 없애라

'선상 파티'( A Shipboard Party ) 라는 애플리케이션을 짠다 치면 모든 이름 앞에 ASP를 붙이는 것은 바람직하지 못하다.