개발공방

이 글의 목표 뭐야? 테스트 이게 끝이야? 별거 없잖아? 테스트 세팅 위 사진처럼 처음 프로젝트를 만들때 Test를 포함했다면 상관 없지만, 테스트를 포함하지 않았거나 위 사진처럼 Target에 Test가 없을땐 직접 추가해주면 된다. Test Target 추가하는 방법 위 사진 순서대로 Test Target을 추가하면 된다. 테스트 대상 우선 테스트 코드를 아주 쉽게 접근하기 위해 아주 간단한 테스트를 먼저 만나보자. 현재 애니또에서 사용하는 Entity중 하나인 RoomListItem 에 대한 테스트 코드를 작성해보겠다. struct RoomListItem { /// 방의 고유 id값 let id: Int /// 방 제목 let title: String /// 현재 진행 상태 let state: Ro..

노션에 먼저 작성한 후 블로그로 옮기기 때문에 노션이 보기에 더 편합니다 https://mingwan.notion.site/Moya-Unit-Test-5745af80d0414f3bbc8f785dd3775efd?pvs=4 들어가면서 Moya의 장점은 뭐가 있을까?? 장점으로 언급되는 곳에는 항상 테스트에 용이하다 라는 말이 항상 존재한다. 얼마나 용이하길래 항상 장점으로 꼽히는 것일까? 한번 알아보자. (Moya를 사용하면서 만들어봤던 영화 검색 프로젝트를 예시로 사용하겠다.) 간단히보는 Moya 사용법 본격적으로 알아보기 전에 아주 간단히 Moya의 사용법을 한번 더 짚고 넘어가자. 다들 알다시피 Moya를 사용하기 위해선 TargetType 이라는 protocol을 채택해야만 한다. import Fou..

노션에 먼저 작성한 후 블로그로 옮기기 때문에 노션이 보기에 더 편합니다 https://mingwan.notion.site/MVVM-Combine-Input-Output-2-3ad9c58dc84c4d0c9a14a34c52b25370?pvs=4 https://dev-workplace.tistory.com/23 [애니또] MVVM + Combine - 리팩토링 (3) 노션에 먼저 작성한 후 블로그로 옮기기 때문에 노션이 보기에 더 편합니다. https://www.notion.so/MVVM-Combine-323ab64639374213b1b1734fcea257e7?pvs=4 [애니또] ViewController와 View의 분리 - 리팩토링 (1) [애니또] View dev-workplace.tistory.co..

노션에 먼저 작성한 후 블로그로 옮기기 때문에 노션이 보기에 더 편합니다. https://www.notion.so/MVVM-Combine-323ab64639374213b1b1734fcea257e7?pvs=4 [애니또] ViewController와 View의 분리 - 리팩토링 (1) [애니또] ViewController와 View의 분리 - 리팩토링 (1) 현재 애니또 iOS팀이 직면한 문제 현재까지 개발하면서 많은 문제와 버그들을 만났다. 첫 문제들을 해결하는데는 어려움이 없었지만, 앱의 규모가 조금씩 커지면서 문제들이 서로 엮이기 시작했 dev-workplace.tistory.com 앞전에 작성한 글을 보면, UIViewController에서 View를 분리한 과정을 볼 수 있다. Delegate 패턴..

애니또 팀에서 아키텍쳐 패턴을 고민하던중 MVVM을 선택하게 되었다. 어떤 이유로 선택하게 되었는지 알아보겠다. 애니또 iOS 팀에서 MVVM을 선택한 이유 1. 테스트 가능성 우리의 목표는 테스트 가능한 코드였다. MVC에서는 테스트가 물론 가능할지 몰라도, 번거롭다. 왜냐하면 UIViewController에서 테스트가 필요한 함수들이 UI 코드와 엮여있기 때문이다. 테스트를 하기위해 UI관련 코드까지 작성해야하는 문제가 발생한다. 이런 문제들을 MVVM으로 해결할 수 있다. 비즈니스 로직들을 ViewModel이 소유하고 ViewModel은 View에 관해 일절 모른다. 그러기에 테스트 가능한 코드를 만들기 유리하다. 사실 1번의 이유만으로 충분하다. 2. 기능을 추가하기 힘든 기존의 아키텍처 패턴 M..

코드리뷰를 겪으면서 print() 구문이나, dump() 를 남겨뒀을 때 지워달란 리뷰를 받은적이 있다. 난 해당 값들을 확인하면서 개발하는게 편해서 남겨뒀다가 미처 지우지 못했던 것이다. 그러다 문득 의문이 들었다. 디버깅 코드들이 과연 얼마나 앱에 영향을 미칠까?? 이에 대해 알아보았다. 명확한 공식문서나 WWDC영상은 찾을 수 없었으나, stackoverflow를 통해 어느정도 해답을 얻을 수 있었다. print(), dump() 와 같이 개발하면서 디버깅시에 도움을 주는 코드들이 있다. 하지만 이 코드들은 프로덕션(릴리즈) 상태에서는 해당 코드가 실행은 되지만, 눈으로 확인할 수 없다. 말 그대로 디버깅 코드이기 때문이다. 위와 같은 디버깅 코드들이 프로덕션 코드에 남아있을 때, 생길 수 있는 단..

현재 애니또 iOS팀이 직면한 문제 현재까지 개발하면서 많은 문제와 버그들을 만났다. 첫 문제들을 해결하는데는 어려움이 없었지만, 앱의 규모가 조금씩 커지면서 문제들이 서로 엮이기 시작했다. 그래서 A라는 문제를 해결하면 B라는 문제가 다시 발생하는 상황이 생겼다. 이렇게 우당탕탕 앱을 만드는 것이 아니라 정형화된 틀이 필요했다. 그리고 각자가 만드는 기능들을 다른 팀원이 테스트하는데 굉장한 어려움이 있었다. 각자가 해당 브랜치로 가서 그 상황을 똑같이 만들어야 테스트가 가능했다. (그래서 PR에 테스트 방법을 상세히 적기도 했다) 애니또 팀에서 리팩토링을 진행한 이유 이젠 그 방식이 아니라 테스트 코드가 포함된 코드를 만들고 싶었고, 팀원끼리 상의한 결과 차근차근 리팩토링을 진행하자! 였다. 현재는 그..

크리스마스를 맞아 평소 해보고 싶었던 UIBezierPath를 끄적여 보기로 했다. 다들 즐거워하는 크리스마스이기 때문에 그냥 그림을 그리기 보단 의미있는 것을 그리고 싶었다. 그래서 크리스마스 트리를 그리기로 결정했다. UIBezierPath가 어떤건지 대충 알긴하지만 직접 사용해본적은 없었기에, 꽤나 흥미로웠다. 참고 : https://zeddios.tistory.com/814 zedd님의 정리를 참고했다. 정리가 매우 완벽하기 때문에 다른 글을 필요없이 저 시리즈를 쭉 훑어보면 이해가 될 것 같다. zedd님의 글엔 사람들의 이해를 돕기위해 viewDidLoad나 draw 함수에 다 정의되어 있는데, 난 내 방식대로 코드를 짰다. (property를 미리 만들고, 그리는 함수를 분리하는 식) (보시..

이번에 PR을 날리면 자동으로 빌드를 돌려서 develop이 박살나는지 확인해주는 CI를 적용해보았다. 적용해보면서 겪은 문제들과, 구글링해도 나오지 않던 바보같은 실수를 다른사람들은 하지 않았으면 하는 마음에 작성해본다. 우선은 특정 브랜치를 생성해서 진행한 게 아니라 develop 브랜치에서 진행했다. 그 이유는 develop에 들어갈 때 적용이 되는데, 새로 브랜치를 만들면 CI 추가 작업하고(한번에 된다는 보장이 없음. 분명 실수를 하기 때문에), develop에 PR날리고, 그 PR이 develop에 merge가 되어야 그 때부터 테스트를 할 수 있기 때문에 번거로워서 develop에서 작업했다. 우리팀 규칙으론 develop에서 작업은 원칙적으로 금지였지만, CI관련 작업이었고, 현재 앱 심사..

제가 이해한 내용을 이해하기 쉽게 정리합니다. 혼잣말하는 느낌으로 작성해서 반말로 작성했습니다 ! DispatchQueue를 사용해야하는 이유는 도대체 뭘까?? -> 비동기적으로 처리해야할 데이터(API 통신) 가 있을 때 사용한다. (우리가 어떤 앱을 실행했을때 바로 뭔가가 뜨지않고 1~2초후에 뜨는게 API통신으로 어떤 데이터를 불러오기 때문이다.) 비동기적이란 ?? 순차적(직렬적)으로 진행되는 작업이 아닌 병렬적으로 진행되는 작업 이게 무슨 말이지 ?? 1번(2초 걸리는 작업) 2번(3초 걸리는 작업) 3번(1초 걸리는 작업) 4번(2초 걸리는 작업) 으로 수행되어야할 작업이 있을 때 동기(Sync) : 1번이 끝나야 2번이 실행되고, 2번이 끝나야 3번이 실행되고 ... 그럼 총 8초가 걸릴것이다..