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

서론SwiftUI를 학습하면서 Swift 기본기의 중요성을 크게 느꼈습니다.SwiftUI는 구현이 매우 편리하지만, 학습 과정은 그만큼 쉽지 않다고 생각합니다.이번 포스팅에서는 View 프로토콜을 Swift 기반으로 단계적으로 이해해 나갔던 제 학습 과정을 공유하고자 합니다. 1단계: View 프로토콜 정의가장 먼저 공식문서가 말하는 View 프로토콜을 봅시다.@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)public protocol View { associatedtype Body : View @ViewBuilder var body: Self.Body { get }}View 프로토콜은 body computed 프로퍼티를 가지는 타입입니다..

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

서론Swift 4.1에서 flatMap이 deprecated되고 compactMap으로 역할이 분리되었습니다.저는 한 가지 착각하고 있었습니다. "flatMap이 아예 사라지고 compactMap이 새로 생겼구나"라고 오해했는데요, flatMap은 여러 형태가 존재했고, flatMap 중 하나가 compactMap이 된거였습니다.이번 포스팅은 pointfree의 https://www.pointfree.co/episodes/ep10-a-tale-of-two-flat-maps 영상과 스크립트를 정리한 포스팅입니다. flatMap이 어떤 형태를 제공했었고, 어떤 메서드가 compactMap이 된 것인지 알아보겠습니다. flatMap의 세 가지 형태flatMap은 총 세 가지 형태로 제공됩니다.extension..

Swift Macros 사용 이유이전 포스팅(https://jeong9216.tistory.com/727)에서 Swift macros에 대해 소개했습니다.Swift macros는 코드 작성 시 발생하는 반복적인 패턴을 효과적으로 제거하는 데 큰 도움이 됩니다.여기서 주목할 점은 단순한 코드의 반복이 아닌, 코드만으로는 해결하기 어려운 '패턴의 반복'을 제거할 수 있다는 것입니다. 이는 Swift macros의 강력한 특징 중 하나입니다. 구체적인 예로, DTO(Data Transfer Object)에서 CodingKeys를 작성하는 패턴을 들 수 있습니다. 이러한 패턴은 일반적인 방법으로는 코드 레벨에서 반복을 제거하기 어렵습니다. 그러나 Swift macros를 활용하면 이러한 반복적인 패턴을 효과적으..

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

difference(from:) difference(from:)은 두 개의 Collection 차이를 쉽게 구할 수 있는 메서드입니다. A와 B를 비교했을 때 무엇이 추가로 있고, 무엇이 없는지 알 수 있습니다. (A collection of insertions and removals that describe the difference between two ordered collection states.) 사용법도 간단합니다. let arr1 = [1, 2, 3, 4] let arr2 = [1, 3, 4, 5] let diff = arr2.difference(from: arr1) diff를 출력해 보면 arr1이 arr2가 되기 위해 무엇을 추가하고, 무엇을 빼야 하는지 알 수 있습니다. "Collect..

서론 프로토콜 타입을 사용할 때 불편한 점이 하나 있습니다. 메서드 파라미터에 기본 값을 사용할 수 없다는 점입니다. 예를 들어, UseCase의 execute 파라미터로 page를 전달해야 한다고 합시다. protocol UseCaseProtocol { func execute(page: Int) } struct UseCase: UseCaseProtocol { func execute(page: Int) { // Logic } } let useCase: UseCaseProtocol = UseCase() useCase.execute(page: 1) 그러면 위 코드처럼 항상 page를 전달해줘야 해요. page에 기본 값을 설정하고 싶어도 프로토콜 메서드에는 Default argument를 설정할 수 없다는 ..

NSCoding과 Codable Codable이 나오면서 NSCoding은 옛날의 그것으로 생각되었습니다. 그런데 NSCoding만이 할 수 있는 일이 있었습니다. 바로 상속 관계를 유지해서 저장하는 것입니다. Shape 부모 클래스를 상속하는 두 개의 자식 클래스가 있습니다. class Plane { var shapes: [Shape] init(shapes: [Shape]) { self.shapes = shapes } func display() { for shape in shapes { print("\(type(of: shape)): \(shape.description)") } } } let shapes: [Shape] = [ Rect(point: .init(x: 10, y: 10), size: .in..

Property Observer Property observers observe and respond to changes in a property’s value. Property observers are called every time a property’s value is set, even if the new value is the same as the property’s current value. Property Observer는 프로퍼티의 "값"이 변하면 호출됩니다. 여기서 "값"의 의미때문에 구조체와 클래스의 프로퍼티 옵저버 동작 차이가 발생합니다. struct StructA { var value: Int = 0 } class ClassA { var value: Int = 0 } var struc..