Clean Code

1. 읽기 쉽고 유지보수 가능한 깨끗한 코드 작성

코드 품질의 유일한 유효한 측정 기준: WTFs/분

가독성이 최우선이다. 깨끗한 코드는 다른 개발자들이 쉽게 이해할 수 있어야 한다. 단순하고 우아하며 불필요한 요소가 없어야 한다. 광범위한 주석 없이도 의도를 명확히 표현하는 코드를 작성하도록 노력하라. 의미 있는 변수와 함수 이름을 사용하고, 함수는 작고 집중적으로 유지하며, 코드를 논리적으로 구성하라.

유지보수성은 진화를 가능하게 한다. 변경하기 어려운 코드는 부채가 된다. 코드를 유연하고 모듈화하여 변경 요구사항에 적응할 수 있도록 설계하라. DRY(반복하지 마라)와 SOLID 원칙을 따르며 느슨하게 결합되고 높은 응집력을 가진 시스템을 만들어라. 리팩토링을 통해 코드 구조를 개선하되 동작은 변경하지 마라.

깨끗한 코드는 보답한다. 깨끗한 코드를 작성하는 데 더 많은 초기 노력이 필요하지만, 장기적으로는 상당한 시간과 골칫거리를 줄여준다. 깨끗한 코드는 디버깅, 확장 및 유지보수가 더 쉽다. 개발자들이 더 효율적으로 작업할 수 있게 하며, 변경 중 버그가 발생할 위험을 줄여준다. 깨끗한 코드를 작성하는 것을 개발 관행의 핵심으로 삼아라.

2. 의미 있는 명명 규칙 따르기

변수, 함수 또는 클래스의 이름은 모든 중요한 질문에 답해야 한다. 왜 존재하는지, 무엇을 하는지, 어떻게 사용되는지를 알려줘야 한다.

의도를 드러내는 이름을 사용하라. 변수, 함수 및 클래스의 목적과 동작을 명확히 전달하는 이름을 선택하라. 한 글자 이름이나 암호 같은 약어는 피하라. 쉽게 검색할 수 있는 발음 가능한 이름을 사용하라. 예를 들어:

• 나쁜 예: d (일 단위 경과 시간)
• 좋은 예: elapsedTimeInDays

일관되고 정확하게 하라. 코드베이스 전반에 걸쳐 일관된 명명 규칙을 사용하라. 모호함을 피하기 위해 정확하게 하라 - 예를 들어, getActiveAccounts()와 getActiveAccountInfo()와 같은 의미 있는 구분을 사용하라. 가치 없는 인코딩이나 접두어는 피하라. 클래스 이름은 명사로, 메서드 이름은 동사로 하라.

이름 길이는 범위에 맞춰라. 더 큰 범위의 변수와 함수에는 더 길고 설명적인 이름을 사용하라. 작은 지역 범위에는 짧은 이름이 허용된다. 이름의 길이는 사용 범위에 비례해야 한다. 사용되는 맥락에서 가독성과 이해를 최적화하라.

3. 함수를 작고 집중적으로 유지하라

함수는 한 가지 일을 해야 한다. 그것을 잘해야 한다. 그것만 해야 한다.

작은 것이 아름답다. 함수는 작아야 한다 - 일반적으로 5-10줄 정도. 한 화면에 들어가고 즉시 이해할 수 있어야 한다. 긴 복잡한 함수를 작성하는 대신 잘 명명된 도우미 함수로 코드를 추출하라. 작은 함수는 이해, 테스트 및 유지보수가 더 쉽다.

한 가지 일을 잘하라. 각 함수는 단일하고 명확한 목적을 가져야 한다. 함수가 여러 가지 일을 하고 있다면, 그것들을 별도의 함수로 추출하라. 함수가 너무 많은 일을 하고 있다는 신호는 다음과 같다:

• 여러 수준의 추상화
• 여러 섹션 또는 코드 블록
• 많은 매개변수

하나의 추상화 수준을 유지하라. 함수 내의 문장은 모두 동일한 추상화 수준에 있어야 한다. 고수준 로직과 저수준 세부 사항을 혼합하지 마라. 저수준 작업을 별도의 함수로 추출하라. 이는 함수를 집중적이고 개념적으로 단순하게 유지하여 가독성을 향상시킨다.

4. 적절한 포맷팅과 조직화 실천

코드 포맷팅은 커뮤니케이션에 관한 것이며, 커뮤니케이션은 전문 개발자의 첫 번째 업무이다.

