[iOS] 모듈화를 해야 하는 이유

 

개발을 하면서 왜 모듈화를 해야 하는지에 대한 개인적인 이유입니다.

다른 의견 있으시면 댓글 달아주시면 감사하겠습니다! 🙇🏻‍♂️🙇🏻

 

---

 

캡슐화

---

먼저 캡슐화에 대한 이야기를 하려고 합니다.

2023.08.13 - [객체지향프로그래밍] - [OOP] 객체지향프로그래밍 기초

[OOP] 객체지향프로그래밍 기초

캡슐화에 대한 자세한 내용은 위에 링크를 참조해 주세요.

 

모듈 수준에서도 캡슐화가 진행되어야 한다고 생각합니다.

만약 진행하지 않는다면 외부에서 마음대로 접근할 수 있겠죠.

특정 ViewController, ViewModel, UseCase 등 마음대로 생성할 수 있고 설정 값을 변경할 수 있겠죠.

 

 

기능을 다 쓰지 않고 있다.

---

모듈로 나누지 않는다면 주어진 기능을 다 사용하지 않는 것입니다.

Swift에서는 open, public, internal, fileprivate, private 이렇게 5개의 접근 제어자를 제공합니다.

모듈로 나누지 않는다면 open과 public을 버리고 있는 거죠.

 

 

모듈화 안하면 기능 제대로 안쓰고 있는 것

 

 

단일 책임 원칙

---

MVC 아키텍처의 단점이 ViewController가 많은 기능을 담당하는 것입니다.

저희는 이것을 비즈니스 로직을 처리하는 ViewModel을 만들어 역할을 분리했습니다.

모듈 또한 마찬가지입니다.

필요한 역할을 할 수 있도록 나눠야 합니다.

UIKit, SwiftUI 등 여러 모듈이 하나에 모여있다면 굉장히 무겁고 개발하기도 어려울 것입니다.

 

MVC & MVVM

 

Single/Multi Module

 

 

독립적으로 만들 수 있다.

---

만약 모듈화를 진행했다면 인터페이스/구현체 구조로 나누어 느슨하게 연결하여 모듈에서도 의존성 역전 원칙을 지킬 수 있습니다.

• 모듈에 데모앱을 적용할 수 있게 된다.
• 온전히 자신의 기능 개발을 할 수 있는 환경이 제공되므로 빠른 개발이 가능하다.
• 버그가 발생했을 때 무엇이 문제인지 파악하기 쉬워진다.

실제로 프로젝트를 진행하며 팀원들 모두 동일하게 겪었습니다.

그러나 이에 대한 단점도 존재했는데 하단에 서술하도록 하겠습니다.

 

독립적으로 만들어진 상황에서 개발했을 때 느낀 점

기능이 모두 독립적으로 만들어진 상황에서 개발했을 때 경험은 매우 좋았습니다.

다른 부분을 크게 신경 쓰지 않고 나만 잘하면 되는 상황이므로 속도는 매우 빨랐습니다.

그러나 이러한 상황 때문에 느낀 점이 몇몇 있습니다.

 

1. 이해도 차이가 굉장히 심해진다.

독립적이라 내가 개발한 기능 외에는 이해도가 현저히 떨어집니다.

이로 인해 추후 유지보수할 때 내 기능을 제외하고는 건드리기 어려워집니다.

이를 해결하기 위해 2가지 방법을 사용했습니다.

• 코드 리뷰를 꼼꼼하게 한다.
• 자주 서로 개발하던 기능을 바꾼다.

먼저 코드 리뷰를 꼼꼼하게 하는 것만으로는 해결이 불가능했습니다.

기능 개발이 바빠 꼼꼼하게 하는 것도 어려웠지만 꼼꼼하게 하더라도 이해도 차이가 있을 수밖에 없었습니다.

다음으로 서로 개발하던 기능을 자주 바꾸는 것인데요.

이를 통해 미처 빼먹고 갔던 부분도 파악하고 코드 리뷰를 하면서 왜 이런 식으로 개발했는 지 이해가 안 갔던 부분에 대한 히스토리를 직접 경험을 통해 이해가 되는 등 해당 문제는 해결이 되었습니다.

 

그러나 이 방식을 사용하며 개발 속도가 많이 줄어드는 단점이 존재하긴 했습니다.

 

2. 옳게 성장하고 있는 것인가에 대한 의구심

독립적으로 진행하니 사실상 특정 모듈만 공유하는 반쪽짜리 협업이 되었습니다.

서비스를 만드는 입장에서는 굉장히 빠르게 개발이 가능하므로 많은 장점이 존재했습니다.

그러나 배우는 입장에서는 아쉬운 부분이 부분이 많았습니다.

단순히 각 모듈별 연결하기, 공용으로 사용하는 모듈 제작하기 등 많지 않은 부분만 연관되었습니다.

즉, 각 모듈이 인터페이스로 느슨하게 연결된 것처럼 개발자끼리도 느슨하게 연결이 되었습니다.

물론 1번에서 작성한 방법으로 이해도 간격은 줄일 수 있었지만 팀과의 의사결정 방식 등 여러 부분에서는 아쉬운 부분이 많았습니다.

이를 해결할 수 있는 방법이 무엇이 있나 고민해봤습니다.

• 페어 프로그래밍을 진행한다.
• 자주 상황 공유를 진행한다.

페어 프로그래밍을 진행해 봤는데 꽤 좋았습니다.

많은 부분에서 비슷한 의사 결정을 하게 되었지만 그렇지 않은 부분도 많았습니다.

그럼 과연 얼마나 페어 프로그래밍을 진행을 해야 하는가에 대한 고민도 생겼습니다.

 

자주 상황 공유를 진행해봤는데 사람에 따라 불필요하다는 의견이 있어 오래가지 못했습니다.

꽤나 길어지는 경우도 있었기 때문입니다.

 

해당 경우는 결국 성장 중심으로 느꼈던 것이라 일할 때는 크게 반영되지 않는 부분 같습니다.