[바꿔조/회고] 바꿔조 개발을 마무리 하며

바꿔조를 개발하게 된 이유

 작년 이맘 때 일본으로 첫 해외여행을 다녀왔다. 국내 여행만 다니던 나에게 해외 여행은 큰 흥미를 주었고, 넓은 견문을 가질 수 있게 해주었다. 이 경험으로 나는 더 많은 해외 여행을 다니고자 마음 먹었다.

 

 그러다 문득 내가 만든 앱을 활용해서 해외 여행을 가보면 어떨까? 하는 엉뚱한 발상이 떠올랐다. 이것이 '바꿔조'의 개발 동기가 되었다.

 

앱 소개

📆 개발 기간

24.01.01 ~ 24.01.27 (약 4주)

 

⚽️ 목표

1. 사용자의 개인정보를 수집하지 않는(= 로그인이 필요 없는) 간단한 앱

➡️ 프로젝트를 통해 기본기를 다듬고, Swift에 더 익숙해지는 것이 목표이기 때문에 다른 곳에 투자를 줄였다.

2. 실용적인 앱

➡️ 정말 필요하고 중요한 기능만 앱에 담고자 했다.

3. 복잡하지 않은 직관적인 UI

➡️ 복잡한 UI는 사용자에게 불쾌한 경험을 제공한다. 간단한 앱인만큼 직관적인 UI를 구성하고자 했다.

4. 완성도 있는 앱

➡️ 앱이 자신의 기능을 온전히 제공할 수 있는 완성도 있는 앱을 개발하고자 했다.

5. 앱 스토어 출시

➡️ 앱 스토어에 출시하여 내 앱을 통해 사용자에게 편의를 제공하고 싶었다.

6. 기본에 충실하기

➡️ 가장 중요한 것은 기본기! 기본에 충실하는 것이 가장 큰 목표였다.

 

✅ 적용 기술

UIKit, MVVM Pattern, Delegate Pattern, Singleton Pattern,Snapkit, URLSession, Cocoa Pod, Realm

 

⚙️ 기능

1. 49개 국가의 환율 제공

2. 사칙연산 계산기를 이용한 간단한 환율 계산기 제공

 

배포 및 출시

앱을 출시하기 위해서는 심사 과정을 거쳐야하는데 여간 까다로운 것이 아니다. 나는 앱에서 개인정보를 수집하지도 않고, 다른 앱에 엑세스 하는 것도 없었기에 아카이브할 때 버전 문제 말고는 심사에 있어서 별 다른 문제는 없었다. 

앱을 아카이브 하고나서 문제가 발생 했는데, macOS 버전이 맞지 않다는 것이었다.

앱의 Info에 Minimum system version을 13.3으로 수정하여 해결했다.

 

리젝 없이 심사를 통과하여 성공적으로 앱을 출시할 수 있었다.

 

나의 생각

1. MVVM 패턴에 대한 나의 생각

 

ViewModel

앱을 개발하는 데 있어서 MVVM 패턴을 어떻게 구현할까? 에 대한 고민을 가장 많이 한 것 같다.

MVVM 패턴을 구현하는 방법은 여러 방법이 있지만, "기본에 충실하기"라는 목표를 바탕으로 가장 단순하고 기본적인 방법으로 MVVM 패턴을 구현하고자 했다. ViewModel이 프로퍼티의 변경을 감지하고 이에 대한 반응(액션, 이벤트?)을 수행하도록 구현했다.

 

exchangeRateModel에 어떠한 변경이 생기면 didSet이 이를 감지하여 onUpdated()를 실행하도록 했고, onUpdated()는 클로저로 구현하여 뷰에서 Binding을 하도록 하였다.

 

디자인 패턴은 추상적이고 개발자마다 구현하는 방법이 다르다. MVVM 패턴을 구현하면서 느낀점은 아래와 같다. 

(내 생각인 만큼 정답은 아니라고 생각한다.)

 

✔️ SRP(단일 책임 원칙)

앱을 구성하는 각 구성요소 (Model-View-ViewModel)가 자신들의 역할에 집중함으로써 SRP를 준수한다고 생각한다. 

