- 내 코드 한 줄 한 줄 근거를 댈 수 있어야 한다

    - 가져다 쓰려면 정확히 알고 사용하고 설명할 수 있어야 한다

- 추측으로 작업하지 말 것

    - 이곳의 비즈니스 스펙이 1+1=3 라면 1+1=3이다

    - 일반적인 개발 방법에 따라 추측하면 문제가 생길 수 있다. (취소되면 is_used가 False 상태로 전이되는 것이 확실한지 확인했나?)

- 필요하면 기존 개발자가 작성한 코드, 아키텍처를 뭉개고 다시 만드는 것을 주저하지 말자


- 기능 테스트

    - 인터페이스 관점

    - 오류 케이스 관점

    - 가독성 관점

    - 성능 관점

    - 통합(전역) 로직-상태 관점

- 작업 시간과 테스트 시간의 비율은 1:1


- 큰 기능은 누구나 만들며 디테일이 중요하다

- 최대한 쉽고 간결하게 작성하자

- 개발 완료는 배포 후 오류 없는 것으로 확인될 때까지