🌈 Chapter 8: 무결점과 견고한 설계

• 제품에 버그가 없고 견고하게 설계됐다고 확신하기 위해서는 훌륭한 기술 능력을 키워야 한다.

📚 올바로 작동하는 피처를 늘려 제품을 만듭니다.

• 또한 제품은 점진적으로 발전하는 설계에 기반을 두고 있어야 한다.
• 개발팀은 프로젝트의 진행 상황에 따라 설계를 확장해가며 모든 피처가 제대로 작동할 수 있도록 유지해야 한다.
• 또한 올바른 우선순위에 따라 피처 단위로 개발을 진행해야 한다.
• 하지만 문제가 몇 가지 있다.

📚 결함은 피처의 완성도를 떨어뜨립니다.

• 결함을 제거해 프로젝트의 진행 상황을 명확히 해야 한다.
• 프로젝트는 반드시 피처를 단위로 계획하고 피처에 의해 성장하고 피처를 단위로 관리해야 한다.
• 하나의 피처 개발이 끝났다면 그 피처는 실제로 작동해야 한다.
• 피처에 결함이 있다면 피처의 완성도가 떨어지고 프로젝트의 진행을 방해한다.
• 결함이 아직 발견되지 않았다면 더 심각한 상황에 놓일 수 있다. 상태를 얼마나 나쁜지조차 알 수 없기 때문이다.
• 프로젝트가 결함으로 둘러싸이면 효율적으로 작업을 진행할 수 없다.

📚 결함 수정이 일정을 얼마나 지연시킬지 알 수 없습니다.

• 그러나 프로젝트가 어떻게 진행되는지 명확히 알려면 반드시 해야 한다.
• 버그 하나를 발견했다는 것은 이미 수많은 버그가 있을 수 있다는 말이다.
• 프로젝트가 끝나기 전까지 고치지 않으면 새로운 피처를 추가하는 계획에 차질이 생긴다.

📚 배포일이 다가왔는데도 피처가 얼마나 완성됐는지 알지 못한다면요?

• 결함이 버젓이 보여도 다른 방법이 없다. 일정에 맞춰 소프트웨어를 배포하는 수 밖에.. 비지니스 측면에서도 매우 나쁜 선택이다.

우선순위를 매겨 버그를 한꺼번에 수정하는 방법은 어떨까요? ➡ ❌

• 프로젝트를 진행할 때는 결함이 가능한 한 적게 생기도록 해야 한다.
• 배포일을 앞두고 결함 수정으로 일정이 얼마나 지연될지 알 수 없기 때문이다.
• 일정은 지연되고 버그는 수두룩하다면 스스로를 한심하게 여기게 될 것이므로 이런 상황은 만들면 안된다.

📚 피처는 계속 추가되고 개선됩니다.

• 설계도 계속 변화하니, 그 과정에서 실수할 수도 있다. 그래서 끊임없이 종합적으로 테스트해야 한다.
• 반드시 개발 주기가 끝날 때마다 가능한 한 버그가 없도록 유지해야 한다. 오직 테스트만이 결함을 최소화하는 방법이다.
• 피처를 추가하거나 개선할 때마다 더 많이 테스트해야만 더 나은 소프트웨어를 만들 수 있다.
• 새로운 피처를 테스트함과 동시에, 이전에 있던 피처들도 함께 테스트함으로써 모든 피처가 제대로 작동하는지 확인할 수 있다.
• 테스트는 비지니스와 개발자 관점으로 나눠 진행해야 한다.

📚 개발 주기가 끝날 때마다 반드시 비지니스 테스트를 수행합니다.

• 개발 주기가 끝날 때마다 반드시 비지니스 관점에서 테스트해 요구 사항을 제대로 충족하는지 검증해야 한다.
• 약 2주의 개발 주기마다 제품에 새로운 피처를 추가해야 한다. 새로운 피처가 잘 작동하는지 뿐만 아니라 이전에 있던 피처들이 문제는 없는지도 확인해야 한다.
• 그러려면 반드시 비지니스 관점에서 테스트해야 하며 제품이 마주칠 다양한 환경도 확인해야 한다.
• 테스트를 위해서 사용하는 비지니스 용어로 피처를 서술하고, 그 테스트가 자동으로 수행되도록 하여 해당 피처가 잘 작동함을 보장할 수 있다면 좋다.
• 그런 방법 중 유명한 것이 바로 인수테스트 주도 개발(ATDD, Acceptance Test-Driven Development)이다.

📚 개발 단계에서도 더 자주 테스트를 수행해야만 합니다.

