바야흐로 HangulKit의 Swift DocC 튜토리얼 문서를 작성하고 있을 때로 거슬러 올라갑니다... 그리고 현재진행형...

튜토리얼 문서를 들어가보시면 아시겠지만, DocC로는 반응형 튜토리얼을 만들 수 있는데요. SwiftUI와 유사?동일?한 문법으로 작성해주면 알아서 이런 아주 기깔나는 튜토리얼을 뽑아줍니다.

다만 사소한 문제점이 있습니다.

그것은 어떤 소프트웨어라도 피할 수 없는 숙명...

바로 버그가 있다는 것이죠.

DocC는 Tutorial을 작성할 때, code1.swift와 code2.swift라는 파일을 생성해서 각각 코드를 작성하고, 그 코드를 튜토리얼 내부의 단계, @Steps안의 @Step에서 불러와서 비교를 할 수 있습니다.

그러니까, code2.swift를 바로 직전 코드인 code1.swift와 비교를 해서 다른 부분을 강조해서 표시해주는 기능이 있답니다. 옵션에 따라 바로 직전 코드가 아니라 다른 코드를 비교하게 할 수도 있구요!

뭐 대충 위의 스크린샷과 같은 느낌입니다.

근데 스크린샷을 보고 "잘 되는 거 아니냐? 무슨 버그가 있다는 거냐"고 하시면...

코드 변경점 강조가 간헐적으로 안 되더라고요. 왜인지 (당시에는) 몰랐구요.

나만 겪는 문제가 아니었다

그래서 대충 짧_(지않았고찾는데꽤시간이걸렸지만그냥설명하기귀찮아서생략)_은 구글링을 마치니, Swift DocC GitHub Repo에 이슈가 이미 등록되어 있더라고요!

그래서 일단 버그를 재현해보았습니다

부분적으로 코드를 지워보기도 하고, 같은 문제를 겪던 다른 2명의 개발자 분들의 코드도 뜯어보고 하며, (여기도 자세한 설명은 생략) 결국은 재현해내는데 성공을 했답니다!

이슈에 기록이 남아있으니 직접 보시는 것도 좋지만, 또 글을 읽으러 온 분들에게 각박하게 페이지에서 쫓아내는 것도 도리가 아니기에 친절하지만 간략하게 설명을 드리자면:

@Steps {
    @Step {
        첫번째 스텝입니다.
        @Code(file: code1.swift, name: somefile.swift)
    }
    @Step {
        두번째 스텝입니다.
        @Code(file: code2.swift, name: somefile.swift)
    }
    @Step {
        세번째 스텝입니다.
        @Code(file: code2.swift, name: somefile.swift)
    }
}

요로코롬 두번째와 세번째 @Step에서 똑같은 코드 파일을 사용할 경우 뭔가 내부적으로 꼬이면서 첫번째 @Step에서 두번째 @Step으로 넘어갈 때 code1.swift와 code2.swift의 차이점이 강조가 되지 않는 것이었습니다.

근데 말이죠...

관련해서 정리하여 이슈에 코멘트를 남기고 난 얼마 뒤...

무려 애플 개발자피셜

버그 아니고 의도된 동작이라는 답변을 주셨는데요...!

답변을 요약하자면:

두 개 이상의 @Steps가 하나의 코드 파일을 지칭하고 있을 경우, DocC는 현재 @Step의 코드를 직전의 @Step과 비교하고, 현재 @Step과 직전 @Step의 (코드가) 같으니, 강조가 되지 않을 것이다.

인데요...

뭐지 그럼 내가 틀린건가?

근데 아무리 생각해봐도 이상한 겁니다.

1. 답변이 맞다고 해도, 첫번째와 두번째 단계에선 여전히 (다른 코드이니) 변경점이 표시되어야 하는 것이 아닌가?
2. 그럼 왜 세번째 단계를 빼면 버그가 사라지는가?

그래서...

아뇨 잘못된 건 잘못된 거죠!

위에서 설명한 것처럼 그게 그렇게 되면 안 되는 거 아니냐고요~라는 내용의 코멘트를 이슈에다가 또 달았는데요, 궁금하면 이슈에 있으니 참고바라요

이 글을 쓰고 있는 현 시간 기준으로 아직 별 다른 코멘트가 없으시네요... 많이 바쁘신가봅니다...

(나도바쁜데나도9to6풀타임근무뛰고남는시간쪼개서하는건데)

그래서... 일단 제 나름대로의 해결책을 생각해보자면...

해결책

1. 공식 문서에 @Code(file:name:)를 사용할 땐 중복 파일을 사용하지 말라고 명시

가장 간단하죠? 암것도 안 고쳐도 되고 그냥 버그나니까 하지마!라고 해버리면 되는 군대식 해결책!

하지만 뭐랄까... 그렇게 한다면 파일을 하나 더 생성해야하는 수고가 있잖아요...

하나의 파일을 단 한 번만 불러서 쓸 수 있다면 튜토리얼 때 같은 파일의 내용을 여러 번 사용하고 싶을 때 계속 새로 파일을 만들어야 하는데.. 파일도 많아지고 복잡하잖아요...

그래서 생각해본 다음 해결책은?

2. 같은 코드파일을 지목하고 있어도 알아서 잘 표시해준다.

근데 또 여기엔 내부 로직에서 두 가지 갈래가 있거든요?

내부적으로 같은 코드 파일 이름을 지칭하고 있으면:

1. 동일한 파일을 이름만 다르게 두 개 생성해서 이름만 다르게, 그러니까 code2a, code2b 이런 식으로 해서 알아서 두 개의 파일을 만들어주는 것. (이러면 기존 로직에 덧붙이게 되겠죠)
2. 알아서 잘 표시가 되게 기존 로직을 수정한다.

글로만 봐도 좀 복잡해보입니다.

그래서 DocC를 포크해서 직접 이것저것 만져보고, 괜찮은 해결책이 나오면 PR까지도 날려볼 생각으로,

DocC를 직접 건드려 보려고 했는데요...

여기서부터 또 난장판이었거든요... 그건 이제 다음 시간에... 찾아옵니다...

그럼

한글을 다루는 건 쉽지 않은 일입니다.

TypeScript는 토스의 es-hangul이라는 훌륭한 라이브러리가 있지만, Swift는 아직 없더라고요. (최소한 제가 찾아본 바로는…)

그래서 Swift로 같은 걸 사용해보고 싶어서 만들어봤습니다.

HangulKit입니다.

TypeScript로 작성된 es-hangul을 Swift로 포팅해놓은 녀석이라고 보시면 됩니다. 근데 이제 Swifty함을 곁들인…

만들면서 생각한 것들을 적어놓을 수도, 아닐 수도 있습니다... 모든 것은 제 가용한 시간에 달렸습니다. HangulKit 작업하는 데에 쓸 시간도 모자른지라…

여튼 서론은 여기까지!

참으로 굉장히 오랜만이네요.

제가 뭘 하고 있었냐면,

틴더식 카드 스와이프

를 구현한 오픈소스 라이브러리를 갖다가 프로젝트에 적용시키고 있었단 말이죠.

뭐 대충 이런 겁니다.

Shuffle이라는 오픈소스 라이브러리인데요, 델리게이트 패턴을 사용한 녀석이라, 처음에 적용하는 데에는 큰 무리가 없었습니다.

UICollectionView와 상당히 흡사한 Delegate와 Datasource 패턴을 채용했기 때문이죠.

근데... RxSwift를 사용해서 리팩터링을 진행하던 과정 중에 이 친구를 어떻게 Rx로 사용할 것인가?

라는 의문이 들었고, 잘 찾아보니 답이 나왔습니다.

답은 DelegateProxy다.

그럼 작성해줍시다.

extension SwipeCardStack: HasDelegate {
    public typealias Delegate = SwipeCardStackDelegate
}

일단 위의 코드로 Shuffle의 SwipeCardStack의 스와이프 액션 등을 처리해주는 Delegate가 있다고 명시해주고,

class RxSwipeCardStackDelegateProxy
: DelegateProxy<SwipeCardStack, SwipeCardStackDelegate>
, DelegateProxyType
, SwipeCardStackDelegate {

    weak private(set) var cardStack: SwipeCardStack?

    init(cardStack: SwipeCardStack) {
        self.cardStack = cardStack
        super.init(parentObject: cardStack, delegateProxy: RxSwipeCardStackDelegateProxy.self)
    }

    static func registerKnownImplementations() {
        self.register { RxSwipeCardStackDelegateProxy(cardStack: $0) }
    }
}

위 코드처럼 DelegateProxy를 작성해줍니다.

클래스명은 RxCocoa 내부에서 Rx+(원래 클래스 이름)+DelegateProxy로 다 지어놨길래 마음의 평안을 위해 통일해줍니다.

extension Reactive where Base: SwipeCardStack {
    var delegate: DelegateProxy<SwipeCardStack, SwipeCardStackDelegate> {
        return RxSwipeCardStackDelegateProxy.proxy(for: base)
    }

    // (기존 delegate의 메서드들을 넣을 곳)

}

그 담엔 이렇게 Reactive의 extension으로 작성을 해주고요, 아래에 기존 delegate의 메서드들을 넣어줍시다.

// 기존 delegate의 메서드들
@objc
optional func cardStack(_ cardStack: SwipeCardStack, didSelectCardAt index: Int)

@objc
optional func cardStack(_ cardStack: SwipeCardStack, didSwipeCardAt index: Int, with direction: SwipeDirection)

@objc
optional func cardStack(_ cardStack: SwipeCardStack, didUndoCardAt index: Int, from direction: SwipeDirection)

그러니까 요놈들을

// 넣어줌
extension Reactive where Base: SwipeCardStack {
    var delegate: DelegateProxy<SwipeCardStack, SwipeCardStackDelegate> {
        return RxSwipeCardStackDelegateProxy.proxy(for: base)
    }

