9. 반복하기, 테스팅하기

여러분은 반복 작업을 통해 위대한 소프트웨어를 작성합니다. 큰 그림을 그리고, 그 다음 애플리에키션이 완성될 때까지 조각조각들에 대해 반복적으로 작업하세요.

반복 심화 작업: 두 가지 기본적인 선택
반복 작업의 두 가지 접근 방식은 잘 작성된 요구 사항에 의해 유도됩니다.

1. 특징 주도 개발(Feature driven development)
애플리케이션의 특정한 특징을 선택하고, 완성될 때까지 그 특징을 계획, 분석, 개발하는 것입니다.
애플리케이션의 특정한 특징들에 집중하는 것을 선택할 수있습니다. 이 접근 방법은 고객이 원하는 기능의 한 조각을 선택하고, 그것이 완성될 때까지 작업하는 것입니다.

한 번에 하나의 특징을 작업하고 그리고 나서 반복하여, 애플리케이션의 기능을 완성할 때까지 한 번에 하니씩 특징들을 구현합니다.

 2. 유스케이스 주도 개발(Use case driven development)
유스케이스의 시나리오를 선택하여 시나리오가 완성될 때까지 코드를 작성하는 것입니다.
애플리케이션의 특정한 흐름에 집중하는 것을 선택할 수 있습니다. 이 접근 방법은 애플리케이션에서 하나의 완전한 경로를, 명확한 시작에서 끝까지 선택하여 코드로 구현하는 것입니다.

유스케이스 내에서 하나의 시나리오를 완성하는 작업을 합니다. 그 다음 또 다른 시나리오를 선택하여 작업하며, 유스케이스의 모든 시나리오가 완성될 때까지 반복합니다. 모든 유스케이스가 작동할 때까지 반복합니다.

특징 주도 개발과 유스케이스 주도 개발이의 차이점 

특징 주도 개발	유스케이스 주도 개발
특징 주도 개발은 더 세분화된 모양 입니다.	유스케이스 주도 개발은 더 "큰 그림"의 모양 입니다.
서로 별로 연결되어 있지 않은 특징들이 많을 때 잘 동작 합니다.	독립적인 기능보다는 많은 프로세스와 시나리오를 가지고 있는 애플리케이션의 경우 잘 동작합니다.
고객에게 동작하는 코드를 빨리 보여줄 수 있습니다.	고객에게 각 개발 단계마다, 더 큰 단위의 기능 조각을 보여줄 수 있습니다.
매우 기능 주도적입니다. 특징 주도 개발을 사용하면 어떠한 특징도 빠트리는 일이 없을 겁니다.	매우 사용자 중심적입니다. 유스케이스 주도 개발을 사용하면 사용자가 시스템을 사용하는 여러 방법들을 모두 고려하여 코딩할 것입니다.
연결되어 있지 않은 기능의 조각들이 많은 시스템에서 특히 잘 동작합니다.	길고 복잡한 프로세스를 가진 트랜잭션 시스템에서 특히 잘 동작합니다.

* 실제 대부분의 좋은 소프트웨어 분석 설계는 다양한 접근 방식을 혼용하여 사용합니다. 여러분은 유스케이스로 시작할지도 모릅니다. 그 다음 작업을 시작하기 위해 유스케이스에서 작은 특징 하나를 선택할 수 있습니다. 마지막으로 이 특징을 어떻게 구현할지 이해하기 위해 테스트를 사용할 수도 있습니다.(테스트 주도개발)

특징 주도 개발 방법 사용 예

1. 특징 리스트 중 하나를 선택하여 그것을 끝낼 때까지 작업할 수 있습니다.
2. 하나의 특징을 결정했다면, 본문 분석을 그 특징에 대해서 다시 하여 특징에 대한 새로운 특징 리스트를 작성한다.
3. 특징들에 대한 자세한 클래스 다이어그램을 작성한다.
4. 테스트 시나리오를 작성한다.
1. 테스트는 간단하고 한 번에 기능의 작은 부분 하나만을 테스트 해야 합니다.
2. 테스트 주도 개발은 클래스의 기능을 올바르게 만드는데 집중합니다.
5. 클래스들에 대해 다시 분석하기(공통점 분석 정제하기)
   좋은 소프트웨어는 반복 작업을 통해 완성됩니다. 애플리케이션의 매우 작은 부분을 작업하면서, 분석과 설계를 하고, 다시 이를 되풀이 하세요. 반복해서 작업할 때마다, 설계 결정들을 재평가하고, 여러분의 설계에 도움이 되면 무언가 변경하는 것을 두려우워하지 마세요.