일관된 포맷팅이 중요하다. 코드 전반에 걸쳐 일관된 들여쓰기, 줄 바꿈 및 간격을 사용하라. 이는 가독성을 높이고 인지 부하를 줄여준다. 팀과 포맷팅 표준에 동의하고 자동화 도구를 사용하여 이를 강제하라. 주요 포맷팅 지침은 다음과 같다:

• 적절한 들여쓰기
• 일관된 중괄호 배치
• 논리적인 줄 바꿈
• 적절한 공백

코드를 논리적으로 조직하라. 관련된 코드를 함께 그룹화하고 관련 없는 코드를 분리하라. 빈 줄을 사용하여 논리적 섹션 간에 "단락"을 만들라. 관련 함수는 서로 가까이 배치하라. 파일은 단일 개념 또는 구성 요소에 집중하라. 적절할 때 큰 파일을 더 작고 집중된 파일로 나누라.

표준 규칙을 따르라. 언어와 커뮤니티의 표준 규칙을 준수하라. 이는 다른 개발자들이 더 친숙하고 접근하기 쉽게 만든다. 예를 들어, Java에서는:

• 클래스 이름은 PascalCase를 사용
• 메서드 이름은 camelCase를 사용
• 상수는 ALL_CAPS를 사용

5. 의존성 관리 및 중복 방지

중복은 소프트웨어의 모든 악의 근원일 수 있다.

중복을 제거하라. 중복된 코드는 추상화의 기회를 놓친 것이다. 중복을 발견하면 공통 코드를 재사용 가능한 함수나 클래스로 추출하라. 이는 로직을 중앙 집중화하고 일관되지 않은 변경의 위험을 줄여 유지보수성을 향상시킨다. 주의해야 할 중복 유형:

• 동일한 코드 블록
• 약간의 변형이 있는 유사한 알고리즘
• 반복되는 switch/case 또는 if/else 체인

의존성을 신중하게 관리하라. 모듈 간의 의존성을 최소화하여 결합도를 줄여라. 의존성 주입과 제어의 역전을 사용하여 코드를 더 모듈화하고 테스트 가능하게 만들어라. 의존성 역전 원칙을 따르라 - 구체화가 아닌 추상화에 의존하라. 이는 코드를 더 유연하고 변경하기 쉽게 만든다.

최소 지식 원칙을 사용하라. 모듈은 조작하는 객체의 내부를 알지 않아야 한다. 이는 모듈 간의 결합도를 줄여준다. 예를 들어, Demeter의 법칙을 사용하라 - 메서드는 다음에만 메서드를 호출해야 한다:

• 자신의 객체
• 매개변수로 전달된 객체
• 자신이 생성한 객체
• 자신의 직접 구성 요소 객체

6. 오류를 우아하게 처리하라

오류 처리는 중요하지만, 논리를 흐리게 한다면 잘못된 것이다.

오류 코드 대신 예외를 사용하라. 예외는 더 깔끔하고 코드의 주요 논리를 어지럽히지 않는다. 예외는 오류 처리를 행복 경로와 분리할 수 있게 한다. 예외를 사용할 때:

• 정보가 풍부한 오류 메시지 작성
• 예외에 컨텍스트 제공
• 호출자의 필요에 따라 예외 클래스 정의

null을 반환하지 마라. null을 반환하면 null 포인터 예외가 발생하고 null 검사가 코드에 어지럽게 된다. 대신:

• 목록에 대해 null 대신 빈 컬렉션 반환
• Null 객체 패턴 사용
• Java의 Optional 또는 함수형 언어의 Maybe 사용

try-catch-finally 문을 먼저 작성하라. 예외를 던질 수 있는 코드를 작성할 때 try-catch-finally로 시작하라. 이는 호출 코드의 범위와 기대치를 정의하는 데 도움이 된다. 오류 시나리오에서도 리소스가 적절히 관리되고 해제되도록 보장한다.

7. 철저한 단위 테스트 작성

테스트 코드는 프로덕션 코드만큼 중요하다.

TDD의 세 가지 법칙을 따르라. 테스트 주도 개발(TDD)은 코드 품질과 설계를 향상시킨다:

1. 프로덕션 코드를 작성하기 전에 실패하는 테스트 작성
2. 실패를 입증하기 위해 테스트를 최소한으로 작성
3. 테스트를 통과하기 위해 프로덕션 코드를 최소한으로 작성

테스트를 깨끗하고 유지보수 가능하게 유지하라. 프로덕션 코드와 동일한 코드 품질 기준을 테스트 코드에 적용하라. 정기적으로 테스트 코드를 리팩토링하고 개선하라. 잘 구조화된 테스트는 문서 역할을 하며 프로덕션 코드의 두려움 없는 리팩토링을 가능하게 한다.

