개발 방법론의 필요성
대규모 비즈니스 시스템 구축 시 체계적인 공정 및 기법을 제공함으로써, 양질의 정보 시스템 구축을 가능하게 하고 개발 생산성 향상 및 개발 노하우의 축적의 기반이 된다.
- 좀 더 대규모 서비스를 경험해 보고 싶었던 터라 기초부터 다시 배워나간다는 생각으로 방법론 스터디를 하게되었다.
TDD,BDD,DDD 세 가지의 방법론 중 장단점을 비교해 보고 스터디 할 방법론을 선택하기로 했다.
✔️TDD vs BDD vs DDD
TDD : Test-Driven Development
개발 과정에서 테스트를 중심으로 코드를 작성하는 방법론.
테스트 케이스를 작성 후 해당 테스트를 실패/통과 하는 코드를 작성하여 기능을 추가할 때마다 테스트를 실행한다.
코드의 안정성과 동작 여부 검증.
개별 함수나 메서드의 동작 중심으로 테스트.
>>실패하는 테스트 케이스를 먼저 작성한 후 개발 진행!
-
장점 : 디버깅 시간 단축, 재설계 시간 단축, 추가 구현의 용의함, 튼튼한 객체 지향적인 코드 생산.
-
단점 : 생산성 저하.
BDD : Behavior-Driven Development
TDD를 기반으로 한, 개발 프로세스에 사용자의 행위와 시나리오를 중심으로 한 개발 방법론.
비즈니스 요구사항에 집중하여 테스트 케이스를 개발한다.
TDD를 결합해 시나리오 테스트까지 하는 것.
>>Given-When-Then 형태로 표현
- 장점 : 한 개의 feature에 여러 개의 다양한 시나리오가 나올 수 있다.
- 단점 : 사용자 행동에 대한 정확한 이해 필요.
DDD : Domain-Driven Development
도메인 영역을 중심으로 설계하는 개발 방법론.
보편적인 언어의 사용을 추구하며 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나간다.
- 장점 : 비즈니스 도메인에 집중 / 의사소통과 협업의 강화 / 유연하고 확장 가능한 설계
- 단점 : 초기 비용과 시간 / 팀 구성과 조직적인 도입 난이도 / 새로운 개념과 용어를 이해하고 적용하는데 시간 걸릴 수 있음.
👉🏻TDD vs BDD vs DDD 어떤걸로 공부할건데!?
나의 선택은 TDD였다.
1. 세가지 방법론 중 가장 익숙한 단어였다.
2. 공부하는 단계이므로 리소스와는 상관없이 차근차근 밟아나간다는 생각으로 하는게 중요하다고 생각했다.
3. 당장 협업이 아니라 스터디 목적이므로 이해관계자가 필요없다.
Reference