6. 클래스 작성

 

좋은 테스트를 만드는 방법

1. 각 테스트 케이스는 아이디와 이름을 가지고 있어야 합니다.
   테스트 케이스의 이름에 무엇이 테스트되는지 나타나야 합니다.
2. 각 테스트 케이스는 그것이 테스트하는 특정한 것 하나를 테스트 해야 합니다.
   각 테스트 케이스는 한 번에 한 가지 기능만을 테스트해야 합니다.
3. 각 테스트 케이스는 여러분이 제공하는 입력 값을 가지고 있어야 합니다.
4. 각 테스트 케이스는 예상되는 출력 값을 가지고 있어야 합니다.
5. 대부분의 테스트 케이스는 초기 상태를 가지고 있습니다.

 

OOA&D 도구 상자

요구사항

• 좋은 요구 사항은 시스템이 고객이 기대한 대로 동작하도록 합니다.
• 여러분의 요구 사항이 시스템의 유스케이스의 모든 단계들을 담고 있는지 확인하세요.
• 유스케이스를 사용해서 고객이 잊고 얘기하지 않았던 것들을 찾아내세요.
• 유스케이스는 시스템에 추가되어야 할 불완전하거나 빠진 요구 사항들을 분명하게 합니다.
• 요구 사항은 항상 끊임없이 변화합니다.(그리고 성장합니다.).

분석과 설계

• 잘 디자인된 소프트웨어는 변경과 확장이 쉽다.
• 기본적인 캡슐화와 상속 같은 객체지향 원리를 사용하여 소프트웨어를 좀 더 유연하게 만드세요.
• 디자인이 유연하지 않으면, 변경하세요. 변경해야 하는 것이 여러분의 디자인이더라도, 결코 나쁜 디자인을 고수하지는 마세요.
• 여러분의 각 클래스의 응집도를 높게 하세요. 여러분의 클래스 각각은 하나의 일을 정말 잘하는 것에 중점을 두어야 합니다.
• 소프트웨어 디자인을 진행하면서, 항상 높은 응집도를 위해 노력하세요.

큰 문제들 해결하기 정리

1. 고객의 말에 귀 기울여, 여러분이 만들어 주길 바라는 것이 무엇인지 알아낸다.
2. 특징 리스트를 고객이 이해하는 용어를 사용하여 작성한다.
3. 작성한 특징 리스트가 고객이 실제로 원하는 것인지 확인한다.
4. 유스케이스 다이어그램을 사용하여 시스템의 청사진을 만든다.
5. 큰 시스템을 여러 개의 작은 섹션으로 나눈다.
6. 디자인 패턴을 시스템의 작은 섹션에 적용한다.

객체지향 원리

• 변하는 것을 캡슐화 하라.
• 구현에 의존하기 보다는 인터페이스에 의존하도록 코딩하라.
• 각 클래스는 변경 요인이 오직 하나이어야 한다.
• 클래스는 행동과 기능에 관한 것입니다.
• 클래스는 확장에는 열려있고, 수정에는 닫현 있어야 한다.(OCP)
• 공통되는 부분을 추출하여 추상화하고 한 곳에 두어 중복 코드를 피하라(DRY원리).
• 시스템의 모든 객체는 하나의 책임만을 가지며, 객체가 제공하는 모든 서비스는 그 하나의 책임을 수행하는 데 집중되어 있어야 한다.(SRP)
• 서브 클래스들은 부모 클래스들이 사용되는 곳에 대체될 수 있어야 한다.(LSP)

개발 접근 방식