포괄적인 테스트 커버리지를 목표로 하라. 행복 경로뿐만 아니라 엣지 케이스, 경계 조건 및 오류 시나리오를 다루는 테스트를 작성하라. 코드 커버리지 도구를 사용하여 테스트 커버리지의 격차를 식별하라. 100% 커버리지가 버그 없는 코드를 보장하지는 않지만, 리팩토링 및 변경에 대한 자신감을 제공한다.

8. 지속적으로 코드 리팩토링

캠프장을 발견했을 때보다 더 깨끗하게 떠나라.

기회가 있을 때마다 리팩토링하라. 코드를 작업할 때마다 코드 구조를 개선하라. 보이스카우트 규칙을 따르라: 코드를 발견했을 때보다 더 좋게 만들어라. 작은 점진적 개선이 시간이 지남에 따라 누적되어 코드 부패를 방지한다. 일반적인 리팩토링 기술은 다음과 같다:

• 메서드 또는 클래스 추출
• 명확성을 위한 이름 변경
• 복잡한 조건문 단순화
• 중복 제거

테스트로 안전하게 리팩토링하라. 리팩토링 전에 항상 견고한 테스트 스위트를 갖추어라. 작은 점진적 변경을 하고 자주 테스트를 실행하라. 이는 기존 기능을 깨뜨리지 않는다는 자신감을 준다. 가능한 경우 자동 리팩토링 도구를 사용하여 오류 도입 위험을 줄여라.

가치 제공과 리팩토링의 균형을 맞추라. 지속적인 리팩토링이 중요하지만, 진행을 마비시키지 않도록 하라. 완벽보다는 "충분히 좋음"을 목표로 하라. 가장 문제적이거나 자주 변경되는 코드 영역에 리팩토링 노력을 집중하라. 이해관계자에게 리팩토링의 가치를 전달하여 지속적인 코드 개선에 대한 지원을 확보하라.

9. 객체 지향 및 함수형 프로그래밍 원칙 적용

객체는 데이터를 추상화 뒤에 숨기고 그 데이터에 작용하는 함수를 노출한다. 데이터 구조는 데이터를 노출하고 의미 있는 함수가 없다.

객체 지향 원칙을 현명하게 사용하라. 캡슐화, 상속 및 다형성과 같은 원칙을 적용하여 유연하고 모듈화된 설계를 만들어라. SOLID 원칙을 따르라:

• 단일 책임 원칙
• 개방-폐쇄 원칙
• 리스코프 치환 원칙
• 인터페이스 분리 원칙
• 의존성 역전 원칙

함수형 프로그래밍 개념을 활용하라. 객체 지향 언어에서도 함수형 프로그래밍 기술은 더 깨끗한 코드를 작성하는 데 도움이 된다:

• 부작용 없는 순수 함수
• 불변 데이터
• 고차 함수
• 함수 합성

문제에 맞는 접근 방식을 선택하라. 객체 지향 및 함수형 패러다임은 각각 강점과 약점을 가지고 있다. 복잡한 도메인을 행동으로 모델링해야 할 때는 객체 지향 설계를 사용하라. 데이터 변환 및 처리 파이프라인에는 함수형 접근 방식을 사용하라. 많은 현대 언어는 하이브리드 접근 방식을 지원하여 시스템의 각 부분에 가장 적합한 도구를 사용할 수 있게 한다.

10. 동시성을 신중하게 고려하라

동시성은 디커플링 전략이다. 무엇을 할 것인지와 언제 할 것인지를 분리하는 데 도움이 된다.

동시성 문제를 이해하라. 동시 프로그래밍은 복잡성을 증가시키고 미묘한 버그의 가능성을 높인다. 일반적인 문제는 다음과 같다:

• 경쟁 조건
• 교착 상태
• 신호 누락
• 메모리 가시성 문제

동시성 문제를 분리하라. 동시성과 관련된 코드를 다른 코드와 분리하라. 이는 이해하고 테스트하기 쉽게 만든다. Executors, Futures 및 Actors와 같은 추상화를 사용하여 원시 스레드 대신 동시성을 관리하라.

불변성과 순수 함수를 선호하라. 불변 객체와 순수 함수는 본질적으로 스레드 안전하다. 공유 가변 상태를 피함으로써 많은 동시성 문제를 제거한다. 가변 상태가 필요한 경우 적절한 동기화 기술을 사용하고 원자 변수 또는 동시 컬렉션을 고려하라.

Last updated: July 25, 2024