Clean Code: 10 Principles That Make You a Better Developer — cod-ai.com

내가 50,000라인의 코드베이스를 상속받았던 날을 아직도 기억한다. 그날은 내 경력 선택을 의문스럽게 만들었다. 2015년이었고, 나는 핀테크 스타트업에서 선임 개발자로 3년째 일하고 있었으며, 우리의 수석 엔지니어는 문서 없이 떠났다. 코드는 구실을 했지만—겨우—그 코드를 읽는 것은 미래의 개발자들을 싫어했던 누군가가 쓴 고대 이집트 문자와 같았다. 그 경험은 나에게 어떤 교과서도 가르쳐 줄 수 없는 깨끗한 코드에 대한 더 많은 것을 가르쳐 주었다.

아홉 년이 지나고, 나는 현재 하루 200만 건의 거래를 처리하는 시스템을 관리하는 회사의 수석 엔지니어가 되었다. 나는 수천 개의 풀 리퀘스트를 검토하고, 수십 명의 개발자를 멘토링하며, 내가 인정하고 싶지 않은 만큼의 레거시 코드를 리팩토링했다. 이러한 모든 과정을 통해, 나는 좋은 코드와 훌륭한 코드를 구별하는 10가지 기본 원칙을 정리했으며, 이는 내 작업뿐만 아니라 내가 코칭한 모든 개발자의 작업에도 변화를 가져왔다.

깨끗한 코드는 피곤하고 규칙을 따르기 위한 것이 아니다. 그것은 존중에 관한 것이다—당신의 미래 자신, 팀원, 그리고 2 AM에 프로덕션이 중단되었을 때 당신의 작업을 유지할 다음 사람에 대한 존중이다. 내가 배운 것을 공유하겠다.

더러운 코드의 진짜 비용

원칙으로 들어가기 전에, 이것이 왜 중요한지 이야기해보자. 현재 내 역할에서, 우리는 엔지니어링 팀 전반에 걸쳐 개발자 생산성을 추적하는 내부 연구를 수행했다. 우리는 개발자들이 기존 코드를 읽고 이해하는 데 평균 65%의 시간을 보내고, 실제로 새로운 코드를 작성하는 데는 35%만을 사용한다는 사실을 발견했다. 이 비율은 잘못된 코드로 인해 더 악화되어 레거시 시스템에서는 80/20으로 증가했다.

여기서 웃픈 사실은, 불명확한 변수 이름만으로도 우리 팀이 분기마다 약 127시간의 손실을 입는다는 것을 계산했다는 것이다. 단순히 x, temp, data2가 실제로 무엇을 나타내는지를 이해하는 데에만 3주 전체 근무 시간이 소모된다. 40명의 엔지니어가 있는 팀을 생각해보면, 나쁜 명명 규칙으로 인해 연간 6자리 숫자의 비용이 발생하게 된다.

나는 프로젝트가 기술적 불가능성 때문이 아니라 코드베이스가 너무 복잡해져서 간단한 변경조차도 몇 주가 걸리는 걸 보았다. 내가 자문을 해주던 한 전자 상거래 클라이언트는 체크아웃 시스템이 너무 취약하여 새로운 결제 수단을 추가하기 위해 3개월의 개발 주기가 필요했기 때문에 하루에 약 $50,000의 잠재 수익을 잃고 있었다. 깨끗한 코드 원칙을 적용한 6주간의 리팩토링 스프린트 후, 같은 변경이 4일 만에 끝났다.

비즈니스 사례는 분명하다: 깨끗한 코드는 귀하의 수익, 팀의 사기 및 혁신 능력에 직접적인 영향을 미친다. 이제 어떻게 이를 달성할 수 있는지 탐구해보자.

원칙 1: 의미 있는 이름은 당신의 첫 번째 문서화입니다

나는 한 번, 짧은 변수 이름이 코드를 빠르게 입력할 수 있게 만든다고 주장하는 개발자와 함께 일한 적이 있다. 그는 let u = getUserData() 또는 const p = calculatePrice()와 같은 코드로 작성했다. 그에게 3개월 후에 자신의 코드를 설명해 달라고 했을 때, 그는 설명할 수 없었다. 그는 자신의 약어 시스템을 잊어버렸다.

당신의 변수, 함수 및 클래스 이름은 이야기를 전달해야 한다. 주석을 필요로 하지 않고 의도를 드러내야 한다. 이 두 가지 예를 비교해 보라:

나쁨: const d = 86400;

좋음: const SECONDS_PER_DAY = 86400;

차이는 하찮게 보일 수 있지만, 자정에 디버깅을 하고 있고 계산이 틀린 이유를 이해하려고 할 때는 그렇지 않다. 두 번째 버전은 그 마법 숫자가 무엇을 나타내는지를 즉시 알려준다.

내가 멘토링하는 모든 주니어 개발자와 공유하는 이름 지정 체크리스트:

• 발음할 수 있는 이름 사용—코드 리뷰에서 말할 수 없다면, 너무 암호화되어 있다
• 검색 가능한 이름 사용—단일 문자 변수는 Ctrl+F로 찾을 수 없다
• 정신적 맵핑 피하기—독자가 당신의 약어를 번역하게 만들지 마라
• 개념당 하나의 단어 고르기—같은 작업에 대해 fetch, retrieve, get을 섞지 마라
• 해결책 도메인 이름 사용—다른 프로그래머가 당신의 코드를 읽을 것이므로 AccountVisitor 또는 JobQueue가 의미가 있다

실제로는, 이름에 대해 30초 더 생각하는 것이 나중에 평균 15분의 혼란을 줄여주었다. 이는 30배의 투자 수익률이다. 프로젝트 내 수백 개의 변수에 대해 이를 곱하면, 시간 절약은 막대해진다.

내가 사용하는 한 가지 기술: 변수가 무엇을 하는지 한 문장으로 명확하게 설명할 수 없다면, 이름은 충분히 좋지 않다. 스스로 시도해 보라—무언가의 이름을 짓는 데 어려움이 있다면, 이는 종종 그 자체가 너무 많은 일을 하고 있어 분해해야 한다는 신호다.

원칙 2: 함수는 하나의 작업을 수행하고 잘 해야 합니다

단일 책임 원칙은 단순한 학문적 이론이 아니다—생존 전략이다. 나는 processOrder라는 400행의 함수를 디버깅하면서 이 원칙을 힘들게 배웠다. 이 함수는 입력을 검증하고, 세금을 계산하고, 재고를 업데이트하고, 이메일을 보내고, 분석을 기록하고, 결제 처리를 맡았다. 세금 계산에서 버그를 찾는 것은 관련 없는 이메일 템플릿 코드를 통해 헤엄쳐야 한다는 것을 의미했다.