화면에 종속? 🙅‍♂️ 기능에 맞게 🙆‍♂️

Entered Screen 🙅‍♂️ FilterType 🙆‍♂️

💡 ‘카테고리 개편’ 작업을 하며 4번의 PR 끝에 간신히 Approve를 받았던,,

1. 개요

---

각 진입한 화면별로 카테고리를 다르게 보여줘야하는 기획안이 도착했다.
그 때의 나로서는(물론 지금도 간혹,,) 개발 공수를 너무 얕잡아 본 탓에 시간이 너무나도 촉박했다.(핑계)
생각을 하긴 했지만 시야가 아직 좁아서일 수도 있고,,, 생각을 많이 못해서일 수도 있고위에 쓴 말대로 개발을 하며 진입한 화면별로 카테고리들을 조건에 맞게 필터링해서 띄워줬다.

2. Before

---

CategoryFragment.kt

처음 작업을 할 때는 이렇게 말 그대로 ‘진입한 화면별’로 카테고리를 CategoryFragment에서 카테고리들을 필터링하였다.

당시에는 생각하고 있지 못했지만 의존성이 각 화면에 걸려버린다는 문제점이 있었다.

화면에 의존성이 걸리게 된다면 CategoryFragment 및 ViewModel에서는 Category에 관한 역할만 수행해야 하지만, 각 화면에 대한 정보도 가지고 있어야하고 기획안이 변경된다면 수정도 쉽지 않을 것이다.

이에 대한 내용을 밴이 리뷰해주시며 한 말씀을 적어보자면,

카테고리라는 레스토랑에서 음식을 팔고있는데 방문한 손님의 출생지역에 따른 요리를 해주는것보단, 손님이 원하는 형태의 요리를 해주는게 낫지 않나요?
손님의 출생지라는 의존성이 걸려버리면 그손님은 사실 다른요리가 먹고싶은데 그 의존성때문에 출생지역에 따른 음식을 먹어야 하는것이잖아요?
단순하게 손님이 원하는 형태를 전달하면 레스토랑의 요리사는 그 오더에 맞는 음식을 하면 될것이고 그 손님이 어디출신인지는 사실 알필요가 없게되니깐요.

당시에는 솔직히 내가 개발한 의도가 분명했기에 이해가 안 가는 부분도 있었고 한 번에 납득하기는 쉽지는 않았지만, 밴이 위처럼 쉽게 풀어서 설명해주셨고 납득이 가며 점차 길이 보이기 시작했다. 🙇‍♂️

3. After

---

그래서 다음과 같이 수정을 했다.

CategoryFragment.kt

CategoryFragment 에서는 단순히 ViewModel의 데이터를 observing하다가 categoryAdatper에서 렌더링하기 위해 데이터를 넘겨주는 역할만을 한다.

그러면 각 화면에 맞는 필터링은 어디서할까?
데이터 처리에 관한 일이므로 ViewModel에서 수행을 한다.

CategoryViewModel.kt

각 화면에서 enteredScreen처럼 자신의 화면 정보를 보내주는 것이 아닌 자신이 먹고 싶은 음식 즉, 필터 타입만 전달하고 그 정보(요리 메뉴)를 CategoryViewModel에서 받아서 누구인지는 모르지만 오로지 주문한 정보에 맞게만 필터링(요리)을 해준다.

4. 배운 점

---

다음에도 비슷한 상황이 온다면 ‘화면’에 종속하기보다는 ‘기능’에 초점을 두어 개발을 해야겠다. 그로인해 유연성과 확장성도 함께 가져올 수도 있다는 것을 체감하였고, 당연한 것이겠지만 의도가 분명한 개발을 하는 것이 정말 좋다고 느꼈다.

혹여나 그것이 틀린 혹은 덜 좋은 의도라고 하더라도 리뷰를 받으며 내 의도와는 다른 의견을 들으며 ‘직접’ 비교해볼 수 있어서 내 코드의 내 의도의 문제점을 체감하기 수월했던 것 같다.