54 lines
2.6 KiB
Markdown
54 lines
2.6 KiB
Markdown
---
|
|
id: 코드의 가독성 20260317
|
|
created: 2026-03-17 17:19
|
|
tags:
|
|
aliases:
|
|
---
|
|
## 💡 생각
|
|
글로 읽을 땐 무슨 말인지 어렴풋이 짐작이 되지만 실제로 해보면 가독성이 좋은 코드를 만드는 건 어렵다.
|
|
|
|
문장처럼 읽히는 코드와 인지 부하의 최소화는 함수형 프로그래밍이 좋은 대응책인 것 같고,
|
|
|
|
|
|
---
|
|
## 📑 개념
|
|
**가독성이 높은 코드**는 단순히 "예쁜 코드"를 넘어 **코드를 읽는 사람의 뇌가 에너지를 최소한으로 쓰게 만드는 코드**를 의미합니다.
|
|
|
|
## 📌 가독성이 좋은 코드의 기준
|
|
### 1. 문장처럼 읽히는 코드 (의도 노출)
|
|
|
|
코드를 봤을 때 "어떻게(How)" 작동하는지 분석하기 전에, "무엇을(What)" 하려는지 바로 이해되어야 합니다.
|
|
|
|
- **나쁜 예:** `if (user.Status == 1 && user.Age > 19 && user.HasPaid)` (숫자 1이 무엇을 의미하는지 한참 생각해야 함)
|
|
|
|
- **좋은 예:** `if (user.IsActiveAdultMember())` (함수 이름만으로 의도가 명확함)
|
|
|
|
|
|
### 2. 인지 부하(Cognitive Load)의 최소화
|
|
|
|
사람의 단기 기억력은 한계가 있습니다. 한 번에 머릿속에 담아야 할 정보가 많을수록 읽기 힘든 코드가 됩니다.
|
|
|
|
- **낮은 중첩도:** `if` 문 안에 `if`, 그 안에 `for` 루프가 여러 번 겹쳐 있으면 뇌는 각 단계의 조건을 기억하느라 과부하가 걸립니다. (Early Return 패턴 등으로 중첩을 제거하는 것이 좋습니다.)
|
|
|
|
- **작은 함수:** 하나의 함수가 100줄이라면 흐름을 놓치기 쉽습니다. 5~10줄 내외의 작은 함수로 쪼개면 각각의 책임이 명확해집니다.
|
|
|
|
|
|
### 3. 일관성 (Consistency)
|
|
|
|
사람은 패턴을 인식하는 데 능숙합니다. 코드 전체에서 동일한 규칙이 적용되어 있다면 다음에 올 내용을 예측할 수 있게 됩니다.
|
|
|
|
- 변수 명명 규칙(CamelCase vs snake_case), 폴더 구조, 에러 처리 방식 등이 프로젝트 전체에서 일관되어야 합니다.
|
|
|
|
- **"놀람 최소화의 원칙(Principle of Least Astonishment)":** 코드를 읽었을 때 "어? 이게 왜 여기서 이렇게 동작하지?"라는 당혹감이 없어야 합니다.
|
|
|
|
|
|
### 4. [[신호 대 소음비(Signal-to-Noise Ratio)]]
|
|
|
|
코드에서 진짜 중요한 로직(신호)은 강조하고, 형식적인 문법이나 군더더기(소음)는 줄이는 것입니다.
|
|
|
|
- **불필요한 주석 제거:** 코드만으로 설명이 가능하다면 주석은 소음일 뿐입니다.
|
|
|
|
- **단순한 추상화:** 너무 복잡한 디자인 패턴을 남용하면 실제 비즈니스 로직을 찾기 힘들어집니다.
|
|
|
|
---
|