개발 방법론 개념 정리(tdd, ddd)
개발 방법론 개념 정리(tdd, ddd)
최근에 인턴직을 하며 회사 코드도 뜯어보고 사수 분과 개발에 대해 이야기 하다가 DDD관련 개발 방법론을 주제로 이야기 하게 되었다.
개인적으로는 아키텍처나 클린코드는 평소에 공부를 했었는데 개발 방법론은 교과서에서 잠깐만 보고 직접 공부해보지 않은 것 같아 간단히 정리하려고 한다.
1. 개발 방법론이란?
개발 방법론은 소프트웨어를 생산시에 필요한 프로그래밍 개발 과정들을 정리하고 표준화하여 프로그래머들이 개발과정에서 일관성을 유지하고 효과적인 협업이 이루어질수 있도록 돕기 위한 방법론이다.
즉, 방법론은 무엇을, 어떻게 해야 하는지 가이드를 제시 하기 위한 메뉴얼이다.
가장 대중적인 방법론을 소개하자면 폭포수 방법론과 애자일 방법론이 있다.
- 폭포수 방법론
개발 설계 → 구현 → 테스트 → 유지보수
위의 과정을 순차적으로 진행하고 이전 단계로 돌아가지 않는 것이 특징이다.
각 과정 진행 이해는 용이하지만 수정사항 발생시에 리소스가 많이 들어간다.
- 애자일 방법론
기능을 작게 나눠 구현 -> 테스트 -> 배포 형태로 계속해서 반복
주기적으로 프로토타입을 시험해보는 개발 방법론이라 할 수 있으며 끊임없이 개발하고 수정하는 일을 반복하면서 소비자의 니즈를 가장 만족할 수 있는 방향으로 소프트웨어를 개발한다.
수정사항 발생시에 즉각적으로 대체가 가능하지만 문서화가 힘들다는 특징이 있다.(너무 난잡해질 가능성도..)
참고로 아래의 TDD, DDD들은 애자일 방식 중 하나이다.
2. TDD(Test-driven development)
TDD란 ‘테스트 주도 개발’ 이라고 한다. 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다. 짧은 개발 주기의 반복에 의존하는 개발 프로세스이며 애자일 방법론 중 하나이다.
개발 주기는 다음과 같다.
- 테스트 코드를 먼저 작성한다.
- 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
- 중복 코드 제거 및 일반화 등의 리팩토링을 수행한다.
일반 개발과 다른점은 개발 후 테스트인 일반 개발과 달리 테스트를 먼저 한 후 개발을 한다는 점이 다르다.
이런 TDD의 장점은
- 높은 코드 안정성
테스트 코드 개발-리팩토링 단계를 거치며 끊임 없이 보완하고 종속성과 의존성이 낮은 모듈로 조합된 개발을 가능하게 하여 코드의 안정성을 높일 수 있다.
- 완성도 높은 설계
TDD는 설계 단계에서 테스트 시나리오를 작성하기 때문에 무엇을 해야하는 지 미리 정의할 수 있어 완성도 높은 설계로 이어진다.
- 디버깅 시간의 단축
TDD의 경우 자동화된 단위테스트를 통해 특정 버그를 쉽게 찾을 수 있다.
물론 단점도 존재한다.
- 생산성의 저하가 크다. 매번 코드를 짤때 개발 코드를 두번 이상 반복해야 함으로 개발의 시간 자체가 늘어날 수 밖에 없다.
3. DDD(Domain Driven Design)
DDD란 ‘도메인 주도 설계’로 말 그대로 도메인(문제의 영역)을 중심으로 설계해 나가는 방법이다.
때문에 일반적으로 많이 사용하는 데이터 중심의 접근법이 아닌 순수한 도메인의 모델과 로직에 집중하는것이 핵심이다.
이를 위해 유비쿼터스 등의 보편적인 언어를 사용하고 모두가 이해 가능하도록 문서 및 코드가 동일한 표현 및 단어로 구성된다.
또한 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향한다.
장점.
- 소프트웨어 라이프사이클동안 커뮤니케이션이 원할하다.
- 모듈화/캡슐화 기반으로 유연성 향상된다.
- 현재 상황에 적합한 소프트웨어 개발론이다.
단점.
- 도메인이 중요하다 보니 도메인 전문가 참여가 필수적이다.
- 기존 도메인의 관행을 개선하기 어렵다.
- 기술적으로 복잡한 프로젝트에는 적절하지 않을 수 있다.
4. BDD(Behaviour-Driven Development)
‘행동 주도 개발’로써 TDD에서 파생된 개발 방법론으로 사용자의 행위를 작성하고 결과 검증을 진행하며 BDD로 테스트 코드를 작성함에 따라 설계 역시 행위의 중심이 되는 도메인 기반 설계이다.
개발 주기는 다음과 같다.
- 시나리오 상에서 환경을 정의한다.
- 사용자가 어떤 행위를 하는 것을 정의한다.
- 그에 따른 어떠한 결과를 정의한다.
예시로 다음을 들 수 있다.
사용자가 계산기로 ‘1’과 ’+‘와 ‘1’을 누르고 ’=’ 을 누르면 ‘2’라는 숫 자가 화면에 정상적으로 나오는지를 테스트
그럼 TDD와의 다른점이 뭐냐? TDD는 세부적인 모든 사항들을 테스트한다. 사용자가 계산기에서 ’+‘만 20번 누르는 것도 테스트 하는 것이지만 BDD는 큰 ’=’ 클릭시에 결과가 잘 나오는 가 같은 큰 줄기의 테스트를 진행한다.
즉, TDD와는 별개가 아닌 얽혀있는 개발 방법론이다.(아마 같이 쓰는 경우가 많지 않을까 싶다.)
장점.
- TDD에 비해 테스트 케이스가 줄어들기에 일정관리와 리소스 관리가 용이하다.
- 기획서 요구사항이 곧 테스트 케이스이기에 기획서를 더 중요시하게 되고 기획서에서 놓친 부분에 대한 리스크를 감소시킨다.
5. FDD(Feature Driven Development)
기능 위주 개발 방법론으로 개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발 방법론이다.
특징으로는 여러 개발팀이 있을 경우, 하나의 신규 기능을 개발하기 위해서 전체 팀에서 필요한 내용을 중재하기 위한 프로젝트와 전체 시스템 흐름을 정의할 수 있는 아키텍트의 역할이 필요하게 된다.
생활은 과감한 모험이거나 아니면 아무것도 아니다. –헬렌 켈러(Helen Keller)
Life is either a daring adventure or nothing at all.