이 프로젝트를 선택한 이유

프로젝트: https://github.com/minnnidev/Wote.git

• 현재 진행하고 있는 팀 프로젝트가 있기 때문에, 혹시나 피해가 가지 않기 위해 개인 프로젝트로 진행하려고 했다.
• 기존 앱 리팩토링, 새로운 앱 개발하기 선택지가 있었는데 전자를 선택하게 되었다. 이유는
  • 서버가 아직 살아있고, API 개발이 모두 완료되어 있다.
  • 커뮤니티 앱이고, 내가 했던 프로젝트 중 규모가 가장 크다.
  • 해당 팀 프로젝트가 끝나고 나서 개발적인 부분에서 아쉬움이 많이 컸다.
  • 등등… 이유는 많았다!
  • 한마디로 요약하자면, 고칠 수 있는 부분이 가장 많아서 학습이 가장 잘 될 것 같았다.

어떤 것을 중점으로 리팩토링할 것인가

1학기 동안은 캡스톤(딥러닝 웹서비스 프로젝트)을 진행하느라,

iOS 개발 대신 기본기와 이론을 많이 다졌고, 거기서 내가 학습했던 것 + 평소에 고민했던 것 위주로 해 보려고 한다.

일단 이 앱을 처음 개발할 때는, 핑계 같을 수도 있지만 팀원 모두가 기획에 참여하였기에 생각했던 것보다 기획 기간이 너무 늦어져, 개발 기간이 거의 한달 정도 됐던 것 같다.

사실상 SwiftUI도 많이 익숙하지 않을 때여서, 일단 굴러가게만 만들자를 목표로 했던 것 같다.

SwiftUI에 대한 기본 지식이 있었다면, 설계부터 해야지! 라는 생각을 할 수 있었을 텐데… 아쉽다.

아무튼 그래서, 후에 추가될 수도 있지만 일단 중점적으로 할 것들을 정리했다.

1. DTO & Model의 분리

• 사실 이 앱은 DTO와 Model이 거의 일치하지만, 조금 번거롭더라도 둘을 분리해 주는 것이 계층 분리, 아키텍처적인 측면에서도 명확할 것 같았다.

2. MVVM 구조

• 그동안 공부하면서 MVVM의 역할을 많이 고민했고, View에 보여줄 데이터를 가공하는 곳으로 내 나름대로 정의했다. 아직 Action 같은 것에 대한 고민이 남아 있긴 하지만…
• 관련 이야기는 8번에서 더 진행할 예정이다

3. Authentication 파트

• 거의 뷰와 API(인증 제외) 부분을 맡아서 Authentication 파트에 대해 100% 알지 못한다.
• 팀원들의 코드를 기반으로 리팩토링을 진행할 것이지만, authentication만큼은 다시 혼자 작업해 보려 한다.

4. Moya를 알고 쓰기

• Moya? 그거 많이 쓴대 우리도 쓰자 하면서 그냥 썼다.
• 편리함은 당연히 느꼈지만, 정확하게 알고 써야 하는 라이브러리라고 생각한다.

5. Combine도 알고 쓰기

• 웃긴 이야기긴 하지만, 초반에는 Swift Concurrency를 썼고, 후에는 Combine으로 한 명이 쓰기 시작하여 갑자기 Combine이 됐다. 아직 Swift Concurrency로 작성된 코드는 여전히 남아있다.
• 그러다 보니 Combine을 잘 알지 못하는 상태에서 기계처럼 sink만 따라 작성하기 시작했다.
• Combine을 이해하고, 리팩토링해 보려고 한다.
  • RxSwift도 학습해 나가고 있으니, 그때보단 이해가 쉽지 않을까?!

6. 화면 전환

• 우리는 테스트를 하지 않으면 접근할 수 없는 서비스 범위와 딥링크 기능이 존재한다.
• 이를 위한 NavigationStack의 Path관리 부분도 리팩토링할 예정이다.

7. 에러 처리

• 8번에 나올 것이지만, 레이어를 분리하면서 그에 맞는 에러를 부여하고 핸들링을 하고 싶다.

8. 마지막으로 아키텍처 설계

• 문제점

  • 레이어 분리 없음
  • ViewModel에서 API request & response 모두 처리
  • protocol 추상화 없음
  • 나름의 의존성 주입을 도전했지만, protocol 없이 진행하였으므로 진짜 just 의존성 주입….
    • 의존성 주입이라는 개념을 공부하고 보니 그렇더라…..

• 리팩토링

  • 일단 protocol 없이 모두 구현했으므로 시작부터가 난관이긴 하다
  • Clean Architecture 기반 레이어 분리
    • 어떻게 나누는 것이 좋을까까지는 아직 고려하기 힘들어, 보편화된 아키텍처를 적용해 보려고 한다.
    
  • 의존성 주입을 도울 Swinject
    • 의존성 주입을 돕는 라이브러리를 사용하여 AppDependency 객체에 객체를 register하고, 필요한 곳에서 resolve할 것이다.
    • DI에 대해 이해는 했는데, 그래서 어디서 생성해야 알맞을까? 라는 고민을 Container 기반 라이브러리를 사용함으로써 해결할 수 있을 것 같다.
    • Swinject으로 미리 설계해 본 깃헙 링크
      iOS-Playground/Swinject-Sample at main · minnnidev/iOS-Playground

• 이러한 구조를 사용하여, SwiftUI에서 제공하는 Preview도 모두 볼 수 있도록 작업할 것이다.
  기존에는 객체를 가져오는 게 어려우면 그냥 preview를 삭제했는데, preview를 통한 작업도 중요하다는 것을 알게 되었다.

어떤 방식으로 진행할 것인가

• 기존 레포에서 refactoring branch 따서
  • 사실 뭐 새로 레포를 파서 해 볼까도 했으나, 뭐가 문제인지 부딪히면서 알아가봐야 여러 시행착오를 겪을 수 있을 것 같아서, 그대로 도전해 보기로 했다. 덕분에 앞서 언급한 것처럼 삽 뜨는 데 오래 걸릴 것 같긴 하다 ㄱ-
• 기간
  • 7월에도 발표회나 여러가지 일정이 있어서 일단 최대 한달로 잡았다!
• 기록하기
  • 코드 한 줄 못 썼더라도, 고민한 날에는 이렇게 포스팅을 최대한 남겨두려고 한다. 미래의 내가 똑같은 고민을 할 수도 있으니…