코드 습관

기존 코드를 수정할 때도 전략적으로 생각하고, 일관성을 지키고, 명확하게 써야 해. 이 세 가지가 코드 습관의 핵심이야.

소프트웨어 개발 시간의 대부분은 기존 코드를 수정하는 데 쓰이잖아. 근데 수정할 때 가장 큰 위험이 전술적 모드로 돌아가는 거야. "일단 이 버그만 고치자", "이 기능만 빨리 추가하자" — 이런 마인드로 코드를 수정하면 복잡성이 점점 쌓여. 저자는 수정할 때도 전략적 마인드셋을 유지하라고 강조하지. 구체적으로 세 가지야. 설계를 더 좋게 남겨라 — 보이스카우트 규칙과 같은 맥락이야. 새로운 코드도 설계 원칙을 따르라 — 기존 코드가 잘못되었으면 "기존 스타일에 맞추자"고 나쁜 패턴을 답습하지 마. 그리고 최소한 기존보다 나쁘게 만들지는 마. hack 위에 또 다른 hack을 쌓으면 시스템이 급속히 악화되거든.

코드를 수정할 때 주석도 같이 수정하는 것이 매우 중요해. 코드와 주석의 불일치는 주석이 없는 것보다 더 나쁠 수 있거든. 잘못된 주석은 개발자를 잘못된 방향으로 이끄니까. 주석을 코드 가까이에 두고, 커밋 전에 diff를 확인하면서 "이 변경에 영향받는 주석이 있나?"를 체크하는 습관을 들이자. 고수준 주석은 유지보수가 쉬워. "이 메서드는 사용자를 인증한다" 같은 주석은 구현이 바뀌어도 유효하거든. 추상화 수준이 높은 주석이 유지보수에도 좋은 거야.

수정은 설계를 개선할 기회이기도 해. "이 코드의 원래 설계 의도는 뭐였을까?", "이 수정이 기존 설계와 일관되는가?", "이 코드를 더 깊게 만들 수 있는가?" — 이런 질문을 던지면서 점진적으로 설계를 개선하는 게 현실적인 전략이지.

여기서 바로 일관성으로 넘어가자. 일관성은 복잡성을 줄이는 강력한 도구야. 인간의 뇌는 패턴 인식에 능하거든. 같은 패턴이 반복되면 "아, 이건 전에 본 거랑 같은 방식이구나" 하고 빠르게 이해할 수 있지. 일관성이 있으면 학습 비용이 줄어들고, 실수가 줄어들고, unknown unknowns가 줄어들어. "이 코드도 저기서 본 것과 같은 방식일 거야"라고 안전하게 가정할 수 있으니까.

일관성이 필요한 대표적인 영역은 코딩 스타일, 인터페이스 패턴, 설계 패턴, 불변식 등이야. 그리고 일관성은 저절로 유지되지 않아. 팀의 컨벤션을 문서화하고, 린터와 포매터로 자동화하고, 코드 리뷰에서 강제해야 해. 새로운 패턴을 도입할 때는 한 곳에서 확실하게 구현하고 나머지는 그걸 따라하게 하는 게 좋아.

저자가 특히 강조하는 건, 기존 관례가 마음에 안 들어도 따르라는 거야. 프로젝트에서 들여쓰기로 탭을 쓰는데 내가 스페이스를 선호한다고 해서 내 코드만 스페이스로 쓰면 안 돼. 일관성이 깨지는 것이 개인 취향보다 더 해롭거든. 바꾸려면 팀과 합의해서 한꺼번에 적용하는 게 맞아. 팀 프로젝트에서는 최고의 방식보다 일관된 방식이 더 가치 있어.

마지막으로 명확한 코드 이야기야. 명확한 코드는 읽는 사람이 빠르게, 별다른 노력 없이 이해할 수 있는 코드야. 핵심은 읽는 사람의 관점이지. 작성자에게 명확한 건 의미없어 — 작성자는 컨텍스트를 다 갖고 있으니까. 처음 보는 사람에게도 명확한가가 중요해.

코드를 불명확하게 만드는 것들이 있어. 이벤트 드리븐 프로그래밍에서 핸들러가 분산되면 전체 흐름 추적이 어렵지. Map<String, Object> 같은 제네릭 컨테이너는 안에 뭐가 들었는지 알 수 없어서 전용 클래스를 만드는 게 더 명확해. 변수 타입이 int인데 -1이 "해당 없음"을 의미하는 같은 암묵적 규약도 위험하고. 깊은 중첩은 각 수준의 조건을 다 기억하면서 읽어야 해서 인지적 부하가 높아. 같은 변수를 다른 목적으로 재사용하는 것도 혼란을 주지.

명확성을 높이려면 빈 줄과 들여쓰기로 논리적 구조를 시각적으로 드러내고, 14장에서 배운 명확한 이름을 쓰고, 같은 종류의 코드에 일관된 패턴을 적용하고, 코드만으로 전달이 안 되는 정보는 주석으로 보완해야 해. 저자의 핵심 메시지는 간단해 — 코드를 쓸 때 항상 **"처음 보는 사람이 바로 이해할 수 있을까?"**를 체크하라는 거야.

---

정리

6장 읽고 기억할 거 세 가지:

1. 기존 코드를 수정할 때도 전략적 마인드셋을 유지해야 해. hack 위에 hack을 쌓지 말고, 수정을 설계 개선의 기회로 삼자
2. 일관성은 인지적 부하를 줄이는 강력한 도구야. 기존 관례가 마음에 안 들어도 따르고, 바꾸려면 팀과 합의해서 한꺼번에 바꿔
3. 명확한 코드는 읽는 사람 기준이야. 제네릭 컨테이너, 암묵적 규약, 깊은 중첩을 피하고, 항상 "처음 보는 사람이 이해할 수 있나?"를 체크하자