![]()
Subject는 non-Combine 코드로부터 값을 받아서 Subscriber에게 값을 방출시키는 Publisher입니다. PassthroughtSubject로 value를 전달하는 방식은 명령형 코드를 Combine을 통한 선언형 코드로 연결하는 좋은 방법입니다. (@published를 마킹한 프로퍼티와 유사한 징검다리 역할입니다. non-Combine 코드로부터 값을 받아, sink를 통해 값을 내보낼 수 있죠) PassthroughSubject ( = RxSwift의 PublishSubject) Subject의 가장 기본형입니다. 아래는 우선 커스텀 Subscriber의 예시입니다(Custom Subscriber는 이전글 참조) // 1. Error 타입을 정의 enum MyError: Error..
![]()
이전 글([Combine] Publisher, Subscriber, Cancellable)에서 Subscribe하자마자 단일값을 방출하고 Complete시키는 Publisher의 예시로 Just를 작성했었습니다. Future를 사용하면 단일값을 비동기적으로 생성하고 Complete하는 Publisher를 정의할 수 있습니다. 아래는 Int, Never의 Future를 생성하여 반환하는 factory함수입니다. (Never는 failure를 절대 반환하지 않음. 이전글 참조) func futureIncrement( integer: Int, afterDelay delay: TimeInterval) -> Future { } Future를 반환하는 함수 본문을 채워봅니다. 함수 호출부가 전달해 준 afterDe..
![]()
매개변수 객체 만들기 데이터 항목 여러개를 함수로 넘겨주게 되면, 데이터 구조를 묶어서 보내주면 좋습니다. 데이터 뭉치를 데이터 구조로 묶으면 데이터 사이의 관계가 명확해짐 함수는 데이터 구조를 받음으로써 매개변수 수가 줄어듦 같은 데이터 구조를 사용하는 모든 함수가 원소를 참조할 때 같은 이름을 사용하기 때문에 일관성을 높여줌 (1) 적당한 데이터 구조가 없으면 새로 만들기 (2) 테스트 (3) 함수 선언 바꾸기로 데이터 구조를 매개변수로 추가 (4) 테스트 (5) 함수 호출시 새로운 데이터 구조 인스턴스를 넘겨주도록 수정하고, 수정할 때마다 테스트 (6) 기존 매개변수를 사용하던 코드를 새 데이터 구조의 원소를 사용하도록 변경 (7) 기존 매개변수를 제거하고 테스트 아래는 온도측정값(reading) ..
![]()
변수 캡슐화하기 데이터는 참조하는 모든 부분을 한 번에 바꿔야 코드가 제대로 동작하는 까닭에 함수보다 까다롭습니다. 유효범위가 넓어질수록 다루기 어려워집니다. 전역 데이터가 골칫거리인 이유. 그래서 접근 범위가 넓은 데이터를 옮길 때는 먼저 그 데이터로의 접근을 독점하는 식의 '캡슐화'하는 것이 좋을 때가 많습니다. 캡슐화를 하면 데이터를 변경하고 사용하는 코드를 감시할 수 있는 확실한 통로가 되어주기 때문에 데이터 변경 전 검증이나, 변경 후 추가로직을 쉽게 끼워 넣을 수 있습니다. (Swift에서는 프로퍼티들에 willSet, didSet을 제공하기 때문에 통로를 이유로 캡슐화를 하지는 않습니다) '불변 데이터'는 가변 데이터보다 캡슐화할 이유가 적습니다. 데이터가 변경될 일이 없어서 갱신 전 검증 ..
![]()
함수 선언 바꾸기 함수의 이름이 좋으면 함수의 구현 코드를 볼 필요도 없이 호출문만 보고도 무슨일을 하는지 파악이 가능합니다. 💡 좋은 이름을 떠올리는 효과적인 방법은 '주석으로 함수의 목적을 설명해보기'. 주석이 멋진 이름으로 바뀌어 되돌아 올 때가 있음. 매개변수도 마찬가지. 함수를 사용하는 문맥을 설정하는 것. 함수 선언 바꾸기를 할 때는 변경사항을 보고 함수 선언과 호출문들을 단번에 고칠 수 있을지 가늠해보고 가능해 보이면 간단한 절차로 수행할 수 있습니다. [간단한 절차] (1) 매개변수를 제거하려거든 먼저 함수 본문에서 제거 대상 매개변수를 대상 매개변수를 참조하는 곳은 없는지 확인 (2) 메서드 선언을 원하는 형태로 변경 (3) 기존 메서드 선언을 참조하는 부분을 모두 찾아서 바뀐 형태로 수..
![]()
변수 추출하기 Extract Variable 표현식이 복잡하여 이해하기 어려울 땐, 지역 변수로 표현식을 쪼개어 관리하기 쉽게 만들수 있습니다. 추가한 변수는 디버거에 breakpoint를 지정하거나, 상태를 출력하거나, 상태를 임의로 변경할 수 있어 디버깅에도 많은 도움이 됩니다. (1) 추출하려는 표현식에 부작용은 없는지 확인 (2) 상수를 하나 선언하고 이름을 붙일 표현식의 복제본을 대입 (3) 원본 표현식을 만든 변수로 교체 (4) 테스트 (5) 표현식을 여러 곳에서 사용한다면 각각을 새로 만든 변수로 교체. 하나 교체할 때마다 테스트. 아래에 딱 봐도 복잡한 주석이 꼭 필요해보이는 계산식의 예시가 있습니다. func price(order: Order) -> Double { // 가격(price)..
![]()
함수 추출하기 Extract Function 코드 조각을 찾아 무슨 일을 하는지 파악한 다음, 독립된 함수로 추출하고 목적에 맞는 이름을 붙이는 작업입니다. '목적과 구현을 분리'하는 방식이 가장 합리적인 기준. 코드를 보고 무슨 일을 하는지 파악하는 데 한참이 걸린다면 그 부분을 함수로 추출한 뒤 '무슨 일'에 걸 맞는 이름을 짓습니다. (1) 함수를 새로 만들고, 목적을 잘 드러내는 이름을 붙임('어떻게'가 아닌 '무엇을' 하는지가 드러나야 함): 대상 코드가 함수 호출문 하나처럼 간단하더라도 함수로 뽑아서 목적이 더 잘 드러나는 이름을 붙일수 있다면 추출할 것(이런 이름이 떠오르지 않는다면 추출하면 안 된다는 신호) (2) 추출한 코드를 원본 함수에서 복사하여 새 함수에 붙여넣음 (3) 추출한 코드..
![]()
Foundation Package Preview Now Available I’m pleased to announce that a preview of the future of Foundation is now available on GitHub! www.swift.org 드디어 Swift로 작성된 Foundation Package의 Preview가 Github에 공개됐습니다. 아직 모두 완성된 것은 아니지만 초기 테스트와 컨트리뷰트를 위해 빠르게 공개되었다고 합니다. 공개된 요소들은 아래와 같습니다. FoundationEssentials AttributedString Data Date DateInterval JSONEncoder JSONDecoder Predicate String extensions UUID..
![]()
테스트 코드는 리팩터링이 아니더라도 새 함수, 새 기능을 만들 때 생각하지 못했던 버그를 검출할 수도 있고, 코드가 테스트 가능하게 만들기 위해서 좀 더 나은 코드로 리팩터링 할 수도 있음. → 좋은 테스트를 구축하는 일은 개발효율을 높여줌. 모든 테스트를 완전히 자동화하고 결과까지 스스로 검사하도록 만들어야 함. → 요즘 툴들은 자동으로 테스트를 진행해 줌. 우리가 예상하는 값을 코드로 명시해 두면 알아서 검사해 주고 문제가 있을 땐 문제를 찾아줌. 컴파일할 때마다 테스트도 함께 하면서 생산성이 급상승. 디버깅 시간이 크게 줄어듦. 테스트를 자주 수행하는 습관도 버그를 찾는 강력한 도구가 됨. → 새로운 코드를 작성할 때, 코드 리뷰를 진행할 때에도 테스트코드를 함께 작성하도록 권장해야 함. 테스트 코..
![]()
코드에서 나쁜 냄새가 나면 리팩터링할 시간. 당신은 당신이 뭘 모르는지 모른다. → 어떤 코드가 나쁜 코드인지 모르면, 어떻게 개선해야 하는지도 모름. → 리팩터링이 필요한 코드들의 일정한 패턴(악취!)이 있어서 이를 알아야 함. 1. 기이한 이름 Mysterious Name 코드는 단순하고 명료하게 작성해야 함. 코드를 명료하게 표현하는데 가장 중요한 요소 중 하나는 '이름'. 마땅한 이름이 떠오르지 않는다면 설계에 근본적인 문제가 숨어 있을 가능성이 높음. 각각의 이름이 정확히 무얼하는지 이해하기 어렵거나, 구현사항이 이름과 맞지 않은 경우 코드 이해력, 가독성이 떨어짐. → 함수, 모듈, 변수, 클래스 명은 그 이름만 봐도 각각 무슨 일을 하고 어떻게 사용해야 하는지 명확히 알 수 있도록 엄청나게 ..
![]()
이번 Xcode14.3 Release Note를 보면 아래와 같은 General Deprecation이 있습니다. Xcode isn’t supported under Rosetta. See Developer Technote “Resolving architecture build errors on Apple silicon“ for more information. (92772361) ⚠️Xcode 14.3부터는 Rosetta로 실행하는 것을 지원하지 않습니다. 저는 그동안 아래 글에서 Apple Silicon 환경(M1, M2, ...)에서 발생할 수 있는 문제점 및 해결 방법을 정리하고 계속 글을 갱신하고 있었는데요. 애플 실리콘(M1, M2, ...) 환경에서의 빌드 환경 문제 집에서는 M1 Pro 맥북을 ..
![]()
Xcode 14.3이 릴리즈되면서 Swift 5.8도 업데이트되었습니다. 변경점들을 간단하게 정리해봅니다. Function back deployment (SE-0376) @backDeployed(before:) attribute를 통해 이전 버전의 프레임워크에서 새 API를 사용할 수 있게 해줍니다. 함수에 대한 코드를 앱의 바이너리에 작성 후 런타임 시 검사하여 수행됩니다. 사용자가 적절한 새 OS를 사용하는 경우 시스템 자체 버전의 함수가 사용되고, 아닌 경우 앱 바이너리에 복사된 버전에 대신 사용됩니다. 단, @backDeployed는 함수, 메서드, 서브스크립트, 계산프로퍼티에만 적용됩니다. 당연하게도 만능으로 새 기능을 이전 OS에서 쓸 수 있게 한다던가 하는건 아닌거죠. 아래는 예시입니다. @..
