클린아키텍처 듣기 전부터 고민하던 내용들

적용에 앞서 많은 고민중

  • 고민은 좋은거.

1. MVP등의 각종 패턴은 정말 만능일까? 의문점들

  • 장점은 매우 많습니다. 개발자가 많고 교육 시간이 많으면 하는게 좋습니다. 테스트하기에 좋다.
  • 의문점들
    • 요즘 유행하는 MVP 패턴을 적용해 보려고 공부중 이지만 유지보수가 정말 편해 질까?
    • MVP를 정말 열심히 해서 잘 적용하면 다른 사람들이 잘 알아 볼 수 있을까?
    • 만약 회사에 신입이 오면 코드가 잘 보고 비슷한 패턴으로 추가를 해줄까?
    • 정말 유지 보수가 쉬울까?
  • 패턴을 적용하면 우선 많은 파일들이 생김
    • 패키지 관리를 어떻게 해야 할까? ‘M’ 끼리 ‘V’ 끼리 ‘P’ 끼리
    • 액티비티는 뷰에 넣어야 하나?
  • 패턴을 적용하면 거의 대부분이 DI라이브러를 추가하기 시작 함(dagger 등)
    • 컴파일단계에서 추가되어서 기본 구조를 모르면 약간 많이 어색함
    • 스프링을 공부 했던 사람은 매우 편하다고 함
    • C 를 기반으로 하는 저 같은 사람에게는 너무 어색함
  • 지금 만드는 코드들을 보면 액티비티에 다 넣는다. 앱을 만들면서 아래 내용 말고는 없는거 같다. 앱 자체에 알고리즘이라고 할 만한 내용이 없다. 거의 모든일이 서버 의존적이다.
    • 뷰 초기화(현재는 구글의 데이터 바인딩을 사용해서 안함)
    • 뷰 이벤트 등록
    • http 리스너 등록
  • 서버개발자가 있어서 그럴수도 있지만 사내에 막강한 서버개발자가 있고 기본 구성이 서버1명 +앱1명 이라고 가정하고 앱을 만드는 경우를 가정하자. (매우 개인적인 생각들)

    • 회원 가입 시나리오 및 추가내용
      • 앱 : 아이디 비밀번호를 서버에 전송
      • 서버 : 아이디 비밀번호 저장, 토큰 발급
      • 앱 : 토큰으로 API 접근
      • 간단하게 회원 가입가능하게 만들었다.
      • 사업팀에서 요청 사항이 생겼다.
        • 카카오톡 회원 가입을 추가해 주세요.
        • 소셜로그인 기능도 결국 소셜의 아이디값을 콜백으로 받아서 이를 회원 가입 시나리오에 추가함, 비밀번호가 없음
      • 매우 간단한 내용이고 다른일들이 발생해도 추가 하기 쉬운 일들이라고 생각한다.
      • xml 에 아이디 비밀번호 입력란이 있고 회원 가입 버튼만 있으면 된다.
      • 카카오톡 버튼이 추가가 필요하면 카카오 sdk 호출이 하여 아이디를 받을수 있는 리스너를 등록한다.
        • 성공 리스너에서 자사 회원 가입 API를 호출한다.
      • 회원 가입을 시나리오를 가정해 보았고 추가되는 사항도 만들어 보았다.
      • 액티비티에 기본적인 클래스 분리와 함수 분리만 하였을때에도 변경 되는 로직에 큰무리 없이 쉽게 추가가 가능하다.
      • MVP 패턴을 적용하려면 정확히 지킬건 지켜주고 싶다.
        • 기존 포스트 내용들 처럼 액티비티에 뷰 와 프리젠터 파일 만들어 주고 액티비티와 연결해주고 각종 이벤트들을 연결해 준다.
        • 카카오 버튼이 하나 추가되어도 뷰와 프리젠터에 추가해서(어렵지는 않다.)
        • 카카오 SDK api를 이용해서 리스너 등록하고 결과를 처리하고
        • 프리젠터 임플리먼트에서 결과를 받아서 뷰 함수를 호출하여 화면 업데이트 하고 …
      • 위와 같은 상황이 거의 대부분 구성이었다. 앱에서 비지니스로직,모델 이라고 할 내용이 거의 없다.

      • 통신 요청하고 결과를 화면에 보여준다. 이게 거의 대부분의 앱의 구성이었다.
      • 이렇다 보니 왜 mvp 를 써서 코드가 복잡해 보이게 하는지 잘 이해가 되지 않는다.
      • 유닛테스트를 만들기 쉽다.
        • 위 내용중 유닛 테스트는 어떤게 있을까를 생각해 보자
        • 어떤게 나올까요 애매한 상황이라고 생각합니다.
        • 왜냐면 내용이 없습니다.
        • 그래도 뭔가 하고 싶어서..
          • 유닛테스트를 하는데 통신 API에 잘못된 값들만 넣어서 결과를 확인한다.
            • 통신 테스트는 별개로 서버와 함께 하는게 좋을거 같은 생각, 내가 만든 기능테스트라고 하기에는 어려워 보임
          • 결과로 받은 내용이 화면에 나오는 부분을 확인한다.
        • mvp 패턴보다는 차라리 리액트개념을 넣어보자는게 나을거 같다.
        • rx로만 앱을 구성하면 한눈에 보기좋고 수정들이 훨씬더 좋으니깐
        • 등등 하기싫은 이유들..
  • 의문점이 생기는 이유는 하기 싫어서 핑계를 찾는거 같다.
  • mvp 와 같은 패턴이 생기는 이유를 생각해 보았습니다.
    • UI 쪽과 그이외의 기능을 분리하고 UI와 기능의 연결을 단일 통로로 해결하자
    • 이게 핵심이라고 판단 하고 있습니다.
    • mvc, mvvc, mvp 등등을 만들어서 패턴을 만들어 보는 이유는 조금더 규격화 해보는게 아닌지 생각합니다.
    • 여기서부터 또 다른의문점이 생기기 시작 했습니다.
    • 저렇게 화면에 보이는 부분만 따로 만들면 자바가 동작 하는 여러 플랫폼에서 동작 해야 하는거 아닐까?
    • 절대 안되죠 왜냐면 화면에 보이는 부분은 분리했지만 안드로이드 플랫폼 안에서 구분이니깐요
    • 그래서 이런 저런 생각하던중 클린아키텍처를 보고 기본부터 다시 생각하기 시작함
    • 드로이드나이츠의 클린아키텍처 세션을듣고 클린아키텍처 먼저 적용이 필요하다고 생각함

PyeongHo

즐겁게 또 즐겁게