작성
·
10
1
강의를 들으며 제일 강조하시는게 "요구사항 충족" 이라고 생각했습니다.
처음부터 아키텍처를 정해놓지 않은 상태로 요구사항 충족을 목표로 달리는 형태로 설명해주셔서 TDD의 의미나 철학을 이해하는데 도움은 많이 됐습니다!
궁금한 것은 현업에서도 새로운 프로젝트를 시작할때 이와 같은 방식으로, 아키텍처를 특별히 정해놓지 않고 개발하는것이 일반적인가요?
테스트 표면을 통해 아키텍처를 유연하게 변경 가능하다고 하신 말씀도 이해를 했는데
서비스 기획 및 설계 단계에서 서비스의 성격/특성에 맞추어 아키텍처정도는 어느정도 정하고 가는것도 괜찮지 않을까 생각하여 여쭤봅니다!!
답변 1
0
다익스트라님 안녕하세요. 강의 수강해 주시고 질문도 남겨 주셔서 정말 고맙습니다. 🙂
저는 말씀하신 것처럼 요구사항 충족을 가장 중요하게 생각합니다. 하지만 아키텍처가 중요하지 않다는 뜻은 아닙니다. 다만 저는 고수준 아키텍처와 공개된 모듈 간 인터페이스는 가능한 상세하게 설계하지만 그 내부의 아키텍처는 미리 설계하거나 에너지를 많이 쏟지 않습니다.
그러면 어느 수준에서 공개된 모듈을 정의할 것인가가 남게되는데 이건 각 프로젝트 상황에 따라 많이 달라지며 저는 분명한 필요가 없다면 공개(public) 모듈을 가급적 만들지 않습니다. 그렇게 해야 설계가 유연하게 관리되고 변경 비용이 감소하기 때문입니다.