[Chapter02] 설계하면서 트레이드오프를 고민한 사례가 있는지?

[pythonstrup]

• 요즘 새로운 시스템의 설계를 하시는데 옵션 간의 트레이드오프를 고민한 사례가 있으신가요? 궁금해요 @YJGwon

[JisuPark-dev]

이번에 모비닥에서 기존에 쓰던 닥터를 개편하고 있어요. employee라는 인터페이스를 두고 그걸 구현한 doctor, staff...등등이 구현될 것 같은데 구조가 간단해서 그런지 트레이드오프에 대한 고민은 하지 않았던 것 같아요.

[pythonstrup]

@JisuPark-dev 오~ 기대하겠습니다~ 나중에 리뷰 요청해주세요! ㅋㅋㅋ

[YJGwon]

이번 레시피 개발을 하면서는 식재료 - 레시피 - 상품간의 관계를 어떻게 바라봐야 할까..에서 고민을 정말 많이 했어요.

식재료와 레시피의 협력을 설계하면서 레시피가 가진 재료 List를 Wrapper 객체로 감쌌는데요(일급컬렉션이라고도 부르는 형태로요) 사실 이런 wrapper 객체가 하나 추가될 때 마다 코드 양은 늘어나고, 기능은 작게 쪼개지면서 구현에 대한 파악은 어려워지는 셈이죠.. 대신 기능이 작게 쪼개졌다는 것은 책임이 그만큼 잘 나눠졌다는 뜻이고(제가 설계를 잘 했다면요 ㅎㅎ), 구현이 어떻게 되어있는지는 파악하기 힘들지언정 주고받는 메시지를 통해 협력 관계는 더 잘 파악할 수 있게 된 것 같아요.

레시피와 상품 관계는 의존 방향 설정 자체부터 선택해야 했습니다 ㅠㅠ 결국에는 상품이라는 개념이 추상화되어야 하고 "식품" 상품이 그 추상적인 상품의 구현체가 되어 레시피나 영양정보 등등 식품만이 갖고 있는 속성을 가지는게 맞다고 보고 있는데, 현재 시스템은 상품이 식품의 성격을 강하게 띄고 있다보니 당장에 그런 아이디어를 녹이기는 변경 범위가 너무 커질 것 같았어요. 그렇다면 현재의 구조에서 레시피 - 상품은 어떤 관계를 가져야할까? 를 자연스럽게 고민하게 되었죠. 레시피 -> 상품으로 본다면 상품에 관련된 변경을 줄일 수 있을테고, 상품 -> 레시피로 본다면 레시피가 있어야만 이유식 상품이 만들어진다는 기본적인 rule을 직관적으로 녹여낼수 있을테니까요. 결국엔 상품이 레시피를 의존하게 만들었는데, 이유는 현재는 어차피 상품이 식품 성격이 너무 강해서 레시피로 인한 상품 쪽의 코드 변경을 막는다라는 장점이 딱히 크게 유효하지 않을 것 같아서였어요. 상품과 레시피 간의 강결합 문제는 상품을 추상화하고 식품 상품이라는 구체적인 개념을 분리해내서 해결하는게 결국 맞는 방향성일거라는 결론을 내렸었습니다.

매번 새로운 개념을 도입하거나 기존 개념을 확장할 때 마다 과설계와 과의존 사이에서 저울질 하게 되네요!