계층화 설계 1 - 직접 구현과 이어지는 포스트이다.
계층화 설계 패턴 - 추상화 벽
추상화벽은 세부 구현을 감춘 함수로 이루어진 계층이다.
세부 구현을 감추었다는 것은 추상화 벽을 기준으로 ‘how’는 감추고 ‘what’을 명확히 하는 것인것 같다.
책에서는 개발팀과 마케팅팀을 예시로 새로운 기능을 추가해야하는 마케팅팀은 개발팀이 작성한 추상화 벽에있는 명시적인 세부 구현 함수들의 조합으로 기능을 쉽게 구현할 수 있다고 한다.
이 예시는 서버와 클라이언트의 분리와도 굉장히 유사하다. 서버는 api를 제공하고 클라이언트는 해당 api를 사용하여 프로젝트를 진행한다. 클라이언트는 이 데이터가 서버 내에서 어떻게 만들어졌는지 알 필요가 없고, 서버는 이 api의 response를 어떻게 사용하는지 신경쓰지 않는다.
조금 더 프론트엔드 친화적으로 생각해보면 클라이언트 개발을 하면서 만들어져있는 라이브러리를 사용하는것과 같다. 사용자는 ‘what’에 집중하고 구현자는 ‘how’에 집중하여 책임을 명확히 한다.
What 의 특징
- 기획서와 같은 행동 묘사적인 함수이다.
- 데이터 구조를 신경쓰지 않는다.
- 액션의 집합이거나 액션이기에 테스트하기에 어려울 수 있다.
How 의 특징
- 구현과 같은 데이터 계산의 함수이다.
- 데이터 구조를 알아야 한다.
- 테스트하기에 쉬워진다.
추상화 벽 패턴은 만병통치약이 아니다.
추상화 벽을 기준으로 함수의 의존성을 줄일 수 있으며 이는 곧 좋은 설계이다.
하지만 현업 프론트엔드 개발자로 일하면서 데이터 구조가 바뀐적은 드물었다. 프로젝트가 들어가기전 기획서를 참고하여 데이터 구조관련 회의도 진행하였고, 기획이 크게 바뀌지 않는 이상 데이터 구조변경 작업은 드물었기에 일어나지도 않을 일을 미리 대비하는건 오버 엔지니어링일 수 있다.
그러면 언제 사용할까?
- 기능 개발
추상화 벽에 대해 공부하고 이전 개발 경험들로 미루어보았을때에, 어떤 기능을 개발하기 위해서 큰틀로 what을 정의하여 개발 진행 방향을 큰 단락으로 생각할 수 있다. 세부 구현(how)은 큰 단락을 정한 뒤에 해결하면 된다.
- 라이브러리 개발
디자인 시스템이나 사내에서 자주 사용하는 유틸함수를 라이브러리화 할때에 유용하게 사용이 가능하다. 유틸 함수 라이브러리를 개발 후 퍼포먼스 개선이나, 리팩토링등의 작업들도 책임이 명확하게 나뉘어있다면 가능하다.