좋은 코드는 뛰어난 글쓰기 기술, 오래 기억에 남는 내용, 명확한 챕터, 명확한 주제를 가진 좋은 책과 같습니다. 또한 훌륭한 음질과 컵홀더를 갖춘 자동차와도 같습니다. 차가 최고 속도에 도달하면 소음이 들리지 않고 물이 넘칠 염려도 없습니다. 고장이 나면 어떤 정비사라도 가장 일반적으로 사용되는 도구를 사용하여 최단 시간 내에 쉽게 고칠 수 있으며, 잘못된 코드는 이제 막 시작한 작가가 쓴 책과 같습니다. 각 장에는 명확한 목적이 없습니다. 한 문장이 장 전체에 걸쳐 반복됩니다. 스토리가 명확하게 정해져 있지 않습니다. 최고 시속 200마일을 보장하는 자동차가 있지만 사운드는 오래된 테이프만 재생되고 컵홀더가 불안정한 것과 같습니다. 반사경의 각도를 조정하면 갑자기 차가 고장 나 일반 정비공은 차를 고칠 수 없습니다. 생산 라인의 전문가를 불러 특수 공구를 사용해 고쳐야 합니다.
개발자는 코드를 작성하는 것이 아니라 코드를 읽고, 코드를 디버깅하고, 다른 사람이 제출한 개발 문서를 검토하고, 새로운 라이브러리를 배우는 데 많은 시간을 소비합니다. 코드를 읽을 때 개발자는 실제로 코드 해석자의 역할을 수행하며 자신의 머릿속으로 코드를 실행하고 현재 실행 상태를 기억하려고 노력하기 때문에 프로그래머는 코드를 읽을 때 주의가 산만해집니다.
작성 시 유지 관리 가능성: 프로그램이나 시스템이 가동된 후 발생하는 버그를 말하며, 개발팀은 다른 버그 없이 제때 버그를 해결할 수 있으며, 메서드의 원자성을 유지하고 코드의 응집력을 개선하면 일부 수정의 영향을 최소화하여 일부 메서드의 버그가 다른 모듈의 정상적인 기능에 영향을 미치지 않도록 할 수 있습니다. 작성 시점의 유지 관리 가능성에는 코드의 '테스트 가능성'도 포함됩니다.