TDD 및 POAD는 방법론을 경쟁합니까?

Question

여름 동안, 나는 디자인에 대해 많이 읽었습니다. 내가 읽은 두 가지 주목할만한 작품은 켄트 벡 (Kent Beck)의 Test Driven Development: By Example과 야코프 (Yacoub)의 Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems입니다.

이 책은 소프트웨어 시스템을 설계 할 때 두 가지 다른 접근 방식을 사용합니다. 제 생각에이 두 기술은 스펙트럼의 반대편에 있습니다. POAD, 우리는 패턴에서 엄격하게 설계

• : 나는 때문에 결론에 도달. TDD에서는 필요에 따라 패턴을 리팩터링합니다.
• TDD에서는 모델을 경량으로 유지합니다. POAD에서는 다양한 수준의 세분성을위한 모델을 엄격하게 개발합니다. 우리는 코드 생성과 라운드 트립을 사용하여 모델과 코드를 일관성있게 유지합니다.
• POAD는 이론적으로 보이고 작동이 입증되지 않습니다. 많은 소프트웨어 개발자가 TDD를 연습합니다.
  • 패턴 클래스보다 더 높은 수준의 추상화를 제공합니다 : 내가 설계 패턴 중심의 접근 방식을 사용하여 뒤에 추론을 많이 볼 수 있지만

  나는, TDD가 잘 작동하도록 입증 된 것으로 알고 있습니다.

• 패턴을 사용하면 높은 세분성의 세부 사항을 무시할 수 있습니다.
• 코드 측면에서만 시스템을 이해하려고하면 어려울 수 있지만 POAD는 추적 기능을 제공하는 상위 수준 모델을 제공합니다. 이러한 모델을 코드와 함께 사용하면 시스템을보다 빠르게 이해할 수 있습니다.

이렇게 주어진다면,이 방법론은 경쟁하고 상호 배타적입니까? 내가 POAD를 선호하는 것처럼 느껴지지만, TDD가 가치있는 디자인 방법론으로 확실히 인식됩니다. 선호되는 접근법이 있습니까?

Answer 1

나는 두 가지 접근 방식을 경쟁하거나 배타적이라고 생각하지 않습니다.

POAD를 사용하더라도 코드를 작성하는 중입니다. 이 코드는 여전히 Unit Tested가 될 수 있습니다. 코드를 작성하기 전에 테스트를 작성할 수 있습니다. 코드를 작성하고 코드를 작성하고 성공 여부를 확인하십시오.

더 나은 코드 작성을 위해 행복하게 길을 걸을 수 있어야합니다.

Answer 2

매우 다르며 경쟁이 치열합니다. TDD는 패턴 리팩터링을 권장하지 않습니다.

패턴은 프로그래밍 개념이 아니라 프로그래밍 구체입니다. 도메인에 대한 우리의 추상화를 프로그램에 인코딩하더라도 프로그램에 대한 추상화를 프로그램에 인코딩해서는 안됩니다.

패턴은 다른 프로그램과 관련하여 프로그램을 이해하고 필수적인 유사성을 식별하는 방법이지만 프로그램을 작성하는 방법은 아닙니다. 우리는 다르게 다른 코드 집합간에 필수적인 유사성을 확인하고이를 "패턴"이라고 부릅니다. 패턴에 프로그래밍하는 것은 권장되지 않습니다. 계약에 프로그래밍하거나 인터페이스에 프로그래밍하는 것과는 다릅니다. 패턴은 프로그래밍을 지시하지 않습니다 - 프로그램을 개념화하고 그에 대해 이야기 할 수있는 방법을 제공합니다. 여러분은 다음과 같이 말할 수 있습니다 : "XYZ 모듈의이 클래스 그룹은 광범위한 수준에서 ABC 패턴을 구현합니다." 하지만 예를 들어 클래스 이름이 없어야합니다. AbcPatternImpl.

패턴이 좋습니다.패턴 기반 개발에는 결함이 있습니다.