FDA(Feature Driven Architecture) - FSD의 기원

TDD(Test-Driven ~), DDD(Domain-Driven) 등 Driven이 포함된 방법론은 ~~주도 설계로 번역됩니다. TDD는 테스트 주도 개발, DDD는 도메인 주도 설계를 뜻합니다.

https://www.youtube.com/watch?v=BWAeYuWFHhs

FDA는 2018년 React Day Berlin에서 발표된 내용입니다. 해당 발표에서 발표자는 6개의 해결하고자 하는 목표를 제시하게되고, 이를 기반으로 FSD의 형태가 구체화 됩니다.

6가지 목표

발견 가능성(Discoverability)

큰 규모의 프로젝트에 신규 투입되는 상황을 떠올려봅시다. 버튼 하나를 수정하려고 해도 컴포넌트간의 의존성이나 구조에 대한 파악이 되지 않으면 어려움을 겪게된 경험이 있을 겁니다. 심지어 필자는 이전에 작성한 코드를 다시 살펴볼 때에도 이런 경험이 있는데 이는 코드 맥락파악을 떨어뜨려 유지보수 비용을 증가시키고 생산성을 저하합니다. 또 전체 구조가 파악되지 않은 채로 변경하게 되면 다양한 오류 발생할 위험에 처하게 됩니다.

목표1: 발견 가능성 증대

병행 작업(Work parallelisation)

큰 규모의 프로젝트는 보통 혼자서 개발하지 않고 많은 사람들과 병행해서 개발하게 됩니다. 그러면서 자연스레 공통되게 사용하는 함수나 기능에 대해서 충돌이 일어날 수 밖에 없습니다. 이는 통합 문제와 일관성이 부족한 코드 등으로 이어질 수 있고 결국 생산성을 떨어뜨립니다.

목표2: 병행 작업 효율화

공통 추상화 제어(Controlling shared abstractions)

“공통으로 추상화된 기능”을 어떻게 제어할 것이냐에 대한 고민입니다. 코드 전방위적으로 참조되고 사용되므로 구성원이 어떻게 다루어야 할 지에 대한 방법론이 제시되어야 합니다. 이러한 고민 없이 반영된 공통 추상화는 프로젝트 전체에 과한 영향력을 행사하여 예상치 못한 문제를 낳을 수 있습니다.

목표3: 공통 추상화 제어