• 유스케이스 주도 개발은 시스템에서 하나의 유스케이스를 선정하여, 유스케이스의 모든 시나리오를 포함해서 그 전체를 구현하고 코드 작업을 완성하는데 중점을 두고 있습니다. 그 다음에 애플리케이션의 다른 것으로 넘어갑니다.
• 특징 주도 개발은 하나의 특징에 집중하여 그 특징의 모든 행위 모두를 코드 작업합니다. 그 다음에 애플리케이션의 다른 것으로 넘어갑니다.
• 테스트 주도 개발은 한 가지 기능의 테스트 시나리오를 작성하고, 그 다음에 그 기능에 대한 코드를 작성합니다. 그리고 모든 테스트를 통과할 때까지 소프트웨어를 작성합니다.
• 좋은 소프트웨어 개발 방법이란 대체로 개발 주기의 여러 단계에서 이러한 개발 모델 모두를 혼용합니다.

프로그래밍 기술

• 약정에 의한 프로그래밍은 여러분과 소프트웨어 사용자가 지키기로 합의한, 소프트웨어가 어떻게 동작해야 하는지에 관한 계약을 설정합니다.
• 방어적 프로그래밍은 다른 소프트웨어를 신뢰하지 않고, 다른 소프트웨어가 나쁜거나 안전하지 않은 정보를 제공하는지 확인하기 위해, 광범위 하게 오류와 데이터를 점검합니다.

 

핵심 정리

• 좋은 소프트웨어를 작성하는 첫 번째 단계는 여러분의 소프트웨어가 고객이 기대하고 원하는대로 동작하도록 하는 것입니다.
• 고객은 다이어그램이나 목록에는 관심이 없습니다. 단지 여러분의 소프트웨어가 실제 무엇인가 하는 것을 보고 싶어합니다.
• 유스케이스 주도 개발은 애플리케이션의 유스케이스에서 한 번에 하나의 시나리오에 집중합니다.
• 유스케이스 주도 개발에서, 한 번에 하나의 시나리오에 집중합니다. 그러나 대부분 하나의 유스케이스의 모든 시나리오를 코딩 작업한 이후에 또 다른 유스케이스의 시나리오로 이동합니다.
• 특징 주도 개발은 하나의 특징을 완전히 코딩 작업한 후에 그 밖의 다른 것으로 이동합니다.
• 한 번에 하나의 특징을 선택하는 한, 특징 주도 개발에서는 크거나 작은 특징 중에서 한 가지로 작업할 수 있습니다.
• 소프트웨어 개발은 항상 반복 작업입니다. 큰 그림을 살펴보고, 그 다음 작은 단위의 기능을 반복 작업합니다.
• 하나의 새로운 특징이나 유스케이스를 가지고 작업을 시작하는 것을 포함해서, 개발 주기의 모든 단계마다 분석과 설계를 해야 합니다.
• 테스트를 통해서 소프트웨어가 어떠한 버그도 가지고 있지 않다는 것을 확인하고, 고객에게 소프트웨어가 작동하고 있다는 것을 입증할 수 있습니다.
• 좋은 테스트 케이스는 오직 기능의 특정 부분 하나만 테스트 합니다.
• 테스트 케이스는 하나의 클래스에 하나 혹은 서너개의 메소드를 포함할 수 있고 또는 여러 개의 클래스를 포함할 수 있습니다.
• 테스트 주도 개발은 테스트를 먼저 작성하고 이 테스트를 통과할 수 있도록 소프트웨어를 개발한다는 생각에 기반하고 있습니다. 결과는 모든 기능을 갖춘 동작하는 소프트웨어 입니다.
• 약정에 의한 프로그래밍은 트랜잭션의 양쪽 대상이 무슨 행동이 무슨 행위를 발생시키는지 알고 있다는 가정하에 약정을 지키는 것입니다.
• 약정에 의한 프로그래밍 환경에서, 메소드는 대부분 오류가 발생할 때 null이나 점검이 필요 없는 예외 상황을 반환합니다.
• 방어적 프로그래밍은 잘못될 것들을 찾아서, 문제 상황을 회피할 수 있도록 폭넓게 테스트 합니다.
• 방어적 프로그래밍 환경에서, 메소드는 대부분 "빈"객체나 혹은 점검이 필요한 예외 상황을 반환합니다.