메서드나 변수의 이름(그리고 타입, 주석)이 약속하는 것과 실제 동작이 맞지 않는 상태다. 베네라 아르나우도바(Venera Arnaoudova) 등이 정리한 개념으로, 『프로그래머의 뇌』는 이것이 특히 인지 부하를 크게 높인다고 설명한다.
예
// get인데 상태를 바꾼다
function getUser(id: string) {
cache.clear();
return db.find(id);
}
// is로 시작하지만 boolean이 아니다
const isValid = validate(form); // { ok: boolean, errors: string[] }
// 복수형 이름인데 하나만 담는다
const users = findFirstUser();왜 해로운가
이름을 읽는 순간 뇌는 장기 기억에서 "get은 읽기만 한다", "is는 참/거짓이다" 같은 지식을 꺼내 코드를 덩어리로 묶는다(청킹과 코드 읽기). 그 지식이 틀리면 잘못된 덩어리로 이해하고, 나중에 실제 동작을 확인하느라 더 많은 부담을 진다(인지 부하). 이름이 나쁜 코드에서 버그가 더 많이 발견된다는 연구도 있다(인과관계까지 밝혀진 것은 아니다).
이름에서 예상한 대로 동작하라는 최소 놀람의 원칙, 조회와 변경을 나누라는 명령-질의 분리이 같은 문제를 다른 쪽에서 다룬다.
좋은 이름을 만드는 3단계
드로르 페이텔슨(Dror Feitelson)이 제안한 방법이다.
- 이름에 담을 개념을 고른다 (무엇을 나타내는가)
- 각 개념에 쓸 단어를 고른다 (팀과 도메인이 쓰는 말로)
- 단어를 조합하는 틀을 정한다 (코드베이스 안에서 일관되게)
이름을 바꾸는 것만으로도 좋은 리팩터링이다 → 함수 선언 바꾸기. 코드 어휘를 도메인 어휘와 맞추는 습관은 상호 참조 전략와 이어진다.
출처: 『프로그래머의 뇌』 펠리너 헤르만스 (원서 The Programmer's Brain)