UIProgressViewUIProgressView는 0~1 사이의 수치로 progress를 표현할때 사용하는 UIView입니다.개발자는 정확한 progress를 쉽게 표현하기 위해 UIProgressView를 사용할텐데요.UIProgressView에는 숨겨진 함정이 있습니다.바로 progress를 표현하는 최소 width가 정해져있다는 것입니다. progress 수치에 따른 width 비교0.5예를 들어, width가 100인 UIProgressView의 progress를 0.5로 설정하면 progress width는 50이 됩니다.progressView.progressTintColor = .cyanprogressView.frame = CGRect(x: 180, y: 300, width: 100, he..

서론최근 테스트와 관련된 포스팅을 작성했습니다.테스트 코드 필요성과 테스트 쉬운 구조테스트 코드 작성과 구조 개선역할 분리와 객체 지향과 코드 개선그리고 작업을 진행하면서 꾸준히 테스트 코드를 작성하고 있어요.Swift Testing의 좋았던 점과 테스트 코드를 작성하면서 느낀 점을 공유해보고 싶어서 또 포스팅을 쓰러 왔어요 ㅎㅎ테스트 코드를 왜 작성하기로 결심했는지 등은 이전 포스팅을 참고해 주세요. Swift Testing제가 담당하는 앱은 글로벌 서비스라 최근에 최소지원버전을 iOS 15로 올렸을 만큼 최신화된 프로젝트는 아니에요.Swift Testing 처음 발표를 들었을 때는 "이번에도 나는 못 쓰지 않을까?" 생각이 있었어요.다행히 Swift Testing은 그런 걱정과 달리 편하게 사용할 ..

서론최근 제 코드를 어떻게 하면 더 나은 방향으로 개선할 수 있을지 많은 고민을 하고 있습니다.매 순간 마주하는 코드의 맥락과 작업 환경, 그리고 제가 처한 상황이 계속 변화하다 보니 명확한 해답을 찾기가 쉽지 않더라고요. 이런 고민들을 정리하면서 함께 나누고 싶어 이 글을 쓰게 되었습니다.특히 요즘은 객체지향적인 설계와 역할 분리에 대해 깊이 생각해보고 있는데요. 실제 업무에서 작성한 코드로 예시를 들면 좋겠지만, 회사 코드라는 특성상 공개하기 어려운 점이 아쉽네요.그래서 이번 글은 다소 추상적인 경험 공유가 될 것 같습니다만, 함께 이야기를 나누면서 서로의 생각을 공유할 수 있었으면 좋겠어요. 고민하게 된 계기역할 분리와 객체지향에 대해 고민하게 된 계기는 반복되는 보일러플레이트 코드였습니다.개발을 ..

서론이전 포스팅에서 테스트 코드의 필요성을 느꼈다는 글을 적었습니다. [iOS/꾸준 회고]테스트 코드 필요성과 테스트 쉬운 구조서론최근 테스트 코드와 관련된 많은 깨달음을 얻었습니다.테스트 코드의 필요성과 테스트하기 좋은 구조란 무엇인지, 그리고 왜 MVC 패턴에서 테스트가 어려운지를 체감할 수 있었습니다. 테jeong9216.tistory.com이에 대한 최근 근황을 작성해보려고 합니다. 흐려지는 동기테스트 코드가 아니어도 이미 많은 업무를 처리하다 보니 테스트 코드를 작성하는 동기가 점점 흐려졌습니다. (외면하게 되었다는 게 맞겠네요... 🥲) 이 흐려지는 동기를 해결하기 위해 저는 테스트 코드 작성을 팀의 레벨로 올려서 진행했습니다.저희 회사는 1명이 프로젝트를 온전히 담당하는 구조라서 같은 프로..

서론최근 테스트 코드와 관련된 많은 깨달음을 얻었습니다.테스트 코드의 필요성과 테스트하기 좋은 구조란 무엇인지, 그리고 왜 MVC 패턴에서 테스트가 어려운지를 체감할 수 있었습니다. 테스트 코드 없이 앱 리뉴얼 하기최근 사내 앱의 UI 리뉴얼을 진행했습니다.기존 기능은 그대로 유지하면서 UI만 새롭게 구현하는 작업이었습니다. 이 과정에서 기존 동작 검증에 어려움을 느꼈습니다.기존 동작이 제대로 유지되는지 확인하기 위해서는 기존 앱과 리뉴얼된 앱을 일일이 실행하며 비교해야 했습니다.테스트 코드가 있었다면 딸깍 한 번으로 검증이 가능했을 텐데... 많이 아쉬웠습니다. 작업 시간뿐만 아니라 심리적인 부담도 상당했습니다."테스트 코드 없는 리팩토링은 도박과 같다"는 말이 있듯이 코드를 수정할 때마다 "이 수정이..

클린 아키텍처 원 그림과 사용자 관점의 불일치최근 흥미로운 대화를 나눴습니다."iOS 개발할 때 클린 아키텍처의 원과 사용자 관점이 잘 안 맞는 것 같지 않나요?" 소프트웨어 개발자라면 한 번쯤은 접해봤을 클린 아키텍처의 유명한 원형 다이어그램에 대한 이야기입니다.이 다이어그램에서는 네트워크 계층이 가장 바깥쪽에 위치하고, Presenter, Use Case, Domain 등이 안쪽에 배치되어 있습니다.하지만 실제 사용자 시나리오를 보면, 화면이 먼저 나타난 후 사용자 이벤트에 따라 네트워킹이 발생하는 것이 일반적입니다.즉, 사용자 관점에서는 네트워크보다 Presenter나 UseCase를 먼저 경험하게 되는 것이죠. 물론 이 다이어그램이 잘못되었다고 할 순 없습니다.이렇게 널리 알려진 데에는 분명한 이..

서론제가 개발 중인 앱에는 다국어를 지원합니다. 총 영어(en), 일본어(ja), 터키어(tr), 스페인어(es) 총 4개의 다국어를 지원하고 있어요.그래서 Localizable.strings로 다국어를 키-문자열 쌍으로 관리하고 있습니다.아래에서 설명할 이유들로 Lokalise 서비스 도입을 결정했고, 이 과정에서 도입을 위한 작업을 효율적으로 개선한 경험을 공유드리려고 합니다. 기존의 다국어 관리 문제기존 다국어 적용은 기획자가 각 클라이언트 개발자(iOS, Android, Web)에게 문자열을 전달해 줍니다.문자열을 받으면 각자의 방식으로 키를 정의하고 관리했죠. 이로 인해 기입 실수가 발생하면 클라이언트마다 다국어가 다른 경우가 생겼습니다. (특히 일본어는 한자라서 실수가 발생해도 알아차리기 어렵..

서론제 프로젝트에서는 대부분의 UseCase가 Repository와 ViewModel을 단순히 연결해 주는 역할만 하고 있었습니다. 예를 들면 다음과 같은 코드였죠.struct FetchBooksUseCase { func execute() async -> Something { await repository.fetchBooks() }}이런 구조 때문에 저는 종종 "과연 이 상황에 UseCase가 정말 필요할까?" 하는 의문을 가졌습니다. 하지만 최근 UseCase를 정의한 것이 매우 적절했다고 느낀 경험이 있었습니다.물론 이것이 엄청난 발견이나 깨달음은 아니었습니다. 다만, 인터넷에서 자주 언급되는 "UseCase를 사용해야 하는 이유"를 직접 체감하고 경험했다는 점에서 작은 감동을..

UIPageViewController 크래시 분석UIPageViewController를 사용하는 앱에서 높은 비율로 크래시가 발생했습니다.The number of view controllers provided (0) doesn't match the number required (2) for the requested transitionThe number of view controllers provided (0) doesn't match the number required (1) for the requested transitionUIPageViewController에 제공하는 UIViewController의 개수를 제대로 컨트롤하고 있었기 때문에 원인을 파악하기 어려웠습니다. UIPageViewControl..

Unit Test 자동화GitHub Actions를 활용하면 Xcode에서 작성한 Unit Test를 자동으로 체크할 수 있습니다.PR을 생성할 때, push를 할 때 등의 액션이 발생하면 Unit Test를 수행하는 방식입니다.Test 편의성과 안정성을 동시에 챙길 수 있으므로 꼭 필요한 과정입니다.  GitHub Actions로 자동화하며 겪은 에러저는 GitHub 안에서 개인 프로젝트 사이클을 돌리고 싶었기 때문에 GitHub Actions를 선택하였는데요.쉽게 가능할 줄 알았지만, 많은 에러를 겪었습니다. 고군분투의 흔적 ;;결과론적인 이야기지만, 앞에서부터 차근차근 살펴봤다면 쉽게 해결했을 텐데... 반성합니다 🥲성공한 Workflow는 최하단에 있으니 최종 결과만 필요하시면 쭉 내리시면 됩니..