(ViewModel은 비즈니스 로직과 데이터 관리에 집중하고, View는 UI에 집중)

 

✔️ 데이터 바인딩

Data Binding

프로퍼티 옵저버를 통해 ViewModel의 상태 변경을 자동으로 감지하고, Data Binding을 통해 View와 ViewModel이 서로 상호작용을 한다. Binding 하는 방법은 여러 방법이 있지만 클로저를 통한 Binding을 구현했다. onUpdated 클로저를 통해 View에 업데이트 알림을 보내면 View는 자동으로 업데이트하게 된다. 이러한 방법은 반복적인 코드를 줄이고 UI의 실시간 업데이트를 보장한다. 

 

✔️ 의존성 관리

MVVM 패턴은 의존성 관리에 있어서 느슨한 결합을 지향한다. 

View - ViewModel : View와 ViewModel 간의 상호 작용은 데이터 바인딩을 통해 이루어지는데. 이는 View와 ViewModel 간의 직접적인 의존성을 최소화한다.

 

✔️ 재사용성과 확장성

Calculator View에서 ExchangeViewModel 재사용

위의 코드는 Calculator View에서 ExchangeViewModel을 재사용하는 코드이다. 이와 같이 ViewModel은 여러 View에서 재사용될 수 있다. 또한, 새로운 기능이나 UI를 추가하는데 있어서 구성 요소를 변경하지 않고 확장할 수 있다. 

 

2. 함수명, 변수명을 짓는 것은 상당히 어렵다.

앱을 개발하면서 함수명과 변수명을 짓는 것은 내가 생각했던 그 이상으로 어려웠다. 이름 짓기는 코드의 가독성과 유지보수에 직접적인 영향을 미치기 때문에 신중하게 지어야한다. 

 

바꿔조 프로젝트의 코드 중 일부분인 dataLoad()와 allDataLoad() 메소드이다. 만약 우리 팀원 중 메소드 명을 저렇게 지었다고 가정해보자. 나는 저 함수가 어떤 데이터를 Load하는지 명확히 알 수가 없다. 이러한 사소한 것이 개발의 완성도를 높인다고 생각한다. 

 

나는 1인 개발이기 때문에 이름의 의미와 목적을 나만 알면 됐지라는 생각을 가지고 함수명과 변수명을 신중하게 짓지 않은 것 같다. 이러한 안일한 생각을 가지고 개발하면 안되기 때문에 다시 한번 짚어보고자 한다.

 

✔️ 의미 전달

함수나 변수의 목적이나 역할을 명확하게 전달하지 않으면, 다른 개발자들이 코드를 이해하기 어려워진다. 따라서 이름은 간결하고 명확해야 한다. dataLoad() 보다는 exChangeRateDataLoad()였으면 더 좋지 않았을 까 싶다.

 

✔️ 명명 규칙 일관성 유지

일관된 규칙을 유지하지 않으면, 코드 베이스가 혼란스럽고 유지보수가 어려워진다. 예를 들어 Bool 타입은 is로 시작한다던지, 배열은 arr로 끝난다던지에 대한 규칙을 명확하게 정하는 것이 좋은 방법이라고 생각한다.

 

 

3. 조건문을 이렇게 사용해도 되는가?

바꿔조 앱의 계산 기능을 구현한 메소드이다. 연산자를 입력하는 데 있어서 많은 제약조건 (연산자 뒤에는 .을 입력할 수 없다, . 뒤에 숫자가 아니면 연산자를 입력할 수 없다 등)이 있었기에 이를 구현하기 위해서는 많은 조건을 중첩해서 구현했어야 했다. (더 좋은 방법이 있겠지만 내가 생각해낼 수 있는 최선의 방법이었다.) 

 

내가 구현을 하면서도 이게 맞나? 하는 생각이 들었다.

많은 조건문을 중첩하는 것은 코드의 가독성을 저하시키고, 중첩된 조건문은 올바른 조건을 찾기 어렵게 만들어 논리 오류가 발생할 수 있기 때문인 것을 알면서도 이렇게 구현한 것을 보면 아직 많이 부족하구나 하는 생각이 들었다.