주석
부적절한 정보
- 다른 시스템에 저장할 정보를 주석으로 작성하지 마라.
- 주석은 코드와 설계에 기술적인 설명을 부연하는 수단이다
쓸모 없는 주석
- 오래되거나 잘못된 주석은 바로 삭제하라
중복된 주석
- 코드 내용을 중복으로 설명하는 주석은 삭제하라.
성의 없는 주석
- 주석을 작성하는 경우에는 단어를 신중하게 선택하고, 문법도 준수하고, 간결 명료하게 작성하라
주석 처리된 코드
- 즉시 삭제하라.
- 소스 코드 관리 시스템이 기억한다.
환경
여러 단계로 빌드해야 한다
- 빌드는 간단히 한 단계로 끝나야 한다.
- 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드할 수 있어야 한다.
여러 단계로 테스트해야 한다.
- 모든 테스트는 한번에 실행 가능해야 한다.
함수
너무 많은 인수
- 함수는 인수가 적을수록 좋다.
- 없으면 가장 좋다.
출력 인수
- 함수에서 뭔가의 상태를 변경해야 한다면 출력 인수를 사용하지 말고 함수가 속한 상태를 변경하라.
플래그 인수
- boolean 인수를 함수가 여러 기능을 수행한다는 뜻이다.
죽은 함수
- 아무도 호출하지 않는 함수는 삭제한다.
일반
한 소스 파일에 여러 언어를 사용한다
- 소스 파일 하나에 언어 수와 범위를 최대한 줄여라.
당연한 동작을 구현하지 않는다.
- 함수 이름을 보고 기대하는 동작을 모두 구현하라.
- 구현하지 않으면 함수 이름만으로 함수 기능을 직관적으로 예상하기 어려워진다.
경계를 올바로 처리하지 않는다.
- 모든 경계 조건을 찾아내고, 모든 경계 조건을 테스트하는 테스트 케이스를 작성하라.
안전 절차 무시
- 컴파일러 경고를 꺼버리거나 실패하는 테스트 케이스를 제껴두지 마라
중복
- 코드에서 중복을 발견할 때마다 추상화하여 하위 루틴이나 다른 클래스로 분리하라.
- 똑같은 코드가 여러 차례 나오는 중복은 함수로 교체하라
- 조건을 거듭 확인하는 중복은 다형석으로 대체하라
- 알고리즘이 유사하나 코드가 서로 다른 중복은 TEMPLATE METHOD 패턴이나 STRATEGY 패턴으로 중복을 제거하라.
추상화 수준이 올바르지 못하다
- 모든 저차원 개념은 파생 클래스에 넣고, 모든 고차원 개념은 기초 클래스에 넣어라.
- 세부 구현과 관련한 상수, 변수, 유틸리티 함수는 파생 클래스에 넣어라
기초 클래스가 파생 클래스에 의존한다.
- 기초 클래스는 파생 클래스를 아예 몰라야한다.
- 파생 클래스 개수가 확실히 고정되었다면 기초 클래스에 파생 클래스를 선택하는 코드가 들어간다.
과도한 정보
- 자료를 숨겨라
- 유틸리티 함수를 숨겨라
- 상수와 임시 변수를 숨겨라
- 메서드나 인스턴스 변수가 넘쳐나는 클래스는 피하라
- 인터페이스를 매우 작게 그리고 매우 깐깐하게 만들어라.
- 정보를 제한해 결합도를 낮춰라
죽은 코드
- 실행되지 않는 코드는 삭제하라
수직 분리
- 변수와 함수는 사용되는 위치에 가깝게 정의하라
일관성 부족
- 유사한 개념은 같은 방식으로 구현하여 일관성 있게 동작하도록 하라
잡동사니
- 사용하지 않는 변수, 호출하지 않는 함수, 정보를 제공하지 않는 주석은 제거하라
인위적 결합
- 서로 무관한 개념을 인위적으로 결합하지 마라
- 함수, 상수, 변수를 선언할 때는 올바른 위치를 고민하라
기능 욕심
- 메서드가 다른 객체의 참조자와 변경자를 사용해 그 객체 내용을 조작하도록 하지 마라
선택자 인수
- 선택자 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만들어라
모호한 의도
- 행을 바꾸지 않고 표현한 수식, 헝가리식 표기법, 매직 번호 등 저자의 의도를 흐리는 방식으로 작성하지 마라
잘못 지운 책임
- 코드는 독자가 자연스럽게 기대할 위치에 배치하라
부적절한 static 함수
- 오버라이드할 가능성이 있는 함수는 static 함수로 작성하지 마라
서술적 변수
- 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하여 가독성을 높여라
이름과 기능이 일치하는 함수
- 이름만으로 분명하지 않기에 구현을 살펴야한다면 이름을 바꾸거나 기능을 정리하라
알고리즘을 이해하라
- 테스트 케이스를 모두 통과하는 것 뿐만 아니라 함수가 돌아가는 방식을 이해하라
논리적 의존성은 물리적으로 드러내라
- 의존하는 모든 정보를 물리적인 의존성으로 명시적으로 나타내라
If/Else 혹은 Switch/Case 문보다 다형성을 사용하라
- 모든 조건문을 의심하고 다형성을 먼저 고려하라
표준 표기법을 따르라
- 팀은 업계 표준에 기반한 구현 표준을 따라야 한다.
매직 숫자는 명명된 상수로 교체하라
- 의미가 분명하지 않은 숫자나 스트링들은 상수로 사용하라
정확하라
- 코드에서 뭔가를 결정할 때는 정확히 결정하라
- 호출하는 함수가 null을 반환할 가능성이 있다면 반드시 null을 점검하라
관례보다 구조를 사용하라
- 설계 결정을 강제할 때는 규칙보다 관례를 사용하라
- enum 변수가 멋진 switch/case 문의 명명 관례보다 추상 메서드가 있는 기초 클래스의 구조 자체로 강제하는 것이 더 좋다.
조건을 캡슐화하라
- 조건문의 조건에 조건의 의도를 분명히 밝히는 함수로 표현하라
부정 조건은 피하라
- ! 가 붙은 조건문 대신 부정 조건의 함수를 사용해 !를 제거하라
함수는 한 가지만 해야 한다
- 여러 가지 작업을 수행하는 함수는 분리하라
숨겨진 시간적인 결합
- 시간적인 결합이 필요한 경우 숨기지 말고 함수 인수를 적절히 배치해 함수가 호출되는 순서를 명백히 드러내라
일관성을 유지하라
- 시스템 전반에 걸쳐 구조의 일관성을 유지하라
경계 조건을 캡슐화하라
- 코드 여기저기에 +1이나 -1을 흩어 놓지 말고 변수로 캡슐화하라
함수는 추상화 수준을 한 단계만 내려가야 한다.
- 함수의 추상화 수준은 함수 이름이 의미하는 작업보다 한 단계만 낮아야 한다.
설정 정보는 최상위 단계에 둬라
- 추상화 최상위 단계에 둬야 할 기본값 상수나 설정 관련 상수를 저차원 함수에 두지 마라.
- 고차원 함수에서 저차원 함수를 호출할 때 인수로 넘겨라
추이적 탐색을 피하라
- 자신이 직접 사용하는 모듈만 알아야 하고 사용하는 모듈을 타고 들어가서 다른 모듈에 접근하지 마라
자바
긴 import 목록을 피하고 와일드카드를 사용하라
- 패키지에서 클래스를 둘 이상 사용한다면 와일드카드를 사용해 패키지 전체를 가져오라
- 이름이 같으나 패키지가 다른 클래스는 명시적인 import 문을 사용하거나 아니면 코드에서 클래스를 사용할 때 전체 경로를 명시하라
상수는 상속하지 않는다
- 상수는 상속하는 대신 static import 를 사용하라
상수 vs Enum
- Enum을 사용하라
이름
서술적인 이름을 사용하라
- 변수명과 함수명을 보고 하는 일을 짐작할 수 있는 이름을 사용하라
적절한 추상화 수준에서 이름을 선택하라
- 구현을 드러내지 말고 현재 추상화 수준을 반영하는 이름을 선택하라
가능하다면 표준 명명법을 사용하라
- 디자인 패턴을 반영한 이름, toString 과 같은 관례를 따르는 이름, 유비쿼터스 언어를 사용한 이름을 사용하라
명확한 이름
- 함수나 변수의 목적을 명확히 밝히는 이름을 선택하라
긴 범위는 긴 이름을 사용하라
- 범위가 짧으면 i, j와 같은 짧은 이름을 사용해도 되지만, 긴 범위는 긴 이름을 사용하여 의미를 정확하게 하라
인코딩을 피하라
- 오늘날 개발 환경에서 필요없는 m_, f 와 같은 접두어를 사용하지 마라
이름으로 부수 효과를 설명하라
- 함수 변수 클래스가 하는 일을 모두 기술하는 이름을 사용하라
테스트
불충분한 테스트
- 모든 조건을 검증하는 테스트를 작성하라
커버리지 도구를 사용하라!
- 커버리지 도구를 사용하여 테스트하지 않는 부분을 찾아라
사소한 테스트를 건너뛰지 마라
- 사소한 테스트도 큰 문서적 가치를 제공한다
무시한 테스트는 모호함을 뜻한다
- 불분명한 요구사항은 테스트 케이스에 주석 처리하거나 @Ignore를 붙여 표현하라
경계 조건을 테스트하라
- 경계 조건도 당연히 테스트하라
버그 주변은 철저히 테스트하라
- 버그는 모여있는 경향이 있으므로 버그 주변을 철저히 테스트하라
실패 패턴을 살펴라
- 실패하는 케이스의 공통점과 성공하는 케이스와의 차이점을 보고 문제를 진달할 수 있다.
테스트 커버리지 패턴을 살펴라
- 통과하는 테스트가 실행하는 코드와 실행하지 않는 코드를 보면 실패하는 테스트 케이스의 실패 원인을 알 수 있다.
테스트는 빨라야 한다
- 느린 테스트 무시될 수 있으므로 빨라야 한다.
inho ha / ian(swatchon) / iha(42seoul)