설계 후 구축하기
개요
작업 흐름은 순서대로 브레인스토밍 → 명세 → 계획 → 실행 → 기록의 다섯 단계를 거칩니다. 설계가 명확히 표현되고 승인되기 전에는 구현이 시작되지 않습니다. 가장 간단한 작업일수록 검증되지 않은 가정이 가장 큰 비용을 초래합니다.
이 규칙의 글자를 위반하는 것은 그 정신을 위반하는 것입니다. "코딩하면서 설계하겠다"는 설계가 아닙니다.
다섯 단계
- 브레인스토밍. 의도, 제약 조건, 성공 기준을 탐구합니다. 한 번에 하나의 질문을 던집니다. 장단점과 권장 사항이 포함된 2~3가지 접근 방식을 제안합니다. 설계에 수렴하고 명시적 승인을 받습니다. 여기서는 코드를 작성하지 않습니다.
- 명세. 승인된 설계를 날짜가 포함된 문서에 작성합니다. 명세는 구축될 내용에 대한 계약입니다.
- 계획. 명세를 코드에 손대기 전에 순서가 지정된 검토 가능한 구현 계획으로 분해합니다.
- 실행. 검토 체크포인트와 함께 계획에 따라 구현합니다.
- 기록. 구축된 내용과 그 이유를 결정 기록(
recording-decisions참조)에 추려서 기록합니다.
대규모 작업은 분해하세요. 요청이 여러 독립적인 하위 시스템에 걸쳐 있는 경우 세부 사항을 구체화하기 전에 멈추고 분해하세요. 각 하위 프로젝트는 자체 주기로 실행되며, 종속성 순서대로 구축됩니다.
사용하지 말아야 할 경우
진정으로 사소하고 되돌릴 수 있는 편집(오타, 로그 라인, 구성 값)은 실행 단계로 바로 건너뜁니다. 기준: 여기서 잘못된 추측이 설계 단계보다 더 많은 비용을 초래할까? 그렇다면 먼저 설계하세요.
일반적인 합리화
| 변명 | 현실 |
|---|---|
| "이건 설계가 필요 없을 정도로 간단해" | 간단한 작업은 가정을 숨깁니다. 몇 문장의 설계는 저렴하지만, 재작성은 그렇지 않습니다. |
| "진행하면서 설계하겠어" | 설계가 확정되기 전에 작성된 코드는 다시 작성되는 코드입니다. 설계는 별개의 행위입니다. |
| "사용자가 무엇을 구축하라고 알려줬는데, 그게 바로 설계야" | 요청은 무엇을 할지 말할 뿐 어떻게 할지는 말하지 않습니다. 어떻게 하는 것이 설계입니다. |
| "코드베이스를 먼저 탐색하면 접근 방식을 알 수 있을 거야" | 탐색은 설계에 정보를 제공하지만, 하나의 승인을 대체하지는 않습니다. |
| "우린 서두르고 있어" | 서두를 때야말로 건너뛴 설계가 일회용 작업을 만들어내는 때입니다. |
위험 신호 — 중지
- 승인된 설계 없이 편집기를 여는 경우
- "잠깐 프로토타입만 만들어 볼게" (명세가 없는 프로토타입은 검토되지 않은 범위입니다)
- 계획 없이 여러 파일 변경을 시작하는 경우
- 사용자의 한 줄 요청을 완성된 명세로 취급하는 경우
이 모든 것은 다음을 의미합니다: 멈추고, 설계하고, 승인을 받은 후 구축하세요.
전체 근거: engineering-constitution/references/engineering-constitution.md에 번들된 헌법 제1조.