품질 지상주의적 태도 유지

채팅 답변과 답변을 이해하기 쉽게 유지하세요.

도구 (Tools)

gsed, gfind, ggrep, gcat와 같은 GNU(GNU's Not Unix) 도구를 사용하세요.
courier:commit-changes-to-git 스킬로 변경 사항을 커밋하세요.
courier:submit-a-pull-request 스킬로 풀 리퀘스트를 제출하세요.
bugscribe:submit-an-issue 스킬로 이슈를 등록하세요.

규율 (Discipline)

간결하고 직접적이며 인간적인 산문으로 작성하세요.
전문 용어, 속어, 약어를 피하고 완전한 문장으로 평이한 영어(plain English)를 사용하세요.
기술적 실수는 지적하고, 비전과 아키텍처에 대해서는 사용자에게 의존하세요.
범위를 유지하고, 작업에 필요한 부분만 리팩토링하세요.
부분보다 전체를 먼저 생각하고, 재료보다 구성을 먼저 설계하세요(Design top-down, whole before parts, composition before ingredients).
설계상의 장애물을 우회하지 말고, 대신 저에게 물어보며 멈추세요.

작업 흐름 (Workflow)

변경 사항 전에 Git에서 가져오고, 명시적인 사용자 허가만 있을 때 푸시하세요.
각 브랜치 이름을 GitHub 이슈 번호로 지정하고, 확신이 서지 않을 때는 물어보세요.
항상 TDD(test-driven development)를 실천하며, 수정하기 전에 버그를 재현하세요.
버그가 재현될 때까지 유닛 테스트에 투자하고, 디버깅보다 직관을 신뢰하세요.
문제가 해결되기 어려울 때는 광범위하게 기록하세요.

변경 사항 (Changes)

상위 스트림(upstream)의 버그는 허용하며, 이슈를 제안하고 수정될 때까지 기다리세요.
변경 사항은 집중적이고 최소한으로 유지하세요.
퍼즐은 나중을 위해 남겨두고, 퍼즐 주도 개발(Puzzle Driven Development)을 따르세요.
냄새(smells)와 리팩토링을 표시하며, 조용히 수정하기보다는 이슈를 제안하세요.
체커(checkers)를 신뢰하고, 억제하는 것보다 코드의 스타일 위반을 고치세요.

코드 (Code)

기능성보다 미학을 선호하세요.
인라인 주석은 건너뛰세요.
클래스 앞에는 사용법이 아닌 목적을 설명하는 일반 텍스트 문서 블록(docblocks)을 붙이세요.
변수 이름은 단일 명사로 지정하세요.
불필요한 지역 변수를 삭제하고, 인라인 단일 사용 표현식으로 만드세요.
메서드는 단일 명사 또는 동사로 이름을 지정하고, 명령과 쿼리를 분리하세요.
빈 줄 없이 메서드 본문을 채우세요.

스타일 (Style)

오류 및 로그 메시지는 컨텍스트와 함께 한 문장으로 유지하세요.
메시지 끝의 마침표를 제거하세요.

Honor Elegant Objects와 SOLID 원칙(단일 책임, 개방성, 리스코프 치환, 인터페이스 분리, 의존성 역전)을 따르세요.
DDD(도메인 주도 설계)와 YAGNI(당장 필요하지 않은 것은 만들지 마라)를 따르세요.
SRP(단일 책임 원칙)와 DRY(반복되는 것을 반복하지 마라)를 적용하세요.
조용히 실패하는 것보다 즉시 실패하도록 만드세요.
하나의 주 생성자에서만 할당을 허용하고, 보조 생성자는 위임(delegating) 방식으로 처리하세요.
구현은 상속받기보다 객체로 조합(Compose)하세요.
'-er' 이름과 유틸리티 클래스는 거부하세요.
모든 클래스를 final로 만들고, 1개에서 4개의 속성만 가지도록 하세요.

메서드

할당 후 속성을 고정하는 불변(immutable) 객체만 만드세요.
static 메서드, public static 리터럴, 세터(setters), 게터(getters)를 제거하세요.
인터페이스에 먼저 메서드를 선언하고, 외부에는 아무것도 public으로 노출하지 마세요.
null 반환값과 인자는 거부하세요.
타입 검사(type introspection), 캐스팅, 리플렉션(reflection)을 건너뛰세요.

테스트

'Angry Tests'를 따르세요.
테스트당 하나의 단언(assertion)만을 마지막 문장으로 배치하세요.
각 실패 메시지는 부정적인 방식으로 작성하세요.
테스트는 짧게 유지하고, 한 개의 동작을 하나의 문장으로 검증하세요.
테스트 파일을 기능 파일과 일대일로 매핑하고, 테스트 이름은 문장처럼 지정하세요.
'cannot'과 'dont'에는 아포스트로피를 쓰지 마세요.
테스트는 공유 속성, setUp, tearDown, 상수, 정리(cleanup)로부터 격리시키세요.

픽스처

기본값 대신 테스트 대상 객체에 사용자 정의 인자를 제공하세요.
불필요한 코드, 부작용(side effects), 접근자(accessors), 생성자, 오류는 건너뛰세요.
Mock보다 Fake와 Stub을 선호하세요.
Hamcrest 매처를 사용하여 불규칙하고 무작위적인 입력을 사용하세요.
간단한 픽스처는 인라인으로 제공하고, 복잡한 것은 런타임에 생성하세요.
중복 방지를 위해 픽스처 객체를 만들고 임시 디렉토리를 사용하세요.
파일 시스템, 소켓, 메모리는 Mock 처리하지 마세요.

런타임

테스트에서 로깅을 비활성화하세요.
모든 대기(wait)는 타임아웃으로 제한하세요.
플래키한 블록(flaky blocks)은 재시도하며 동시성(concurrency)을 테스트하세요.
인터넷 연결이 없다고 가정하고, 임시 포트(ephemeral ports)를 사용하세요.