안녕하세요. 이번에 회사에서 제가 주도적으로 모듈화를 담당하게 되었습니다. 기존의 코드의 어떤 부분을 어떻게 모듈화를 했는지 포스팅으로 정리해보도록 하겠습니다
모듈화 이전 상황
저희 회사는 새로 시작하는 모든 프로젝트에 SwiftUI와 Combine (혹은 async/await)를 도입해서 활용하고 있습니다. 제가 처음에 입사했을 때는 SwiftUI를 사용하는 프로젝트가 단 하나 밖에 없었는데요. 어느덧 1년 이상이 지나고 SwiftUI를 활용하는 제품이 3개로 늘어났고 모든 제품에서 반복되는 동일한 코드들이 발생하기 시작했습니다.
처음에는 이 코드들을 하나의 별도의 프로젝트 파일로 만들어서 깃허브 레포에 저장해두고 공유를 했는데요. (복붙을 통해서…) 이 방법이 처음에는 별 문제가 없었는데 공유하는 코드가 복잡해지고 수정이 잦아지면서 문제가 발생하기 시작했습니다.
문제점
- 일단 복붙을 사용한다는 것에서 문제가 발생했습니다. 처음에 프로젝트를 만들때 하나하나 파일을 복사하는 것은 상당히 번거로운 작업이었고 개발자 답지 않은(?) 방법이었습니다.
- 또한 공유하는 코드에 새로운 코드가 추가되면 새로 깃허브에서 복사를 해와야 했고 더 심각한 것은 공유하는 코드가 어디까지 업데이트 되었는지 파악할 방법이 없다는 것이었습니다.
- 공유하는 코드에 버그가 발생하면 그 버그를 수정하기 위해서 3개의 모든 프로젝트를 수정해야한다는 점도 문제 였습니다. 또한 버그가 공유하는 코드에서 일어난 것인지 아니면 세부 프로젝트의 코드 때문인지 파악하는 것도 어려웠습니다.
이 외에도 수많은 문제가 발생을 했는데요. 이 때문에 저는 회사에 모듈화를 통해 패키지로 만들자고 건의했고 시니어 개발자 분이 받아들여 개발을 시작했습니다.
예상 되는 장점
복붙에서의 탈출
복붙을 하면서 약간의 자괴감(?)이 들기도 했는데요. 모듈화 및 패키지화를 통해서 새로 업데이트된 코드를 도입하는 것이 훨씬 쾌적해질 것입니다.
버전 관리 용이
패키지에 버전을 관리하게 되면 새로운 공유 코드를 어디까지 업데이트 했는지 알 수 있습니다. 그리고 어떤 코드를 업데이트 했는지도 쉽게 알 수 있습니다.
그리고 새로운 버전에서 문제가 생겼을 때는 문제가 해결될 때까지 이전의 코드로 돌아갈 수도 있습니다.
프로덕트와 별도의 테스트
Swift Package를 만들면 기본적으로 Test를 위한 코드가 포함이 되어 있습니다. 즉 Package를 위한 테스트만 별도로 만들 수 있다는 것입니다. 이 테스트를 통해서 신뢰성 있는 패키지를 만들 수 있습니다.
앞으로 계획
먼저 3개의 프로젝트에 쓰이는 공통적인 코드를 파악하고 하나의 패키지로 묶어낼 생각입니다. 그리고 해당 코드 중에서 public으로 공개해야 하는 것과 private으로 숨겨도 되는 것 등을 분리해서 최소한의 패키지를 만들도록 할 예정입니다. 앞으로 포스팅을 통해서 이 과정을 소개해보도록 하겠습니다.
