앞으로 더 생각해봐야 할 것들
열심히 고민해서 첫 비즈니스 로직 분리를 했으나, 솔직히 말해서 잘 분리된 코드인지는 모르겠다. 처음이니 당연히 잘 분리되어있지 않을 것이라 생각한다. 아직 실력이 부족해서 어디가 잘못되었고 어떻게 고쳐야 할 지 모를 뿐. (일단 이런 고민을 시작했고 어떤 형태로든 해낸 것에 대해서는 나 자신의 머리를 한번 쓰다듬어주고!) 이후로는 코드를 어떻게 더 발전시켜야 할 지 고려해야 할 것들을 적으며 글을 마무리해보려 한다.
1. MVVM 패턴이 프론트엔드 코드에서 비즈니스 로직을 분리하는 데 적합한 패턴인가?
이 부분에 대해서는 이전에도 글을 적은 적이 있고, 꾸준히 고민해왔던 문제다. 객체 지향 프로그래밍도 좋고, 비즈니스 로직을 분리하는 것도 좋은데, 최선의 방법이 MVVM 패턴인가? 코드를 작성하면서 너무 어려웠기 때문이다. Api 하나를 불러오는데도 여러 함수와 클래스가 엮이다보니 비동기 작업을 하는 것도 힘들었고, 상황이 바뀔때마다 익숙치않은 방법으로 코드를 짜느라 시간이 더 오래 걸렸다. 이게 내 실력이 부족한걸 감안하더라도, 꼭 필요하지 않은데 MVVM을 사용해서 간단하게 작성할 수 있는 코드를 복잡하게 돌아가게 한 건 아닌지 헷갈렸다. 이 부분에 대해서는 아직 지식과 경험이 너무 부족하기 때문에 어떤 부분이 문제가 되는지조차 알 수가 없다. 코딩을 계속 하면서 직접 어려움에 부딪히고, 그 어려움에 대한 해결방법을 찾으며 배우는수밖에 없다.
2. ViewModel은 function component로 작성되어야 하는가, class로 작성되어야하는가?
이번에는 ViewModel을 function component로 작성했지만, 작성 이후 여러 부분들이 찜찜하게 남아있다. MVVM 패턴을 적용하고 나면 ViewModel과 Model은 View 없이도 테스트를 진행할 수 있고, 이 테스트가 더욱 쉬워진다고 들었다. 하지만 Model은 테스트가 쉬웠지만 ViewModel은 useState같은 리액트 훅 때문에 테스트를 진행하기가 마냥 쉽지만은 않았다. 그리고 훅을 사용하기 위해 리액트 엘리먼트를 반환하지도 않는데 컴포넌트를 사용하는 것이 맞는건가 싶기도 했다. 다음에 연습용 프로젝트를 하나 만들어서 클래스 ViewModel을 사용하는 MVVM 패턴을 적용해봐야겠다.
3. Api는 어디서 불러야 하는가?
Api는 Model보다는 ViewModel에서 부르는게 맞는것 같다. Model은 비즈니스 로직을 다루는 객체로, 다른것에 의존해서는 안되기 때문이다. 그런데 ViewModel에서 부르더라도 지금처럼 단순하게 함수로 만들어서 api 요청을 보내는게 충분한지, 아니면 api 요청을 담당하는 Repository 객체를 따로 만들어야 하는지는 잘 모르겠다. Repository 객체에 대해서 더 공부해봐야겠다.
4. 뷰로직은 어디에 포함되어야 하는가?
화면에서 어떤 조건이 충족되면 모달을 보여주거나, 데이터를 특정 포맷으로 변형하여 보여주는 것은 뷰로직에 포함된다. 뷰로직은 UI와 관련이 있지만, 위에 작성했던 예시처럼 함수로 작성될 수도 있고 그 수가 많아지면 컴포넌트가 복잡해질 수도 있다. 복잡하지 않아도 뷰로직은 뷰로부터 분리해야 할지, 코드가 길어질때만 분리할지. 분리를 하게 된다면 ViewController 객체를 만들지, 그냥 ViewModel에 포함시킬지. 직접 코드를 작성하며 느낀것은, 작은 프로젝트라면 굳이 분리를 하지 않아도 될 것 같고 프로젝트가 커지면 뷰로직도 따로 분리하는 게 나을 것 같다는 것이었다. 그 크기가 어느정도여야 될지는 역시 경험이 필요할 것 같다.
글을 마무리하며
클린 아키텍처라는 책을 처음 읽었을 때 내용을 하나도 못알아들었는데, 언젠가 그 내용이 이해가 가는 날이 왔으면 좋겠다. 아키텍처는 계속 고민하겠지만 짧은 시간 내에 답이 나올 것들은 아니니까 경험을 쌓아가면서 다른 것을 공부해보려고 한다. 이 다음에는 클린 코드에 대해 고민해보고 싶다. 마침 클린 코드 책을 빌려왔다. 숲을 공부해봤으니 다음은 나무를 봐보는것으로 하자 😚
