MoCoDot 프로젝트 회고록

준우·2024년 4월 7일
0

Swift 이야기

목록 보기
14/19
post-thumbnail
안녕하세요 :) 모스코드 변환 어플 1차 개발을 한지 2주 정도가 되어 중간 점검도 할 겸? 글을 쓰게 되었습니다.

현재 1차 중간점검까지 나온 작업물들입니다.

  • 소리 재생
  • 진동 작동
  • 플래시 작동 등등

기능들이 있는데, 이번엔 기존에 작업했던 것들과는 좀 다른 부분에서 시도를 많이 했어요.
처음으로 Unit Testing 이라는 것과 CI/CD 자동화 구축, 의존성 주입 과 Coordinator 패턴등을 다 적용해봤어요.

Unit Testing 의 위력은 굉장했다.

한글을 변환하는 부분 로직에서 Unit Testing 의 중요성을 실감하게 된 거 같네요.
기존 한글을 변환하는 로직은 "안녕" 같은 문장 또는 "안" 같은 문자는 정상적으로 "문자 또는 문자열 -> UTF16 -> 모스코드" 로 변환이 이루어졌습니다. 그러나 "ㄱ" 과 같은 자음 또는 모음 하나는 출력이 안되는 문제가 생겼습니다.

Xcode 에서 제공하는 Unit Test 라는 것을 사용해서 한글을 변환하는 로직 내부를 미리 테스트 해볼 수 있는 기능이 있어. 계속 로직을 바꿔가며 수 차례 테스트를 진행한 결과, 정상적으로 "ㄱ" 와 "안녕", "안" 같은 입력값들을 처리할 수 있게 됐습니다.

Unit Testing 을 할려면, 의존성 주입은 필연적이다.

기존에는 의존성 주입을 하지 않고, 앱을 제작했습니다.
그러다 보니, 테스트를 하는 것은 꿈도 꿀 수도 없었습니다.
기능 로직을 하나 바꾸기만 해도 엄청나게 많은 곳에서 코드의 변경이 이루어 지기 때문입니다.

그러나 의존성 주입이 이루어진 이후로는 기능 로직들이 다른 View 또는 객체에 영향을 받지 않게 되어, 테스트가 가능해졌습니다.
테스트 환경에서 기능 로직 프로토콜과 프로토콜을 채택한 서비스 하나를 만들어 그 곳에서 미리 코드들을 설계한 후, View 또는 ViewModel 에 사용하니, 훨씬 시행착오를 덜 겪게 되었습니다.

Coordinator 패턴의 중요성은 아직은 잘 모르겠다 입니다.

지금 코드처럼 기능들을 처리하는 VC 가 하나뿐 일 때는, 코디네이터 패턴을 사용하는 것은 너무 오버 코딩이라고 생각이 듭니다.
그러나 여러 개의 VC 를 담는 탭바 컨트롤러를 사용하는 경우 또는 네비게이션 스택을 사용하는 경우에는 적합하지 않을까?라는 생각이 됩니다.

View 들 간의 이동을 외부에서 관리해주면서 동시에 의존성 관리를 해주면, 이후의 코드 리팩토링 및 기능 추가에 도움이 되지 않을까 합니다.

CI/CD 를 구축해 놓으면 생산성이 올라가네요.

말 그대로 입니다. CI/CD 를 미리 잘 구축해 놓으면 반복되는 귀찮은 작업들을 간소화 할 수 있습니다.
테스트, Testflight 에 배포 하는 등의 작업을 컴퓨터가 알아서 대신 다 해줍니다.

앱 배포하기 위해서 Archive 하고 Testflight 에 업로드 하는 등의 작업을 "fastlane upload" 같은 명령어 한 번으로 끝낼 수 있게 됩니다.

위가 지금까지 프로젝트를 해오면서, 느낀 회고점들 입니다. 그 외에도 더 있긴한데, 적기 애매한 것들이라 뺐습니다.

아? 그리고 굳이 한 가지를 더 추가하자면, 추상화를 할 수록, 귀찮아 지는 부분들이 많이 발생합니다. 관리해야하는 파일들이 많아지니까요...
그렇지만, 후에 기능을 추가/수정/삭제하는 부분에서 편해지니, 조금? 귀찮더라도 참고 하는 방법을 적극적으로 해야겠습니다..

0개의 댓글