    var didSelectCardAt: Observable<Int> {
        return delegate
            .methodInvoked(#selector(SwipeCardStackDelegate.cardStack(_:didSelectCardAt:)))
            .map { num in
                return num[1] as? Int ?? 0
            }
    }

    var didSwipeAllCards: Observable<Void> {
        return delegate
            .methodInvoked(#selector(SwipeCardStackDelegate.didSwipeAllCards(_:)))
            .map { _ in () }
    }

    var didSwipeCardAt: Observable<(Int, SwipeDirection)> {
        return delegate
            .methodInvoked(#selector(SwipeCardStackDelegate.cardStack(_:didSwipeCardAt:with:)))
            .map { args in
                return (
                    index: args[1] as? Int ?? 0,
                    direction: args[2] as! SwipeDirection
                )
            }
    }
}

이렇게 넣으면 된다...!

그럼 기존의 델리게이트에서 메서드가 호출되는 타이밍에 .methodInvoked가 호출되어 Observable을 반환하게 됩니다.

그럼 View와 ViewModel에 적용해볼까요?

아니 왜 또 안되는거야

근데 안되네요. 기존의 Delegate 패턴을 사용했을때 잘 뜨던 카드 스택들이 래핑하고 나니 안됩니다...

왜 안되는지... 뭐가 잘못되었는지 한참을 생각하고 코드를 읽어보다가...

설마... 하는 생각이 들어 다른 뷰의 프로퍼티로 분리해뒀던 것 때문에↓

프로젝트/
├─ class ItemSearchView/
│  ├─ 이것저것 뷰 컴포넌트들
├─ class ItemCardsView/
│  ├─ cardStack = SwipeCardStack()

그런 건가 싶어 합쳐주었고↓

프로젝트/
├─ class ItemSearchView/
│  ├─ 이것저것 뷰 컴포넌트들
│  ├─ cardStack = SwipeCardStack()
├─ class ItemCardsView -> delete/

그러니까 됩니다 또...?

사소한 소란이 있긴 했지만

여튼 그렇게 해결이 되었습니다.

예에에에에소리질러~

(실제로 몇시간동안 끙끙댄 후에 해결하고 소리지름 리얼참트루스토리)

어 근데 그럼 Datasource는요?

그게 말입니다....

Shuffle이 가지고있는 Delegate와 Datasource가 UICollectionView와 유사하게 되어 있어,

RxCocoa의 UICollectionView+Rx와 동일한 구조로 작업하면 되지 않을까... 하고 코드를 읽고 적용해보려 했거든요?

근데 안돼요.

계속 에러가 뜨더라고요...

정확히는:

'subscribeProxyDataSource(ofObject:dataSource:retainDataSource:binding:)' requires that 'any RxSwipeCardStackDataSourceProxy.Delegate' (aka 'any SwipeCardStackDataSource') be a class type

이렇게 뜨는데, 대충 해석하자면:

응 니가 준거 클래스 타입 아니야 돌아가~

라네요? 그래서 RxSwipeCardStackDataSourceProxy와 관련된 클래스들을 찾아봤는데 죄다 클래스였고,

SwipeCardStackDataSource도 확인해봤는데 AnyObject였단 말입니다..

public protocol SwipeCardStackDataSource: AnyObject {
  func cardStack(_ cardStack: SwipeCardStack, cardForIndexAt index: Int) -> SwipeCard
  func numberOfCards(in cardStack: SwipeCardStack) -> Int
}

그래서 일단은 데이터소스는 기존 형식을 사용하는 중인데... 이거 왜 이러는지 아시는 분은 댓글로 알려주시면 감사하겠습니다...

일단 해야 하는 게 뭐였냐면...

PokéAPI를 사용해서 MVVM 구조로 도감을 만드는 것입니다.

RxSwift와 MVVM 구조는 처음이라 좀 익숙치 않았는데,

처음이니까~ 하면서 우당탕탕 진행하면서

아무 일 없던 척 다음 단계로 넘어가던 와중에...

현지화를 해야된다

영어로 된 포켓몬의 이름과 타입 등을 한국어로 현지화해서 나타내야 하는 과정에 도달했습니다.

근데 과제에선 말이죠,

import Foundation

enum PokemonTranslator {
    private static let koreanNames: [String: String] = [
        "bulbasaur": "이상해씨",
        "ivysaur": "이상해풀",

        // (중략)

        "mewtwo": "뮤츠",
        "mew": "뮤"
    ]

    static func getKoreanName(for englishName: String) -> String {
        return koreanNames[englishName.lowercased()] ?? englishName
    }
}

/* 사용 예시
 let pokemonName = "Pikachu"
 let koreanName = PokemonTranslator.getKoreanName(for: pokemonName)
 print("\(pokemonName)의 한국어 이름: \(koreanName)")
 */

요런 식으로 현지화를 하라고 코드를 제공해주셨더라고요?

물론... 나쁘지 않은 해결책이지만...

1. 저렇게 코드 고봉밥이 있는 것
2. 추후 범위를 넓히면 또 수동으로 추가해줘야 한다는 점
3. 사용하지 않을 수도 있는 정보들이 static으로 선언되어 메모리에서 자리를 차지하고 있는 것

↑와 같은 사유 때문에 맘이 불편해서, 분명히 방법이 있을 것이야...를 되뇌며 pokeAPI를 쥐 잡듯 뒤졌습니다.

그러다가...?

음? 너 일로와봐

어어?? 다국어 지원이 안 되는 데 이게 있을 리가 없죠?

더 찾아봅시다.

그랬더니 PokéAPI 깃헙에서 이것을 발견했습니다.

링크 들어가기 귀찮은 분들을 위한 스샷↓

오호... pokemon species로 찾으면 뭔가 나올 것 같네요.

PokéAPI 문서로 돌아가봅시다.

음... pokemon species니까... Pokémon에서 찾아볼까요...?

오호 어디 그럼 https://pokeapi.co/api/v2/pokemon-species/1 로 들어가서 최종 확인해봅시다.

딴~ 라라란~ 따라란~ 따라란~ 따~ 쿵짝짝~ 쿵짝짝~ 따라리라라리 (BGM - 요한 슈트라우스 2세: 봄의 소리 왈츠)

한국어네?

한국어야?

갓챠

있었습니다. 한국어가!

그럼 새롭게 발견한 이 녀석을 사용해주기 위해...

struct PokemonSpecies: Codable {
    var names: [Name] = []
}

struct Name: Codable {
    let name: String
    let language: Language
}

struct Language: Codable {
    let name: String
    let url: String
}

JSON 디코딩을 위한 구조체를 선언해주고...

private func fetchLocalizedNames() {
    guard let url = URL(string: "https://pokeapi.co/api/v2/pokemon-species/\(pokemonID.description)") else {
        namesSubject.onError(NetworkError.invalidURL)
        return
    }

    NetworkManager.shared.fetch(url: url)
        .subscribe(onSuccess: { [weak self] (names: PokemonSpecies) in
            self?.namesSubject.onNext(names)
        }, onFailure: { [weak self] error in
            self?.namesSubject.onError(error)
        }).disposed(by: disposeBag)
}

ViewModel에서 정보를 받아오는 부분을 추가해주고...

View에서 적용해주면...?

한국어로 잘 나오는군요

추가 사항

다른 분들이 겪으신 29. 니드런♀이나 122. 마임맨 등의 api에서 영어이름이 수정되어 현지화된 이름이 나오지 않는 문제를 소 뒷걸음질치다 쥐 잡은 격으로 겪지 않게 되었네요...? 완전 럭키비키잖아💛✨

읽고 오시기 귀찮은 분들을 위해 제가 대신 요약하자면,

1. forEach 혹은 for-in 반복문으로 UIView의 Subview로 UIView와 UILabel을 넣어주고
2. SnapKit을 활용해 제약조건을 설정해주면?
3. 축☆런타임 에러★축
4. 유는 모든 구성요소가 넣어지기 전에 SnapKit 코드가 실행되어서인것으로 추정.
5. forEach나 for-in 반복문 말고 addSubview를 직접 반복해서 적어주면 버그 X

와 참 친절한 요약!

여튼, 수많은 뻘짓 끝에 버그의 실로 놀라운 해결책을 찾아냈습니다.

그러나 여백이 부족하여 이를 적지 않겠다...는 농담이구요

그저 시력이 딸려서 발생한 휴먼에러입니다.

저번 글에 넣어놓은 짤방에 답이 있었더라고요...

다시 갖고 왔습니다:

보이시나요?

빨간색으로 표시해보겠습니다.

ㅎㅎ ㅎ

ㅋㅋㅋㅋㅋㅋㅋ

selectedBox만 두개...

즉 selectedLabel이 subView에 들어가지 않은 상태에서 SnapKit으로 SuperView로 constraint를 잡으려니까 에러가 뜬 것이었네요...

네... 저걸 코드를 짤 때도, 주석처리를 할 때도, 스크린샷을 찍을 때도, 짤방까지 만들때까지도 발견을 못 한게 신기하네요...

진즉에 GPT한테 물어봤으면 짚어줬을 것 같은데 그놈의 쓸데없는 자존심때문에 안 물어보다가 여기까지 끌렸습니다.

여튼, SnapKit의 "Fatal error: Expected superview but found nil when attempting make constraint equalToSuperview."라는 에러는, SuperView를 찾을 수 없을 때 나오는 에러이다...!

ㅎㅋㅋㅎ...ㅎ....ㅋㅋㅋ....ㅎㅎㅎ...

두 날짜를 비교하는 중위 연산자들 (==, !=, <, >, <=, >=)

딱히 설명이 필요할까 싶습니다.

스크린샷으로 갈음합니다.

compare(Date) -> ComparisonResult

이건 위에서 본 중위 연산자들이랑 비슷한데요,

리턴값이 Bool이 아니라, ComparisonResult라는 Enum 값입니다.

Enum 값이기에, Switch-case 문에서 사용하기 유용하겠죠?

.rawValue를 붙여서 1, 0, -1 정수값으로 나타낼 수도 있긴 한데.... 사실 그럴 바에 중위 연산자들을 쓰는 게 낫지 않나...?

여튼 코드 예시를 보여드리겠습니다:

이해가 잘 되셨길 바라며...

다음 항목으로 넘어가도록 하겠습니다.

distance(to: Date) -> TimeInterval

이 친구는 간단합니다.

두 Date 간 TimeInterval을 알려줍니다.

보면 바로 이해 되실겁니다.

참 쉽죠? (2)

timeIntervalSince(Date) -> TimeInterval

바로 위의 distance(to:)와 똑같은 친구 아니냐고요?

비슷합니다.

아빠의 이름이 진화고 승우라는 이름의 아들이 있다고 하면,

승우아빠가 진화냐 진화아들이 승우냐 그 차이입니다.

서순이죠.

조금 헷갈리셨다면 다시 찬찬히 읽어보시면 이해가 되실 겁니다.

timeIntervalSinceNow/ReferenceDate/1970

네... 기준점 차이입니다. 이것도 별거 없으니 스샷으로 갈음합니다.

addTimeInterval(TimeInterval) / addingTimeInterval(TimeInterval)

둘 다 이름 그대로 Date에 TimeInterval을 더합니다.

앞에 붙는 단어가 add와 adding라는 차이가 있는데요.

둘의 차이는 Date를 추가로 반환하냐 아니냐의 차이입니다.

그래서 adding은 let 상수에도 쓰일 수 있지만,

add는 그렇게 못 씁니다.

변수로 바꿔주니 잘 되네요.

그럼 다음에 계속...

오늘도 알쏭달쏭 트러블슈팅에 오신 여러분을 환영합니다.

하...

배경 설명을 조금 하자면요,

요런 녀석을 만들어야 해서,

대충 요런 코드를 짜는 중이었습니다.

import UIKit

import SnapKit
import Then

final class ColorGuide: UIView {

    private let availableBox = UIView().then {
        $0.backgroundColor = .available
        $0.layer.cornerRadius = 4
    }

// 중략...

    private let availableLabel = UILabel().then {
        $0.text = "선택 가능"
        $0.textColor = ._100
    }
// 중략...

이렇게 네모 상자가 될 UIView와 그 옆에 붙을 UILabel을 만들어주고,

override init(frame: CGRect) {
    super.init(frame: frame)
    backgroundColor = .systemBackground
    setViews()
    setConstraints()
}

// 중략...
private func setViews() {
    [
        availableBox, availableLabel,
        unavailableBox, unavailableLabel,
        selectedBox, selectedBox
    ].forEach { addSubview($0) }
}

private func setConstraints() {
    let boxSize: CGFloat = 12
    let boxLabelDistance: CGFloat = 7
    let leadingTrailingDistance: CGFloat = 16

        // 선택 가능
    availableBox.snp.makeConstraints { make in
        make.leading.equalToSuperview()
        make.size.equalTo(boxSize)
        make.centerY.equalToSuperview()
    }
    availableLabel.snp.makeConstraints { make in
        make.leading.equalTo(availableBox.snp.trailing).offset(boxLabelDistance)
        make.centerY.equalToSuperview()
    }
    // 후략...
}

대충 이런 코드로 뷰를 넣어주고 constraints를 적용해주는 코드를 작성했습니다.

별 문제 없을 것 같아 보이지 않나요?

저도 그렇게 생각했습니다.

빨간색으로 왼뺨을 맞기 전까진요.

여차저차 이리저리 생각해서 가설을 내려봤습니다.

1. 고차함수인 forEach를 쓰면 (.map이나 .filter처럼) 컴파일러의 최적화가 관여할 여지가 늘어나니,
2. 어떻게 해서 뒤에 오는 setConstraints가 먼저 실행되어서,
3. 각 요소들 중 일부가 subview로 들어가지 못했고,
4. 결과적으로 들어가지 못 한 요소의 superview를 잡으려고 해서 그런 게 아닐까?

미리 스포하자면, 1번은 거짓이었습니다... 사유: 언제 forEach를 또는 for-in 반복문을 쓸 것이냐 & Swift source code 정리하면서 보니 소 뒷걸음질치다 쥐를 잡은 격이네요. 소띠라서그런가

그래서 하드코딩으로 해봤습니다.

어... 잘... 되네요...?

그럼 이론 상 같은 코드를 반복하여 실행해주는 for-in 반복문도 되어야 하는 것이겠죠?

근데 말이죠...

아니 믿었던 반복문 ㄴㅓ ㅁㅏ ㅈㅓ... 왼뺨을 맞고 눈물흘리며 찾아간 친구가 오른뺨 마저도 때려주는 기분이네요.

원인의 실마리가 미궁 속으로 빠져버렸습니다... 근데 오늘은 너무나도 졸린 나머지 다음에 이어서 알아보도록 하겠습니다...

Q. 어? 근데 Date()를 그대로 이니셜라이징해도 현재 시간이 나오는 건 똑같지 않나요?

now는 왜 따로 있어요?

이거에 대해서는 배경 지식에 대한 이해가 필요한데요...

길게 설명하면 읽는 사람도 쓰는 사람도 귀찮으니,

세 줄 요약으로 갈음하겠습니다:

1. 원래는 Date.now가 없었음.

2. 사람들이 다들 Date의 Extension으로 직접 Date.now를 만들어서 사용함. (Date() 보다 Date.now가 현재시간이라는 것이 명확하니까!)

3. Swift 5.5에서 정식으로 추가됨. (iOS 15 / macOS 12 이상에서 사용 가능.)

자세한 내용은: https://stackoverflow.com/questions/78750336/swift-date-vs-date-now-when-to-use-which https://forums.swift.org/t/date-now-and-other-calendar-thoughts/12853

코드 예시 하나 던져놓고 넘어가겠습니다:

타입 프로퍼티 distantFuture/distantPast

직역하면 먼 미래와 먼 과거입니다.

그리고 말 그대로 먼 미래의 시간과 먼 과거의 시간을 나타냅니다.

얼마나 머냐고요?

2000...년정도?

아니 이런 거 뒀다 어디 써요? 라고 하실 수도 있지만,

캘린더 앱 등에서 지금으로부터 모든 과거/미래의 이벤트를 갖고 오고 싶다 할 때 유용하겠습니다.

다음에 계속...

또 그 시간이 왔군요

트러블슈팅의 시간 말입니다.

제목에서 유추하신 분들도 있겠지만, 바로 짤로 보는 것이 이해가 빠르니 보여드리겠습니다.

거슬리군요 참으로...

하지만 이제 짬바가 조금 생겨서일까요?

바로 해.결.해버렸읍니다...

어떻게 해결했냐하면...

self.backgroundColor = .systemBackground

위에 덮여지는 뷰에 이 코드 한 줄 넣으니 해결이더군요.

아이 신나

typealias TimeInterval

*typealias란, 기존의 자료형을 별명으로 부르는 것이라고 생각하면 편합니다.

마치 울트라리스크를 울트라, 울라리, 울리크 등으로 바꿔 부르지만 여러분들은 다 알아들으시는 것 처럼 말이죠.   TimeInterval은 Double입니다. 근데 시간을 초 단위로 나타내는... 친구죠.   뭔 소린가 싶으시면 아래를 보시면 됩니다↓

어렵잖게 이해하셨을것이라 생각하고 넘어가겠습니다.

뒤에 나올 Date에서 시간 간격을 지정할 때 유용하게 쓰이니 기억해두면 좋습니다.

Date()

위에서 보셨듯, 아무런 파라미터를 넣지 않고 Date를 이니셜라이징하면,

현재의 날짜와 시간으로 이니셜라이징이 됩니다.

이어서 다른 이니셜라이징 방법을 살펴봅시다.

Date(timeIntervalSinceNow:)

저기 저 위에서 첫번째 스샷 내부 코드에서 보신 친구죠? 뭔지 모르겠으면 위에서 다시 보고 오시면 됩니다. 저는 불친절한 사람이라 다시 적어주지 않습니다.

Date(timeInterval:since:)

위의 Date(timeIntervalSinceNow:)와 비슷하게 생겼죠? 실제로 비슷합니다. since: 뒤에 지금의 시간 대신 다른 Date를 넣어주면 그 시간을 기준으로 시간을 계산해줍니다.

요렇게 말이죠.

Date(timeIntervalSinceReferenceDate:)

얘도 바로 위에 있는 친구랑 똑같습니다. 다만 ReferenceDate가 기준인데요. 2001.01.01 00:00:00 UTC가 기준입니다. 그 기준으로 초 단위로 시간을 입력해주시면 됩니다.

Date(timeIntervalSince1970:)

얘도 바로 위에 있는 친구랑 똑같습니다. 다만 유닉스 시간, 즉, 1970.01.01 00:00:00 UTC가 기준입니다. (후략)

졸리니 이만 하고 나중에 이어서 적어보겠습니다.

근데 또 보면 어쩔때는 @Binding을 사용하죠? 차이가 뭘까요?

코딩에 영어가 필수란 말을 들어보셨을 건데, 여기서 체감 가능합니다. Binding은 묶음이라는 뜻입니다.

뭐에 묶였길래 묶음이라고 했을까요?

다른 State에 묶어서 동작하기 때문입니다.

코드로 예시를 한 번 볼까요?

위 코드는 showChildView라는 상태 속성(@State)을 이용해서 true일 경우 ChildView가 나오고, false일 경우 나타나지 않습니다.

프리뷰를 보면 아래처럼 나옵니다:

클릭하면?

이렇게 됩니다.

어 근데 이러면 전 화면으로 어떻게 돌아가나요? showChildView를 false로 바꿔주면 되겠죠?

어디 한번 해봅시다.

ChildView가 나타났을 때니, ChildView에서 showChildView를 false로 바꿔주는 버튼을 만들면 되겠죠?

네. 안됩니다. 같은 scope에 있지 않아서죠.

아니 그럼 영원히 닫지 못 하는 창을 계속 띄우고 있어야 하냐고요?

다행스럽게도 방법이 있습니다.

@Binding을 사용해서 ParentView에 있는 showChildView 상태 속성과 연결해 주면 됩니다.

@Binding을 추가해 주면 아래와 같이 뜨는데요,

ChildView()를 호출할 때 파라미터로 Binding을 요구하는 것을 볼 수 있습니다.

그럼 다시 ParentView()로 돌아가서, ChildView의 파라미터를 넣어주면?

와! 해결!

한줄 요약: @State에 묶어서 사용하는 것이 @Binding이다.

배움에 도움이 된 영상 https://www.youtube.com/watch?v=uiptHyyxF3Y

생각해보니, 저번 포스팅에서 제목에 reduce를 넣어놓고는 내용에선 까먹고 적지 않은 것이 있더라고요?

그래서 이어서 적어보려 합니다.

후행 클로저와도 어느정도 연관이 있는 이야기다 보니, 어찌보면 잘 된 일이겠죠.

저번 포스팅에서 썼던 reduce 예제를 다시 가져와보겠습니다.

reduce를 쓰다보면, 트레일링 클로저를 사용해 어떻게 reduce를 할지 전달해 주곤 합니다.

트레일링 클로저가 뭔지 모른다고요? 클릭하십시오 휴먼. 또는 클로저가 뭔지, 또는 클로저 축약문법이 익숙하지 않다고요? 클릭하십시오 휴먼.

클로저 또 너냐

위의 글을 읽었거나, 클로저에 대한 어느정도의 이해가 있다면 말이죠,

let 머리부터발끝까지: [String] = ["머리", "부터", "발끝", "까지"]

let 오로나민씨 = 머리부터발끝까지.reduce("") { $0 + $1 }

print(오로나민씨 + "오로나민씨") // 머리부터발끝까지오로나민씨

여기서 $0, $1이 왜 쓰이는지 아실 겁니다.

근데 이건 어떨까요?

let 머리부터발끝까지: [String] = ["머리", "부터", "발끝", "까지"]

let 사랑스러워 = 머리부터발끝까지.reduce("", +)

print(사랑스러워 + "다사랑스러워") // 머리부터발끝까지다사랑스러워

이게 왜 되지? 싶지 않으신가요?

let 오로나민씨 = 머리부터발끝까지.reduce("") { $0 + $1 }
let 사랑스러워 = 머리부터발끝까지.reduce("", +)

아니, 트레일링 클로저까지만 알면 끝난 거 아니었어? 하실 수 있습니다.

하지만 이번엔 비교적 짧으니 좀만 견뎌보시죠.

Q. 저게 왜 되냐?

A: 고차함수는 클로저를 받으니까요!

예제로 쓰인 고차함수 reduce의 정의를 볼까요?

위의 정의에서 클로저를 받는 아래 코드를 봅시다.

nextPartialResult: (Result, Self.Element) throws -> Result

이해를 돕기 위해 헷갈릴 수 있는 제네릭과 에러 처리 구문 throws를 없애보겠습니다.

nextPartialResult: (String, String) -> String

즉, nextPartialResult는 String 2개를 받아 String을 반환하는 클로저(익명함수)를 받는 함수의 전달인자인 것입니다.

근데 클로저 첫 번째 시리즈를 보셨으면 아시겠지만, 보통 우리가 클로저라고 부르는 것은 익명 함수입니다.

네. 다시 말하지만 클로저는 함수입니다.

근데 우리가 자각하지 못 하는 다른 함수 친구가 또 있다면 믿으시겠습니까?

바로 연산자들입니다.

일반 함수들과는 다르게 prefix/postfix/infix operator라고 선언해줘야 연산자 앞/뒤의 값을 가져올 수 있어서 쵸큼 다르긴 한데...

함수라는건 똑같으니 일단 계속 진행하겠습니다.

연산자가 함수이니, 함수를 전달인자로 받는 고차함수에서 사용이 가능한 것입니다.

let 오로나민씨 = 머리부터발끝까지.reduce("") { $0 + $1 }
let 사랑스러워 = 머리부터발끝까지.reduce("", +)

그래서 이런 짓도 가능합니다

import Foundation

let 머리부터발끝까지: [String] = ["머리", "부터", "발끝", "까지"]

// 클로저로 작성하여 전달.
let 힘차게 = { $0 + $1 + "!" }

// 중위 연산자 ~ 선언 후,
infix operator ~

// 함수로 작성하여 전달.
func ~ (lhs: String, rhs: String) -> String {
    return lhs + rhs + "~"
}

let 사랑스러워 = 머리부터발끝까지.reduce("", +)
let 힘차게머리부터발끝까지 = 머리부터발끝까지.reduce("", 힘차게)
let 늘어지게머리부터발끝까지 = 머리부터발끝까지.reduce("", ~)

print(사랑스러워 + "다사랑스러워") // 머리부터발끝까지다사랑스러워
print(힘차게머리부터발끝까지 + "다입수") // 머리!부터!발끝!까지!다입수
print(늘어지게머리부터발끝까지 + "오로나민씨") // 머리~부터~발끝~까지~오로나민씨

참 신기하지 않나요?

오늘은 여기까지입니다.

나가세요 이제.

입력값을 거르는 과정에서 .count를 이용해 걸러줄 것인가? 거르지 않아도 함수 내부 로직에서 O(n)의 시간복잡도로 걸러지는 구조이다. 즉, 다른 말로 하자면?

.count가 O(n)의 시간복잡도를 가진다면 손해, O(1)라면 이득인 구조.

그래서 찾아보니, collection이 RandomAccessCollection 프로토콜에 부합하면, instance property인 count가 O(1)의 시간복잡도를 가진다고 하네요?

부합 안 하면 O(n) 이래요.

제가 뭐 어떻게 지어낸 말이 아니라 애플이 그렇대요.

Complexity O(1) if the collection conforms to RandomAccessCollection; otherwise, O(n), where n is the length of the collection. Source: Apple Developer Documentation

그래서...

RandomAccessColletion

은 또 뭔지 찾아봤습니다.

오호... 흥미롭네요...

이 프로토콜에 대해선 나중에 따로 글을 써 보도록 하고,

일단은 요점만 쓰자면, Array의 경우 Array의 Element가 Copyable과 Escapable 프로토콜을 따르는 경우, RandomAccessColletion 프로토콜에 부합한다고 하네요.

일단 Character는 Copyable 프로토콜을 따릅니다.

그럼 Escapable은?

공식문서에서 찾아봐도 안 나오네요?

Swift 6에서 새롭게 도입된 프로토콜인 것 같은데... 일해라 애플

일단은 여기선 String과 Character가 Escapable 프로토콜을 준수한다고 하니, 참이라고 간주하고 이어가자면,

지금처럼 [Character]를 쓰는 케이스에선 RandomAccessCollection 프로토콜에 부합하는 Collection이니, O(1)의 시간복잡도로 count를 활용할 수 있을 것으로 추론했습니만...!

뻘짓이었습니다

그 문제가요...

사실 입력으로 String을 받는 경우였고...

String의 인스턴스 프로퍼티 count는 O(n)의 시간복잡도를 가진다고 공식문서에 명시되어 있네요.

그래도 지식이 늘었잖습니까?

한 잔 합시다.

그래도 오늘까지 배운 지식으로 추론해보면, 나중에 공식문서에서 String의 .count가 O(1)의 시간복잡도로 변경될 수도 있지 않을까? 하는 추측을 남겨놓습니다. 하지만 추론 과정 중, Array == Collection이지만 Collection != Array 이기에, 왠지 틀린 추측일 것 같아

수정합니다, 대신 위에 추측했던 것에 대한 논리 흐름을 남겨놓습니다:

1. RandomAccessCollection 프로토콜에 부합하는 Array의 count는 O(1)의 시간복잡도를 가진다.
2. Copyalbe과 Escapable 프로토콜에 부합하는 element로 이루어진 Array는 RandomAccessCollection이다.
3. String은 Collection 프로토콜을 따르며, String.element는 Character이다.
4. Character는 Copyable과 Escapable 프로토콜을 준수한다.
   따라서, [Character]의 .count는 O(1)의 시간복잡도를 가질 것이다.

졸려서 내일 확인해봐야겠네요.

괄호가 바르게 짝지어졌다는 것은 '(' 문자로 열렸으면 반드시 짝지어서 ')' 문자로 닫혀야 한다는 뜻입니다. 예를 들어:

"()()" 또는 "(())()" 는 올바른 괄호입니다. ")()(" 또는 "(()(" 는 올바르지 않은 괄호입니다.

'(' 또는 ')' 로만 이루어진 문자열 s가 주어졌을 때, 문자열 s가 올바른 괄호이면 true를 return 하고, 올바르지 않은 괄호이면 false를 return 하는 solution 함수를 완성해 주세요.

링크

1차 코드 작성

import Foundation
func solution(_ s:String) -> Bool {

    // 첫 문자가 ")" 경우 false를 리턴
    guard s.first == "(" else { return false }

    var answer = false
    var stack: [Character] = []
    for char in s {

        switch char {
        case "(": stack.append(char)
        case ")": stack.popLast()
        default:
            answer = false
            break
        }
    }
    if stack.isEmpty {
        answer = true
    }
    return answer
}

설명이 필요하지는 않을 것 같아 생략합니다.

1트 성공

아싸

헛점발견

근데 소소한 헛점을 발견해서 고쳤습니다.

switch char {
case "(": stack.append(char)
case ")": stack.popLast()
default:
    answer = false
    break
}

저기서 answer를 false로 설정해줘도 아래의 if문에서 stack이 비었으면 answer = true가 실행되기에 고쳐줬습니다.

switch char {
case "(": stack.append(char)
case ")": stack.popLast()
default:
    return false
}

물론, 로직 상 거의 발생하지 않을 문제이지만, 소 잃고 외양간 고치는 것 보다는 미리미리 방지하는 게 낫지 않습니까?

또 다른 헛점 발견

앞에 guard문 제대로 썼나 이것저것 집어넣어보다가 이걸 발견했습니다.

"())()"

이걸 집어넣으면 false를 리턴해야 하는데 true를 리턴하네요...?

않이?

근데 왜 통과시켜줘요 프로그래머스님아

여튼 고치긴 했습니다.

고친 코드

import Foundation

func solution(_ s:String) -> Bool {

    // 첫 문자가 ")"일 경우, 또는 마지막 문자가 "(" 일 경우,
    // 무조건 닫히지 않은 괄호이니, false를 리턴
    guard s.first == "(" || s.last == ")" else { return false }

    var answer = false
    var stack: [Character] = []

    for char in s {

        switch char {
        case "(": stack.append(char)
        case ")":
            // "())()"와 같은 케이스 걸러주기 위해,
            // popLast가 nil일 경우 false를 리턴하도록 작성.
            if stack.popLast() == nil { return false }
        default: // 문자열 중 괄호 외의 문자를 발견 시 false를 리턴하도록 하는
            return false
        }
    }

    if stack.isEmpty {
        answer = true
    }

    return answer
}

결과는?

통과입니다.

아니 그래서 글자수는 왜 안 셌음?

세볼까 생각을 했는데요, 그게 생각보다 간단한 문제가 아니더라고요. count의 시간복잡도가 O(n)이냐 O(1)이냐에 따라 다른데...

그게 자료형이 어떤 프로토콜을 따르는지에 따라 다르답니다. 이에 대해 찾아보다가 따로 글을 쓰게 되었습니다.

요약하자면, [Character]에서 .count를 쓰면, O(1)의 시간복잡도를, String에서 .count를 쓰면 O(n)의 시간복잡도를 가진다는 내용입니다.

그니까, 어차피 for-in 반복문 쓰면 O(n)의 시간복잡도가 비용으로 지불되는데, 그 전에 굳이 또 한 번의 O(n)을 들여서 글자수를 셀 필요가 없다는 것이죠.

그래서 안 셌습니다.

1. "이게 무슨 말이냐..."라고 의문이 드셨을 분,
2. "아 이 밈 중독자 [검열됨] 또 이러네"라고 생각하셨을 분,
3. "뭔가 사라지는 버그를 발견했나 보구만"이라고 눈치채신 눈치 빠른 분.

네.

이 포스트는 무언가 사라지는 버그를 잡는 과정을 기록한 포스트입니다.

이 글을 눈치 빠른 3번 유형의 사람들에게 바칩니다.

그래서 무슨 버그냐?

백문이 불여일견이라고, 일단 보여드리겠습니다.

네... 말이 필요없죠...

굳이 말로 풀어서 쓰자면, 음료 갯수를 더하거나 빼면 갯수를 표시해주는 라벨이 뒤틀리거나 사라지는 버그입니다.

아니 왜 이러는 걸까요?

생각을 해봅시다.

처음에는 말이죠...

연산 프로퍼티 didSet을 사용해서 라벨의 텍스트가 변경되는 방식이라, 그 녀석을 의심했습니다.

근데 암만 봐도 그건 아닌 것 같더라고요. 그랬다면 애초에 초기 설정부터 이상하게 되었을 테니까요.

라벨 레이아웃이 뒤틀리는 것으로 보아, 라벨을 설정해주는 함수를 라벨이 바뀔 때 마다 다시 호출해야 하나?라는 생각도 했습니다.

그리고 이런저런 생각을 머릿속으로 했지만 결과적으론 틀린 추론이었습니다.

그래서 답답한 마음에 계속해서 버그를 뚫어져라 보다보니 미묘한 점을 발견했습니다...

미묘한 움직임

버튼을 클릭할 때 가격 표시와 +/- 버튼이 움찔거리는 것이 보이시나요?

저기가 뭔가 의심스러웠습니다.

그리고 그 의심은 아래에서 점점 확신이 되어갔습니다.

계속 일부러 고장내보자

그래서 일부러 고장내고 View Hierarchy를 보고 단서를 찾으려고 하였습니다.

위의 View Hierarchy를 토대로, 아래와 같이 추측했습니다.

1. 음료의 갯수를 표현하는 숫자 라벨의 너비가 변경됨 (1 >> 2나 9 >> 10 처럼 너비가 크게 변하면)
2. 그 숫자 라벨을 둘러싸고 있는 -/+ 버튼의 위치가 오락가락함.
3. 숫자가 바뀌면서 오락가락하다가 뷰가 무너짐. (이에 대한 정확한 명칭은 잘 모르겠습니다...)

그래서...?

설마 숫자 라벨에 constraint가 적용이 안 되어서 와장창 무너진 것은 아닌가?

라는 가설을 세우고, 해결하기 위해 아래 코드로 숫자 라벨의 widthAnchor와 heightAnchor의 constraint를 지정해줬습니다.

label.translatesAutoresizingMaskIntoConstraints = false

NSLayoutConstraint.activate([
    label.widthAnchor.constraint(equalToConstant: 10)
    label.heightAnchor.constraint(equalToConstant: 10)
])

문제가 확인되었을까요?

빌드를 눌러서 확인해봅시다.

빌드가 안되네?

아

급하게 하느라 쉼표를 까먹었읍니다

ㅎㅎㅎ...

넣어주고 다시 해봅시다.

잡았다 요놈

오...!

좀 찌부되긴 했는데 여튼 일단 해결했잖습니까?

해결 방법을 발견하고 신나서 버그를 발견한 팀원에게 자랑을 하고 밥을 먹으러 갔습니다.

근데 밥을 먹고 온 사이 팀원이 코드를 수정하였다네요...?

어... 음... 떠넘기려는 건 아니었는데 그게... 그렇게 보이긴 하네요;

열심히 일한 우리 팀원에게 큰 박수 부탁드립니다.

여튼 팀원이 수정해준 최종 결과물은 이렇습니다:

최종 결과물

깔끔하네요.

It ain't over, 'til it's over

이렇게 해피해피엔딩이었다면 좋았겠지만...

저희 팀은 또 다른 문제를 맞닥뜨리게 됩니다.

(대충 다음에 계속된다는 소리)

스트리밍 사이트에서 장르 별로 가장 많이 재생된 노래를 두 개씩 모아 베스트 앨범을 출시하려 합니다. 노래는 고유 번호로 구분하며, 노래를 수록하는 기준은 다음과 같습니다.

1. 속한 노래가 많이 재생된 장르를 먼저 수록합니다.
2. 장르 내에서 많이 재생된 노래를 먼저 수록합니다.
3. 장르 내에서 재생 횟수가 같은 노래 중에서는 고유 번호가 낮은 노래를 먼저 수록합니다.
   노래의 장르를 나타내는 문자열 배열 genres와 노래별 재생 횟수를 나타내는 정수 배열 plays가 주어질 때, 베스트 앨범에 들어갈 노래의 고유 번호를 순서대로 return 하도록 solution 함수를 완성하세요.

링크

처음 든 생각

해쉬 문제니까 Dictionary 갖고 풀면 되겠다!라고 생각이 들어서, hashMap이라는 이름의 딕셔너리 변수를 선언해주었습니다. 이렇게요:

var hashMap: [String: [Int]] = [:]

Key가 될 String에는 장르 이름이 들어가고, Value가 될 [Int]에는 노래의 인덱스, 재생 횟수 등이 들어가게 말이죠.

근데 생각해보니까 장르의 총 재생 횟수, 곡 별로 재생 횟수도 비교해야 되더라고요.

그래서 그냥 구조체를 만들었습니다 ㅎ

struct GenreDetails {
    private(set) var songs: [Song] = []
    private(set) var totalPlays: Int = 0

    mutating func addSong(_ song: Song) {
        songs.append(song)
        totalPlays += song.played
    }
}

struct Song {
    let played: Int
    let index: Int
}

그래서 요 구조체들이...

var hashMap: [String: GenreDetails] = [:]

요렇게 들어갈 수 있게요.

테스트나 함 돌려봅시다.

근데 [String: GenreDetails]라고 되어있으니 통일성이 좀 모자라서 마음이 불편해지네요.

Typealias를 사용해서 Genre로 String을 둔갑시켜줍니다.

typealias Genre = String

이러면 이제 String의 별칭으로 Genre를 쓸 수 있게 되구요,

var hashMap: [Genre: GenreDetails] = [:]

요런 편안하고 깔끔한 코드가 되게 됩니다.

그 뒤로는 그냥 문제 읽으면서... 적절히 코드를 작성해줬구요.

아래의 코드가 나왔습니다.

코드

import Foundation

typealias Genre = String

struct GenreDetails {
    private(set) var songs: [Song] = []
    private(set) var totalPlays: Int = 0

    mutating func addSong(_ song: Song) {
        songs.append(song)
        totalPlays += song.played
    }
}

struct Song {
    let played: Int
    let index: Int
}

func solution(_ genres:[String], _ plays:[Int]) -> [Int] {
    var hashMap: [Genre: GenreDetails] = [:]
    var result: [Int] = []

    for index in 0..<genres.count {
        let song = Song(played: plays[index], index: index)
        hashMap[genres[index], default: GenreDetails()] .addSong(song)
    }

    let sortedByTotalPlays = hashMap.sorted { (first, second) in
        return first.value.totalPlays > second.value.totalPlays
    }

    for genre in sortedByTotalPlays {

        switch genre.value.songs.count {
        case 1: result.append(genre.value.songs[0].index)
        case 2:
            let first = genre.value.songs[0]
            let second = genre.value.songs[1]

            if first.played > second.played {
                result.append(first.index)
                result.append(second.index)
            } else if first.played < second.played {
                result.append(second.index)
                result.append(first.index)
            }
        case 3...:
            var inOrder = genre.value.songs.sorted { $0.played < $1.played }

            let last = inOrder.popLast()
            let secondLast = inOrder.popLast()

            result.append((last?.index)!)
            result.append((secondLast?.index)!)


        default: print("error")
        }
    }

    return result
}

테스트도?

통과하는군요.

그럼 이대로 채점까지 ㄱㄱ합시다.

그런데...

넌 못지나간다를 시전하는 프로그래머스씨...

않이외않돼는거야

빡침을 잠시 가라앉히고 문제를 다시 읽어보고 옵시다...

간과한 것

3. 장르 내에서 재생 횟수가 같은 노래 중에서는 고유 번호가 낮은 노래를 먼저 수록합니다.

신나게 문제 푸느라 마지막 기준을 그냥 무시해버려서... 안되었던 것입니다...

그래도 조건문 몇 개만 추가해주면 되니 얼른 가서 고치고 옵시다.

고친 코드

import Foundation

struct GenreDetails {
    private(set) var songs: [Song] = []
    private(set) var totalPlays: Int = 0

    mutating func addSong(_ song: Song) {
        songs.append(song)
        totalPlays += song.played
    }
}

struct Song {
    let played: Int
    let index: Int
}

func solution(_ genres:[String], _ plays:[Int]) -> [Int] {
    var hashMap: [String: GenreDetails] = [:]
    var result: [Int] = []

    for index in 0..<genres.count {
        let song = Song(played: plays[index], index: index)
        hashMap[genres[index], default: GenreDetails()] .addSong(song)
    }

    let sortedByTotalPlays = hashMap.sorted { (first, second) in
        return first.value.totalPlays > second.value.totalPlays
    }

    for genre in sortedByTotalPlays {

        switch genre.value.songs.count {
        case 1: result.append(genre.value.songs[0].index)
        case 2:
            let first = genre.value.songs[0]
            let second = genre.value.songs[1]

            if first.played > second.played {
                result.append(first.index)
                result.append(second.index)
            } else if first.played < second.played {
                result.append(second.index)
                result.append(first.index)
            } else if first.index < second.index {
                result.append(first.index)
                result.append(second.index)
            } else if first.index > second.index {
                result.append(second.index)
                result.append(first.index)
            }
        case 3...:
            var inOrder = genre.value.songs.sorted { $0.played < $1.played }

            let last = inOrder.popLast()
            let secondLast = inOrder.popLast()

            if last?.played == secondLast?.played && last!.index > secondLast!.index {
                result.append((secondLast?.index)!)
                result.append((last?.index)!)
            } else {
                result.append((last?.index)!)
                result.append((secondLast?.index)!)
            }

        default: print("error")
        }
    }

    return result
}

그래서?

잘 됐을까요?

예압

근데 말이죠

코드가 좀 지저분하기도 하고, 가장 큰 두 녀석을 뽑을 때 .sorted을 쓰기는 시간복잡도가 O(n log n)이라 아무래도 좀 마음이 불편하단 말이죠.

그러니 두 가지를 목표로 코드를 수정해봅시다.

1. 지저분한 코드 깔끔하게 변경하기
2. .sorted 대신 다른 방법으로 가장 재생횟수가 높은 두 곡 뽑기

1. 지저분한 코드 깔끔하게 변경하기

지저분한 코드에 가장 큰 지분을 차지하는 반복문을 가지고 왔습니다.

for genre in sortedByTotalPlays {

    switch genre.value.songs.count {
    case 1: result.append(genre.value.songs[0].index)
    case 2:
        let first = genre.value.songs[0]
        let second = genre.value.songs[1]

        if first.played > second.played {
            result.append(first.index)
            result.append(second.index)
        } else if first.played < second.played {
            result.append(second.index)
            result.append(first.index)
        } else if first.index < second.index {
            result.append(first.index)
            result.append(second.index)
        } else if first.index > second.index {
            result.append(second.index)
            result.append(first.index)
        }
    case 3...:
        var inOrder = genre.value.songs.sorted { $0.played < $1.played }

        let last = inOrder.popLast()
        let secondLast = inOrder.popLast()

        if last?.played == secondLast?.played && last!.index > secondLast!.index {
            result.append((secondLast?.index)!)
            result.append((last?.index)!)
        } else {
            result.append((last?.index)!)
            result.append((secondLast?.index)!)
        }

    default: print("error")
    }

으...

눈쌀이 찌푸려지는군요

밑에 2번에서 만들 getTwoMaxValues 메서드로 대체해줍니다.

for genre in sortedByTotalPlays {

    if genre.value.songs.count == 1 {
        result.append(genre.value.songs[0].index!)
    } else if genre.value.songs.count >= 2 {
        result.append(contentsOf: genre.value.getTwoMaxValues())
    }
}

한결 낫네요.

2. .sorted 대신 다른 방법으로 가장 재생횟수가 높은 두 곡 뽑기

GenreDetail 구조체 내부에 새로운 메서드를 선언해줍니다.

가장 많은 플레이 수를 기록한 2곡을, 그리고 플레이수가 가장 많은 곡이 동일하면 인덱스가 적은 친구를 반환하도록 해줍니다.

func getTwoMaxValues() -> [Int] {
    var first = Song()
    var second = Song()

   // 반복문을 한번만 거치기에 시간복잡도가 O(n)이 됩니다.
    for song in songs {
        if song.played > first.played {
            second = first
            first = song
        } else if song.played > second.played {
            second = song
        }
    }

    if first.played == second.played && first.index! > second.index! {
        return [second.index!, first.index!]
    } else {
        return [first.index!, second.index!]
    }
}

옵셔널 강제 추출을 좋아하진 않지만, 추후 호출이 될 때, Song이 두 개 이상 들어있는 Array에서만 호출을 하기 때문에 로직 상 안전할 것 같아서 강제 추출을 때려버렸습니다.

그래서...

최종 코드

import Foundation

typealias Genre = String

struct GenreDetails {
    private(set) var songs: [Song] = []
    private(set) var totalPlays: Int = 0

    mutating func addSong(_ song: Song) {
        songs.append(song)
        totalPlays += song.played
    }

    func getTwoMaxValues() -> [Int] {
        var first = Song()
        var second = Song()

        for song in songs {
            if song.played > first.played {
                second = first
                first = song
            } else if song.played > second.played {
                second = song
            }
        }

        if first.played == second.played && first.index! > second.index! {
            return [second.index!, first.index!]
        } else {
            return [first.index!, second.index!]
        }
    }
}

struct Song {
    let played: Int
    let index: Int?

    init() {
        self.played = 0
        self.index = nil
    }

    init(played: Int, index: Int?) {
        self.played = played
        self.index = index
    }
}

func solution(_ genres:[String], _ plays:[Int]) -> [Int] {
    var hashMap: [Genre: GenreDetails] = [:]
    var result: [Int] = []

    for index in 0..<genres.count {
        let song = Song(played: plays[index], index: index)
        hashMap[genres[index], default: GenreDetails()] .addSong(song)
    }

    let sortedByTotalPlays = hashMap.sorted { (first, second) in
        return first.value.totalPlays > second.value.totalPlays
    }

    for genre in sortedByTotalPlays {

        if genre.value.songs.count == 1 {
            result.append(genre.value.songs[0].index!)
        } else if genre.value.songs.count >= 2 {
            result.append(contentsOf: genre.value.getTwoMaxValues())
        }
    }

    return result
}

잘 되는군요.

근데 사실...

1.의 반복문에서

else if genre.value.songs.count >= 2 {
    result.append(contentsOf: genre.value.getTwoMaxValues())
}

요 부분은 count가 2일때 약간의 성능 상 손해보는 부분이 있긴 합니다.

getTwoMaxValues()메서드를 거칠 필요 없이 두 노래의 재생횟수를 비교하면 되는데, 메서드를 거침으로써 약간의 손해를 봐서 그렇습니다.

극한의 성능을 쥐어짜야한다면 저것까지도 고려하는 것이 좋겠습니다.

여튼 여기까지만 해야겠네요.

일단 가로로 뻗은 버튼스택을 만들어줄 메서드 makeHorizontalButtonStack()을 작성해봅시다.

class ViewController: UIViewController {

    // 이전 코드 생략
    let buttonLayout = [
        "7", "8", "9", "+"
//        "4", "5", "6", "-",  일단
//        "1", "2", "3", "*",  한줄만 
//        "AC", "0", "=", "/", 생성하기.
    ]

    // 중략

    private func makeHorizontalButtonStack(with buttonLayout: [String]) -> UIStackView {
        let buttonStack = UIStackView()

        buttonLayout.forEach {
            let button = Button(title: $0)

            button.snp.makeConstraints {
                $0.width.height.equalTo(80)
            }

            buttonStack.addArrangedSubview(button)
        }

        buttonStack.axis = .horizontal
        buttonStack.backgroundColor = .black
        buttonStack.spacing = 10
        buttonStack.distribution = .fillEqually

        return buttonStack
    }

}

이렇게 해서 만들어진 UIStackView를 configureUI에 넣고 실행해주면?

class ViewController: UIViewController {

    let label = UILabel()
    let buttonLayout = [
        "7", "8", "9", "+"
//        "4", "5", "6", "-",
//        "1", "2", "3", "*",
//        "AC", "0", "=", "/",
    ]

    override func viewDidLoad() {
        super.viewDidLoad()
        configureUI()
    }

    private func configureUI() {
        let buttonStacks = makeHorizontalButtonStack(with: buttonLayout)

        numberLabel()
        view.addSubview(buttonStacks)

        buttonStacks.snp.makeConstraints {
            $0.top.equalTo(label.snp.bottom).offset(50)
            $0.centerX.equalToSuperview()
        }

    }
    // 후략
}

이런 게 나온다!

와!

의도했던 대로 기호를 넣으니까 저절로 색상이 설정되는 것이 아주 마음이 편안하군요.

한번 다른 녀석들로도 시험해봅시다.

바람직하군요.

근데 생각을 해보니까 buttonLayout을 2차원 배열([[String]])으로 만들면 더 깔끔하게 가능하지 않을까라는 생각이 듭니다.

바로 실행해줍니다.

class ViewController: UIViewController {

    let buttonLayout = [
        ["7", "8", "9", "+"],
        ["4", "5", "6", "-"],
        ["1", "2", "3", "*"],
        ["AC", "0", "=", "/"]
    ]

    // 후략
}

이렇게 buttonLayout을 2차원 배열로 변경해주고,

아까 만들었던 메서드 makeHorizontalButtonStack을 활용한 새로운 메서드 makeButtonStack을 만들어서,

class ViewController: UIViewController {

// 생략

    private func makeButtonStack(with buttonLayout: [[String]]) -> UIStackView {
        let verticalStack = UIStackView()

        buttonLayout.forEach {
            let horizontalStack = makeHorizontalButtonStack(with: $0)

            verticalStack.addArrangedSubview(horizontalStack)
        }

        verticalStack.axis = .vertical
        verticalStack.backgroundColor = .black
        verticalStack.spacing = 10
        verticalStack.distribution = .fillEqually

        return verticalStack
    }

}

이렇게 해주면?

짜쟌.

아주 오이시하고 우마이합니다.

덤으로 버튼 연결도 확인해 봤는데,

잘 되었군요.

이히히히히히히히힣

혹시나 하는 마음에 (저번 숫자야구처럼) 어디선가 루프를 만들었는데 모르고 있는건 아닌지 확인하려고 스레드도 살펴봤습니다.

별일... 없어보이죠?

넘어갑시다...

근데 UI는 이제 다 짠 거 아닌가...?

제목을 "로직을 만들어보자"로 해서 새로운 글을 만든 뒤에 계속 진행해봅시다.

다음 글에서 뵙겠습니다.

Lv. 1에선 계산기의 메인 숫자 라벨을 만들어 줄 겁니다.

음... 뭔가 글을 쓸 만한 껀덕지가 없네요.

일단 사용한 코드 먼저 봅시다.

코드

import UIKit
import SnapKit

class ViewController: UIViewController {

    let label = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        configureUI()
    }

    private func configureUI() {

        view.backgroundColor = .black

        label.text = "12345"
        label.font = .boldSystemFont(ofSize: 60)
        label.textColor = .white
        label.textAlignment = .right

        view.addSubview(label)

        label.snp.makeConstraints { make in
            make.leading.trailing.equalToSuperview().inset(30)
            make.top.equalToSuperview().inset(200)
            make.height.equalTo(100)
        }

    }

}

이렇게 썼고

이렇게 나왔습니다.

나중에 엄청 수정될 예정이니 다음으로 넘어가겠습니다.

Lv. 2 ~ 5

를 진행하기 전에...

다음 단계들을 쓱 훑어보니, 여러 생각이 들었습니다.

나열하자면:

1. 버튼 위치를 차후에 변경하려면 번잡할 것 같다.
2. 각 버튼 별 역할(숫자, 연산자, 변형자)에 따라 색상이 달라져야 하는데, 일일히 지정해 주기 싫다.
3. 나중에 로직을 구현하면서 위에 말한 각 버튼 별 역할에 따라 동작을 달리 해줘야 할 것 같은데, 코드가 지저분해질 것 같다.

그래서 다음과 같은 조치를 취하였습니다:

1. 버튼 위치를 차후에 변경하기 쉽게 하자

buttons라는 [String]을 생성해 원하는 버튼을 배열 안에 제가 지정해주면 추후 버튼을 생성할 때 forEach를 사용해서 할 생각으로 만들었습니다.

뭐 이런↓ 느낌이죠?

// 이전 코드는 적절히 생략되었습니다.

class ViewController: UIViewController {

    let buttons: [String] = [
        "7", "8", "9", "+",
        "4", "5", "6", "-",
        "1", "2", "3", "*",
        "AC", "0", "=", "/",
    ]

// 이후 코드 또한 적절히 생략되었습니다.

나중에 할 때 잘... 되겠죠...? (뉴비라해보기전까지될지안될지진짜모름)

2. 각 버튼 별 역할에 따라 색상이 자동으로 달라지게 하자

그러기 위해서 버튼의 유형을 먼저 enum으로 나누어주었습니다.

이렇게↓요.

enum ButtonRole {
    case number // 숫자 (0...9)
    case operation // 연산자 (operator를 쓸랬는데 예약어 크리...)
    case modifier // 변형자 (AC, 하나 지우기 등)
    case undefined // 미지의 존재 (몰라 이거 뭐야 무서워)
}

그 다음에 Button 클래스에서 입력받을 title에 따라 자동으로 지정되게 해주었습니다.

연산 프로퍼티(computed property)를 사용해서 말이죠.

class Button: UIButton {
    var title: String

    var buttonRole: ButtonRole {
        if self.title.isNumber {
            return .number
        }

        switch self.title {
        case "+", "-", "*", "/": return .operation
        case "AC", "+/-", "%": return .modifier
        default: return .undefined
        }
    }

 // 적절한 중략

 extension String {
    var isNumber: Bool {
        CharacterSet(charactersIn: self).isSubset(of: .decimalDigits)
    }    
}

여담이지만 변수명을 buttonRole 대신 role, type을 쓰려고 했는데 이미 UIButton에 있어서... 어쩔 수 없이 buttonRole으로 지었습니다.

이렇게 입력받은 title의 값을 이용해서 buttonRole을 지정해줬으니, 버튼 색 또한 자동으로 지정되게 해 볼까요?

class Button: UIButton {
    var title: String
    var buttonRole: ButtonRole { ... }

    var color: UIColor {
        switch self.buttonRole {
        // 일단은 임의의 색을 지정해줍니다.
        case .number: UIColor(red: 58/255,
                           green: 58/255,
                           blue: 58/255,
                           alpha: 1.0)
        case .operation: UIColor.systemOrange
        case .modifier: UIColor.systemGray
        case .undefined: UIColor.systemRed
        }

    }    
    // 후략
}

이렇게 또 한번 연산 프로퍼티를 이용하여 색이 적절히 지정되게 해 줍니다.

그럼 이걸 써먹어야 하겠죠?

이니셜라이징 후 버튼에 대한 세부사항을 설정해주는 메서드를 만듭시다.

// 이전 코드 생략

    init(title: String) {
        self.title = title
        super.init(frame: .zero)

        setButton()
    }

    func setButton() {
        setTitle(self.title, for: .normal)
        titleLabel?.font = .boldSystemFont(ofSize: 30)
        backgroundColor = color
        frame.size = CGSize(width: 80, height: 80)

        let action = #selector(onTap)
        addTarget(self, action: action, for: .touchDown)
    }

    @objc func onTap(_ sender: UIButton) {
        let title = sender.titleLabel?.text

        print("\(title ?? "error") tapped")
    }

요렇게요.

3. 로직을 구현하면서 위에 말한 각 버튼 별 역할에 따라 동작을 달리 해주자

는 위에서 설명이 되었네요.

넘어가겠습니다.

뭔가 성의 없다고 느껴지신다면 그게 정상입니다.

잠을 제대로 못 자서 제 정신이 아니거든요.

진짜 쓰러질 것 같으니 이만 자러가겠습니다.

(다음 시간에 계속...)

짜장이냐 짬뽕이냐, 김치찌개냐 된장찌개냐, 물복이냐 딱복이냐.

이런 논쟁들이 때론 과격해지기도 합니다.

이렇게 말이죠.

오죽하면, 인생은 B와 D사이의 C라는 말이 존재할 정도입니다. 많이들 들어보셨겠지만, Birth와 Death 사이의 Choice라는 말이죠.

아니라고요?

치킨이라고요?

어...

알파벳 기준으로 Birth와 Death 사이의 Chicken이고, 한글 기준으로 탄생(ㅌ)과 죽음(ㅈ) 사이의 치킨(ㅊ, ㅋ)이니 틀린 말이 아니긴 합니다.

치킨먹고싶네요.

뭐 여튼간에, Swift에서도 이러한 선택들이 존재합니다.

구조체를 쓸 것이냐 클래스를 쓸 것이냐, UIKit을 쓸 것인가 SwiftUI를 쓸 것이냐, 고차함수를 쓸 것인가 반복문을 쓸 것이냐.

오늘은 고차함수와 반복문의 차이점에 대해 알아보겠습니다.

고차함수? 그게 뭔데?

map, filter, reduce처럼 클로저(익명함수)를 전달받는 함수를 뜻합니다.

let 김치찌개: [String] = ["김", "치", "찌", "개"]

let 변형된김치찌개 = 김치찌개.map { $0 + $0 }
let 졸여진김치찌개 = 김치찌개.reduce("", +)
let 걸러진김치찌개 = 김치찌개.filter { "찌개".contains($0) }

print(변형된김치찌개) // ["김김", "치치", "찌찌", "개개"]
print(졸여진김치찌개) // 김치찌개
print(걸러진김치찌개) // ["찌", "개"]

대표적인 map, filter, reduce 말고도 더 있긴 한데 일단 3개만 예를 들었습니다.

같은 코드를 반복문으로 볼까요?

let 김치찌개: [String] = ["김", "치", "찌", "개"]

var 변형된김치찌개: [String] = []
for item in 김치찌개 {
    변형된김치찌개.append(item + item)
}

var 졸여진김치찌개: String = ""
for item in 김치찌개 {
    졸여진김치찌개 += item
}

var 걸러진김치찌개: [String] = []
for item in 김치찌개 {
    if "찌개".contains(item) {
        걸러진김치찌개.append(item)
    }
}

print(변형된김치찌개) // ["김김", "치치", "찌찌", "개개"]
print(졸여진김치찌개) // 김치찌개
print(걸러진김치찌개) // ["찌", "개"]

뭐 대략 이런 느낌입니다.

그래서 둘 중 뭐가 더 빠르냐? 뭘 어떨 때 써야 하느냐? 라는 질문에는,

일단 결론부터 요약하자면:

1. 고차함수만 사용할 경우는 대개 고차함수가 빠르다.
2. 그러나 메서드 체이닝을 하게 된다면, 반복문이 빠르다.

글로만 보니 조금 모호하죠?

차례대로 예를 들어가며 설명하겠습니다.

아래의 내용은 이 문서의 요약본이며, 원문을 읽어보시는 것을 추천드립니다.

1. 고차함수만 사용할 경우에는 대개 고차함수가 빠르다.

이 문서에 따르면, 실험을 진행했을 때:

1. map 함수가 반복문보다 1.63배,

2. filter 함수가 반복문보다 1.11배 빠르지만,

3. reduce와 flatMap의 경우, 반복문이 각각 1.05배, 1.06배 빠른 것을 볼 수 있습니다.

다만...

2. 메서드 체이닝을 하게 된다면, 반복문이 빠르다.

메서드 체이닝이 뭐죠?

let 김치찌개: [String] = ["김", "치", "찌", "개"]

// 일반적인 사용
let 변형된김치찌개 = 김치찌개.map { $0 + $0 }
let 졸여진김치찌개 = 김치찌개.reduce("", +)
let 걸러진김치찌개 = 김치찌개.filter { "찌개".contains($0) }

// 메서드 체이닝
let 변형되고졸여지고걸러진김치찌개 = 김치찌개.map { $0 + $0 }.reduce("", +).filter { "찌개".contains($0) }

print(변형된김치찌개) // ["김김", "치치", "찌찌", "개개"]
print(졸여진김치찌개) // 김치찌개
print(걸러진김치찌개) // ["찌", "개"]
print(변형되고졸여지고걸러진김치찌개) // 찌찌개개

요래... 스까서 쓰는 걸 메서드 체이닝이라고 합니다.

map + filter + reduce

이렇게 위 3개의 고차함수를 섞어서 쓸 경우, 각자 O(n)의 시간복잡도를 가지고 있는 관계로 (출처), for-in을 사용한 반복문에 비해 2.37배 느린 것을 확인할 수 있습니다.

긍까 방대한 데이터를 다룰 땐 지양하는 것이 좋겠다...가 결론이 되겠군요.

파생되는 의문점

1. 메서드 체이닝을 하는 대신 Collection의 extension으로 커스텀 함수를 만들어서 쓴다면 똑같은 반복문보다 성능이 좋게 나올까?
2. 스택 오버플로우 댓글 중에 Playground는 최적화된 컴파일로 실행되지 않는다는 내용을 봤는데 사실인지?
3. 고차함수는 lazy evaluation을 사용할 수 있는데, 사용 시 반복문 대비 얻는 이점이 체이닝을 해도 될 정도일까?

이건 다음 시간에 알아보도록 하겠습니다...

참고한 페이지들: Are higher-order functions more efficient than a for-in loop in Swift? Swift performance: map() and reduce() vs for loops Performance of built-in higher-order functions Map, Filter, Reduce, and flatMap vs. for-in loop in Swift Loops and Maps : Who is faster? Time and Space complexity , we are coming!!! [Swift] map 파헤치기

Lv. 3

정답이 되는 숫자를 0에서 9까지의 서로 다른 3자리의 숫자로 바꿔주세요

라는데... 뭐지 나 이거 Lv. 1에서 해버렸는디...

대충 럭키비키자나를 외치며 다음 단계로 넘어갑시다.

Lv. 4

눈치 챘을 수도 있지만, 저번 포스팅에 임시로 만들어 놓은 안내문구는, 말투를 살짝 문명 5 킹갓세종대왕님의 그것을 따라했으니, 지금 만드는 안내 문구도 비슷하게 만들어 보았다.

뭐 대충 이런 느낌으로다가. 사진 출처 - 유튜브 궁능TV

쉬워보이니까 후딱 만들고 다음 단계로 넘어갑시다.

import Foundation

print("숫자야구↗ 게임에↘ 당도한것을→ 환영하오↘ 낯↘선↗이여↘")

mainPage()

func mainPage() {
    print("원하는 번호를 입력하게나.")
    print("1. 놀이 시작하기 2. 놀이 기록 보기. 3. 종료하기")

    let input = readLine()

    switch input {
    case "1": playGame()
    default: print("유효하지 않은 입력이네.")
    }
}

func playGame() {
    var game = NumberBaseball()
    // (중략)
    print("숫자를 입력하게나.")

    while !hadRightGuess {
        let input = Array(readLine()!)

        if input == game.answer {
            hadRightGuess = true
            print("축하하네, 정답이군.")
            mainPage()
        }

        if input.first == "0" {
            print("첫 번째 자리는 0이 들어가지 않는다네.")
        } else if input.count == 3
            && input[0] != input[1]
            && input[0] != input[2]
            && input[1] != input[2] {
            print("\(game.umpireCall(for: input).strike) 스트라이크, \(game.umpireCall(for: input).ball) 볼.")
        } else {
            print("3자리의 서로 중복되지 않는 숫자만 입력이 가능하네.")
        }
    }
}

...

라고 생각하고 만들다가 버그를 만났습니다.

버그버그

무슨 버그냐?

게임을 몇 번 진행하고 나서 메인페이지에서 게임을 종료하면 이전에 진행했던 게임 중 맞췄던 정보가 남아있는 버그입니다.

스샷을 보면 이해가 되실 겁니다.

아니 저게 저기서 왜 나오죠?

왤까요?

컴퓨터는 굉장히 정직하고 착하고 진실된 종입니다.

제가 시킨 대로 충실히 임무를 수행했죠.

playGame() 안에 있는 while 문을 다시 한번 찬찬히 뜯어볼까요?

while !hadRightGuess {
    let input = Array(readLine()!)

    if input == game.answer {
        hadRightGuess = true
        print("축하하네, 정답이군.")
        mainPage()
    }

    if input.first == "0" {
        print("첫 번째 자리는 0이 들어가지 않는다네.")
    } else if input.count == 3
                && input[0] != input[1]
                && input[0] != input[2]
                && input[1] != input[2] {
        print("\(game.umpireCall(for: input).strike) 스트라이크, \(game.umpireCall(for: input).ball) 볼.")
    } else {
        print("3자리의 서로 중복되지 않는 숫자만 입력이 가능하네.")
    }
}

왜 버그가 났는지 아시겠나요?

코드 일부만 떼어서 보겠습니다.

if input == game.answer {
    hadRightGuess = true
    print("축하하네, 정답이군.")
    mainPage()
}

답을 맞추면 실행되는 코드인데요,

맞추고 나면 mainPage() 함수를 호출해 다시 메인페이지가 불러지는 구조입니다.

문제는 여기서 발생합니다.

저 코드는 while문 안에 있는 코드죠?

즉:

1. playGame()의 안에서 mainPage()를 호출하는 바람에 기존의 while문은 종료되지 않고 계속 남아있는 와중에,
2. mainPage()에서는 다시 새로운 playGame()을 호출하여 또 다시 게임을 진행합니다. 그리고 또 맞추면 1.로 돌아가 반복되다가,
3. mainPage()에서 새 게임을 시작하지 않고 종료하면
4. 1.에서 멈춰있던 while문들이 한번에 풀려나게 되어, 그 아래의 if문으로 들어가서 프린트가 되어버린 것입니다.

아니 그럼 저기 mainPage() 뒤에다가 break 문 넣어주면 장땡 아닌가요?

while !hadRightGuess {
    let input = Array(readLine()!)

    if input == game.answer {
        hadRightGuess = true
        print("축하하네, 정답이군.")
        mainPage()
        break
    }
    // 후략...

이렇게 말이죠?

물론 이렇게 하면 겉보기엔 괜찮아 보입니다.

근데 보이지 않는 문제가 있습니다...

이해를 돕기 위해 print문 하나를 추가해보겠습니다.

while !hadRightGuess {
    let input = Array(readLine()!)

    if input == game.answer {
        hadRightGuess = true
        print("축하하네, 정답이군.")
        mainPage()
        print(game)
        break
    }
    // 후략...

실행 결과입니다.

눈치... 채셨나요?

mainPage() 함수 뒤에 모든 것들이, mainPage() 함수가 종료될 때까지 실행되지 않고 있다는 것입니다...

심각성을 알아보기 위해 몇 번 더 돌려볼까요?

(등골이 오싹)

아주 끔찍한 일이 일어날 수 있는 경우입니다.

물론 지금은 텍스트 기반의 아주 간단한 게임이라, 어지간히 쌓여도 요즘같이 컴퓨팅 파워가 발달한 경우에는 티도 안나겠죠.

근데 만약 이게 복잡한 앱이었고, 필요없는 데이터가 저렇게 계속 쌓인다면?

좋지 않은 일이 일어날 것입니다.

그래서 어떻게 해결했냐고요?

의외로... 간단했습니다. 아까 break문을 넣었을 때의 코드를 갖고 올까요?

while !hadRightGuess {
    let input = Array(readLine()!)

    if input == game.answer {
        hadRightGuess = true
        print("축하하네, 정답이군.")
        mainPage()
        break
    }
    // 후략...
}

mainPage를... while 문 바깥으로 옮겨주면 해결되는 문제였습니다...

while !hadRightGuess {
    let input = Array(readLine()!)

    if input == game.answer {
        hadRightGuess = true
        print("축하하네, 정답이군.")
        break
    }
    // 후략...
}
mainPage()

이런 식으로 말이죠...?

이러면 while문이 mainPage()가 호출되기 전에 종료되니 해피엔딩 아닐까요?

그런데 말입니다...

겉 보기엔 문제가 없어 보이죠...?

응 아니야 해결 안 됐어 돌아가

하지만 뭔가 찝찝한 마음에 스레드를 관찰해보기로 했습니다...

사용이 끝난 NumberBaseball의 인스턴스가 종료되지 않고 남아있던 것이었습니다....!

꺄아아아아아아아아ㅏㅏㅏㅏㅏㅏㅏㅏㅏ악

그래서 어떻게 해결했냐고요? (2트)

playGame()에서 mainPage()를 찾아볼 수 없게 피의 숙청을 감행했습니다.

그리고 keepPlaying이라는 boolean 변수를 생성해 playGame()의 밖에서, mainPage()가 계속 호출될 수 있게 해주었습니다.

그랬더니?

깔-꼼해진 스레드를 볼 수 있습니다. 아이신나

Lv. 5와 Lv.6...

나는 위 레벨에 대한 실로 놀랍게도 간단한 코딩법을 발견했다.

하지만 여백이 부족하여 이를 적지 않겠다... 는 아니구요...

다 써놓고 수정하는 와중에 글이 한 번 날아가서 현타와서 안 쓸겁니다...

임시저장 눌렀다고........................ 왜 다 날라갔냐고......................

그냥 제 깃허브에서 코드를 보시길 바랍니다.

https://github.com/dev-hamin-kim/NumberBaseball

그럼