• 개발자는 매일 코드를 변경하기에 시간을 낭비하지 않기 위해서는 개발 단계에서도 더 자주 테스트를 수행해야만 한다.
• 비지니스 테스트에서도 결함이 발견되기를 기대할 수 있다. 하지만 보통 비지니스 테스트는 매우 오랜 시간에 걸쳐 진행되며 문제가 발생해도 구체적인 에러를 알려주지 않는다.
• 따라서 개발자도 자동화된 전체 테스트를 진행해야만 결함을 조기에 발견하고 수정하여 제품을 더 안정적으로 만들 수 있다.
• 이와 같은 테스트를 진행하기에 가장 좋은 방법은 개발자에게 테스트를 먼저 작성하게 한 뒤, 그 테스트를 통과하게끔 제품을 개발하는 것이다.
• 이 방법이 테스트 주도 개발(TDD, Test-Driven Development)이다.

📚 테스트 주도 개발은 개발 속도를 더 높여줍니다.

• 실수가 줄어들고 결함을 더 빨리 찾을 수 있기 때문이다.
• 결함이 발생한 최초 지점으로부터 멀어질수록 결함을 찾아내고 수정하는 작업은 오래 걸린다.
• 개발자 테스트를 할 때 미리 만들어둔 혹은 코딩 과정에서 추가한 모든 테스트가 성공할 때까지 소프트웨어의 어떤 부분도 배포해서는 안 된다.
• 개발 중인 코드를 테스트하는 일은 결함이 제품으로 들어가는 것을 방지한다.
• 이 방법은 피처를 다 구현했다고 생각될 때 테스트하는 것보다 빠르게 피처를 개발할 수 있다.

📚 초기에는 매우 작은 피처들만 있습니다. 설계도 그만큼 간결하죠.

• 점진적으로 일한다는 것을 기억하자.
• 개발 주기마다 실제로 작동하는 피처들을 제품에 추가한다.
• 초기에는 설계는 잘 되어 있어야 하지만, 당장 필요한 피처들을 추가할 수 있을 정도로만 좋으면 된다.

📚 설계는 쉽게 무너질 수 있습니다.

• 소프트웨어에 어떤 것을 추가할 때는 자칫 설계가 망가질 수 있다.
• 올바른 설계도 한순간의 결정으로 나빠질 수 있다.
• 그러지 않으려면 정교하게 설계하고 고쳐 나가야 한다.
• 조잡한 설계는 작업 속도를 떨어뜨린다. 훌륭한 설계를 유지하기 위해서는 숙련된 기술과 꾸준한 관리가 필요하다.

📚 피처 단위로 제품이 성장할수록 설계도 함께 성장해야 합니다.

• 제품은 항상 올바른 설계를 유지해야만 한다.
• 나쁜 설계는 일정을 지연시키는데 설계를 바꾸기 어렵기 때문이다.
• 프로젝트가 성장하고 피처가 추가될 때마다 이를 지원하기 위해서는 설계도 성장해야 한다.
• 항상 최고의 설계를 유지해야 한다.

📚 피처를 개발할 때마다 설계를 개선해야 합니다.

• 개발팀은 각 피처를 개발할 때마다 반드시 그 피처를 지원하도록 설계를 개선해야 한다.
• 설계를 올바르게 유지하려면 지속적으로 설계를 개선해야 한다.
• 올바른 설계를 유지하는 일을 리팩토링이라고 한다.
• 리팩토링은 올바른 설계를 유지하는 데 꼭 필요한 기술이다.

📚 올바른 설계를 유지하지 못한다면 어떻게 될까요?

• 올바른 설계를 유지하지 못한다면 일정이 지연되거나 프로젝트를 중단시킬 수 있다.
• 설계를 개선하지 않고 그대로 둔다면 작업 속도는 떨어진다.
• 피처를 개발하는 데 드는 시간과 비용은 더 커지게 된다. 올바른 설계를 유지하지 못하면 작업 효율은 계속 떨어진다.
• 피처 단위로 개발하려면 테스트와 리팩토링을 함께 진행해야 한다. 이 개발 방법의 본질이 테스트와 리팩토링에 있기 때문이다.
• 자동화된 테스트는 모든 피처가 제대로 작동하도록 도와준다.
• 이 테스트는 비지니스 관점과 개발자 관점으로 나눌 때 가장 유용하다.
• 피처 단위 개발을 계속하려면 설계를 꾸준히 개선해야만 하고 이를 위해 리팩토링을 해야 한다.
• 하지만 가장 뛰어난 리팩토링조차 무언가를 망가뜨릴 때가 있다. 이때 비지니스 테스트와 개발자 테스트가 설계를 올바르게 개선할 수 있도록 자신감을 심어준다.
• 절대 이 둘 없이 피처 단위 개발을 진행해서는 안 된다.