클린 코드 vs 빠른 배포: 실제로 중요한 것은?

Source: Dev.to

Introduction

모든 개발자는 깔끔하고 구조화된 코드를 작성하는 것과 기능을 빠르게 배포하는 것 사이에서 고민해 본 적이 있습니다. 두 가지 모두 중요하지만 상황마다 동일하게 가치가 있는 것은 아닙니다. 진짜 실력은 언제 어느 쪽을 우선시해야 하는지를 아는 데 있습니다.

When Speed Is the Right Call

• 초기 단계 기능
• 최소 기능 제품(MVP)
• 촉박한 마감일
• 나중에 폐기될 수도 있는 실험

이 경우 과도한 설계는 낭비입니다. 다음 주에 삭제될 수도 있는 코드를 완벽하게 만들기 위해 시간을 들이는 것은 좋은 엔지니어링이 아닙니다. 코드가 오래 살아남지 않을 거라면 완벽할 필요가 없습니다.

When Clean Code Pays Off

• 핵심 비즈니스 로직
• 공유 컴포넌트
• 다른 개발자들이 자주 건드릴 코드

이 영역에서 지저분한 코드는 오늘뿐 아니라 프로젝트 전체 수명 동안 당신을 느리게 만듭니다. 코드가 오래 살아남을수록 더 깔끔해야 합니다.

The Real Issue: Judgment

속도를 깨끗함보다 선택한다는 것이 부주의한 것이 아니라 판단의 문제입니다. 경험 많은 개발자라도 모든 것을 과도하게 설계하거나 모든 것을 서두르는 실수를 할 수 있습니다.

“이것을 깨끗하게 해야 할까, 빠르게 해야 할까?” 라고 묻는 대신

“이 코드가 얼마나 오래 살아남을 것이며, 누가 건드릴 것인가?” 라고 물어보세요.

이 한 질문이 대부분의 결정을 이끌어 줍니다.

Practical Guidelines

• 코드 설명을 전화로 해야 한다면, 너무 복잡한 것입니다.
• 같은 조각을 두 번 복사‑붙여넣기 하고 있다면, 리팩터링할 때입니다.
• 실험에서는 빠르게 배포하고 나중에 정리하세요.
• 여러 사람이 코드를 건드릴 경우, 속도를 늦추고 명확하게 작성하세요.
• 코드가 핵심 로직에 관여한다면, 처음부터 제대로 해두세요.
• 실제로 고통을 느낄 때까지 추상화를 피하세요.
• 모듈화하여 찾고 업데이트하기 쉽게 유지하세요.
• 30초 안에 무언가를 찾지 못한다면 구조가 잘못된 것입니다.
• 실제 문제가 있을 때만 최적화하고, 추측에 의한 최적화는 하지 마세요.
• 누군가가 새벽 2시에 디버깅할 것처럼 코드를 작성하세요.
• 코드를 발견한 것보다 조금 더 나은 상태로 남겨두세요.

Conclusion

완벽한 코드를 만들 필요는 없습니다. 목적에 맞는 코드를 만들면 됩니다. 깔끔한 코드와 빠른 배포는 적대관계가 아닙니다. 좋은 개발자는 두 가지를 균형 있게 다룹니다:

• 안전할 때는 빠르게 움직이세요.
• 중요할 때는 속도를 늦추세요.

빠르게 배포하면 진행이 되지만, 목표는 어느 한쪽을 선택하는 것이 아니라 각각이 언제 중요한지를 아는 것입니다.