여러 프로젝트를 거치며 반복해서 얻은 원칙들이다. 원칙마다 그 원칙이 나온 프로젝트로 이어진다.

• 임시에는 만료 조건을 같은 자리에 적는다 — 안 적으면 영구가 된다

  임시 값·임시 코드·검사를 끄는 플래그를 넣을 때는, 같은 자리에 왜 임시인지와 무엇을 확인하면 걷을지를 함께 적는다.

  프로젝트 4개
• 실패한 적 없는 안전장치는 안전장치가 아니라 안심시키는 장치다

  테스트·경보·dry-run·fallback 같은 안전장치를 만들거나 믿을 때는, 일부러 한 번 망가뜨려 빨간불이 뜨는지 확인한다.

  프로젝트 6개
• 지시는 해결책의 모양으로 오고, 그 아래 목적과 제약은 따라오지 않는다

  무엇을 하라는 지시에 왜가 없으면, 착수 전에 해결하려는 문제·달라질 것·우리가 못 갖춘 전제를 먼저 묻는다.

  프로젝트 2개
• 코드가 표현하지 못하는 구분은 없는 것으로 취급된다

  상태·값·권한·소유권을 설계할 때는, 그 구분을 코드(타입·스키마·도구 설정)가 표현하게 만든다.

  프로젝트 8개
• 틀릴 것을 막을 수 없으면, 틀렸을 때 싸게 끝나도록 만든다

  틀릴 수 있는 결정을 내리기 전에 "이게 틀리면 무엇을 버려야 하나"를 한 문장으로 적는다. 답이 코드나 재작성이면 코드가 쌓이기 전에 문서로 먼저 굳힌다.

  프로젝트 7개
• 「왜」는 코드가 말하지 못한다 — 안 적으면 사람이 흩어질 때 사라진다

  방향을 바꾸거나, 장애를 고치거나, 규범을 세우는 커밋에는 한 일 대신 왜 그렇게 했는지와 무엇을 확인했는지를 적는다.

  프로젝트 6개
• 만드는 사람이 아니라 보는 사람이 정한다 — 무엇이 거짓이고, 무엇이 끝났는지

  덜 만든 기능·mock·자리표시를 내보낼지, 그리고 무엇이 끝났다인지는 그걸 보는 사람 기준으로 정한다.

  프로젝트 7개
• 재지 않으면 진단도 개선도 믿음이다

  고치기 전, 개선을 주장하기 전, 되돌릴 수 없는 작업 전에는 그 숫자를 지금 다시 잰다.

  프로젝트 9개
• 바뀌는 것은, 바꾸는 사람 손이 닿는 곳에 둔다

  값을 코드에 적기 전에 "이게 바뀔 때 누가 바꾸나"를 묻고, 내가 아니면 그 사람이 직접 바꿀 수 있는 곳에 둔다.

  프로젝트 1개
• 해법의 비용이 문제의 크기나 수명을 넘으면, 그 해법은 틀렸다

  해법을 고르기 전에 회수까지 몇 달과 이 문제·프로젝트가 몇 달 더 사나를 나란히 놓고, 앞쪽이 크면 더 가벼운 해법을 고른다.

  프로젝트 5개
• 검사하는 것도 고장난다 — 그리고 고장난 검사는 「이상 없음」처럼 보인다

  검사·필터·스크립트가 0건·통과·위반 없음을 보고하면, 결론을 내기 전에 실제로 검사한 대상의 수를 확인한다.

  프로젝트 1개