6. 동작하는 소프트웨어

💡 해당 책은 수필 느낌의 성격이 강하며 챕터 하나의 분량이 약 30페이지로 상당히 짧습니다. 그렇기에 포스팅이 다소 짧을 수 있습니다. 아래는 제가 책을 읽으며 가슴에 와닿은 내용들입니다.

---

보이지 않는 위협

• 코드의 품질이 낮아질수록 새로운 기능을 추가하거나 버그를 수정하거나 어떤 기능을 테스트하는 일이 점점 더 어려워진다. 품질이 낮아질수록 애플리케이션의 강건성과 신뢰성이 낮아진다.
• 비즈니스 의사결정에 영향을 끼치는 저품질 코드는 용납될 수가 없다.
• 우리 업계는 이제서야 코드의 품질이 프로젝트의 성공을 보증하지는 못하더라도 실패의 핵심 요인이 될 수 있다는 것을 배우고 있다.

시간에 대한 잘못된 인식

• 누군가 백로그의 기술적 부채 항목을 보고 언젠가 고칠 거라고 생각들을 하지만 그런 일은 절대 일어나지 않는다.
• 이 모든 것이 로컬에서 돌려볼 수 있는 '단위 테스트를 작성할 시간이 없어서' 발생한 일이다.
• 개발팀이 자동화할 수 있는 것들임에도, 테스터가 테스트 계획을 짜고 수동으로 검사하느라 시간을 낭비하는 일은 있어서는 안 된다.
• 자동화된 테스트를 만들고 활용하는 데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다.

단위 테스트 작성은 별개의 업무인가.

• 첫 번째로, 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이다. 별도의 작업이 아니다.
• 자신의 작업 시간만 생각하고 전체 프로젝트에 관계된 다른 사람들이 시스템을 테스트하고 디버깅하느라 얼마나 많은 시간을 소모해야 하는지는 생각하지 않는 사람이다.

태도의 변화

• 보이스카웃 규칙 '처음 발견했을 때보다 더 깨끗하게'를 지속적으로 적용해야 한다. 레거시 코드를 개선하고 이해도를 높이면 업무에 크게 도움이 된다.
• 이때 우리는 두 가지 관점 중 하나를 선택할 수 있다. 하나는 지금 하고 있는 일을 코통스런 전생의 업보로 보는 것이고 다른 하나는 재미있고 도전적이 문제로 바라 보는 것이다.