• STEP 1 : 큐 타입 구현
  • 고민했던 것
  • 의문점
  • Trouble Shooting
  • 배운 개념
  • PR 후 개선사항
• STEP 2 : 타입 구현 및 콘솔앱 구현
  • 고민했던 것
  • 의문점
  • Trouble Shooting
  • 배운 개념
  • PR 후 개선사항
• STEP 3 : 다중 처리
  • 고민했던 것
  • 의문점
  • Trouble Shooting
  • 배운 개념
• STEP 4 : UI 구현
  • 고민했던 것
  • 의문점
  • Trouble Shooting
  • 배운 개념

은행에 도착한 고객이 임시로 대기할 대기열 타입을 구현합니다.

• 양방향 LinkedList vs 단방향 LinkedList
  • 서로 이야기를 나누면서 단방향으로도 충분히 큐를 구현할 수 있다는 생각이 듦.
  • 노드를 클래스로 만들고 참조를 활용하여 모든 노드를 연결할 수 있게 구현하였다.
• 테스트를 위한 Mock 타입 생성
  • 테스트 진행시 Node, LinkedList의 head, tail의 요소를 접근하여 테스트 결과를 확인했다.
  • 해당 요소들은 외부에서 접근하면 안된다는 판단이 들어서 따로 MockLinkedList를 만들어주어 원활한 테스트를 할 수 있도록 구현하였다.
• attribute를 활용
  • 반환 값을 유의미하게 사용하지 않고 버려도되는 remove 관련 메소드에 속성 @discardableResult을 부여하여 컴파일러 경고가 발생하지 않도록 하였다.

• if vs guard

  // 1. if 구문
  func removeFirst() -> Element? {
      if isEmpty {
          return nil
      }
      let result = head?.value
      head = head?.next
      
      return result
  }

  // 2. guard 구문
  func removeFirst() -> Element? {
      guard isEmpty == false else {
          return nil
      }
      let result = head?.value
      head = head?.next
      
      return result
  }

• if문으로 구현 시 조건문이 깔끔하게 isEmpty로 맞아떨어지기 때문에 코드의 가독성이 좋다고 생각했다.

  • guard문이든 if문이든 메소드 시작부문에서 return을 활용하여 메소드를 탈출하는건 동일하기 때문에 어떤 구문을 사용하든 상관없다는 생각이 들었다.

• guard문

  • guard 구문의 기능은 코드 블럭의 빠른 종료 기능을 가지고 있어 함수 전체 흐름을 봤을 때 guard 구문이 가독성이 더 좋다고 생각했다. guard문만 보더라도 함수를 탈출하는 구문이라고 읽혀지기 때문이다.
  • if문 처럼 조건문이 깔끔하지는 못하게 되었지만, 함수를 탈출하는 부분을 guard문으로 일관성 있게 구성할 수 있게 되었다.

• 상황 append를 할때 연결된 리스트들의 가장 마지막 부분에 새로운 데이터를 넣어줘야하는데, 요소를 탐색하기 위해 반복적으로 포인터를 추적하는 작업을 해야하는 점을 깔끔하게 해결해보고 싶었다.

• 이유 Queue를 위한 LinkedList인 점도 있고, 또 각 요소를 탐색하기 위해 반복적으로 포인터를 추적하게 된다면 시간복잡도가 O(n)이기 때문에 데이터 접근 방식이 매우 비효율적인 점을 해결하고 싶었다.

• 해결 클래스의 참조를 활용하여 연결리스트를 연결하도록 구현하였다.

  func append(_ value: Element) {
      let newNode = Node(value: value)
          
      if isEmpty {
          head = newNode
          tail = newNode
      } else {
          tail?.next = newNode
          tail = newNode
      }
  }

• Linked-list 자료구조의 이해
• Queue 자료구조의 이해

• 테스트 코드 내부에서 override한 메소드 내부에 super 메소드를 호출하도록 수정
• LinkedList를 테스트하기 위한 Mock 객체 삭제
  • LinkedList 타입에서 접근할 수 있는 프로퍼티, 메소드를 활용하여 테스트를 하도록 리팩토링
• 테스트 메소드 이름을 적절하게 수정
• QueueTests에서 setUp() 메소드를 활용하도록 수정

은행과 고객의 타입을 구현하고 콘솔앱을 구현한다.

• 구현한 타입들 각각 하나의 책임만 갖도록 고민해보았다.
  • 출력문까지도 은행원, 은행이 해야할 일이 아니라고 판단되었기 때문에 따로 출력만 하는 타입(ViewController)을 만들어 Delegate 패턴을 활용하여 분리해주었다.
  • 요구사항 예시에 맞춰 출력을 해주기 위해 NumberFormatter를 활용하는 부분이 필요했는데, 이 부분은 은행에서 직접 처리하는 건 적합하지 않다는 생각이 들었다. 따라서 따로 타입으로 빼주어 static 메소드로 구현해주었다.
• 순환참조
  • Delegate 패턴을 사용하기 위해서 모델 타입 별로 viewController를 만들어주었다.
  • 모델 타입은 delegate로 viewController를 가지고 있고 viewController은 자기 자신을 delegate로 넘겨주기 위해 모델 타입을 가지고 있어 순환 참조가 발생한다.
  • 모델 타입의 delegate를 weak 키워드(약한 참조)를 사용해 순환참조를 해결할 수 있다.
• Delegate 패턴 작성시 네이밍에 대한 고민을 해보았다.

  • 구글의 Swift Style Guide를 참고하여 네이밍을 하였다.

    The term “delegate’s source object” refers to the object that invokes methods on the delegate. For example, a UITableView is the source object that invokes methods on the UITableViewDelegate that is set as the view’s delegate property.

• Delegate 패턴 구현을 위해 기존 모델 타입에 변경사항이 생겼는데 이게 올바른 것인지 잘 판단이 서질 않는다.
  • 기존 구조체였던 타입들을 class로 변경해준 부분이 추후 retain count 추적 비용이 발생할 것이라는 우려가 생겼다.
• Delegate 패턴 사용시 강한 순환 참조 발생을 예방하기 위해 weak 키워드를 사용해주었더니 와일드카드 패턴으로 생성한 인스턴스가 생성과 동시에 해제가 되었다.
  • 인스턴스를 생성한 후 참조를 하지 않는다면 weak 키워드 보다는 와일드카드 패턴을 사용하는 것이 적합한 것일까?
• 단일 책임 원칙에 맞게 역할을 Delegate 패턴을 활용하여 분리해주었다. 하지만 확장성을 고려했을 때 이게 올바르게 설계한 것이 맞는지 너무 오버 엔지리어닝한 부분은 아닌지 판단이 어렵다.

• 상황 기존에 와일드카드 패턴으로 인스턴스 생성한 타입이 Delegate를 채택하고 있던 형태였다. 이후 순환참조 문제가 우려되어 각 타입들마다 delegate 프로퍼티에 weak 키워드를 붙여주었다.

  final class Bank {
      private let bankClerk: BankClerk
      private var customerQueue = Queue<Customer>()
      weak var delegate: BankDelegate?
  ...
  }
  
  func run() {
      let bankClerk = BankClerk()
      let bank = Bank(bankClerk: bankClerk)
      let bankManager = BankManager(bank: bank)
      let _ = BankClerkViewController(bankClerk: bankClerk)
      let _ = BankViewController(bank: bank) // 
  ...
  }

• 이유 그런데 weak키워드를 붙여주니 해당 타입에서 출력해주었던 메소드가 실행되지 않았다. init과 deinit을 통해 디버깅을 해보니 와일드카드 패턴으로 생성한 인스턴스가 생성과 동시에 해제되는 것을 확인할 수 있었다. 와일드카드 패턴은 값을 해체하거나 무시하는 패턴중 하나이므로 weak 키워드가 추가됨과 동시에 retain count가 올라가지 않기 때문에 생성과 동시에 해제되는 것이였다.

• 해결 사용하지 않는 viewController(은행원, 은행)를 상수에 담으면 xcode에서 고메세지가 출력된다. 와일드 카드 패턴을 사용해서 순환참조 문제를 해결할 수 있다고 판단되어 weak 키워드를 제거하고 와일드카드 패턴을 사용하기로 결정했다.

  final class Bank {
      private let bankClerk: BankClerk
      private var customerQueue = Queue<Customer>()
      var delegate: BankDelegate?
  ...
  }
  
  func run() {
      let bankClerk = BankClerk()
      let bank = Bank(bankClerk: bankClerk)
      let bankManager = BankManager(bank: bank)
      let _ = BankClerkViewController(bankClerk: bankClerk)
      let _ = BankViewController(bank: bank) 
  ...
  }

• 타입 추상화 및 일반화
• Delegate 패턴 활용
• SOLID의 단일 책임 원칙
• 와일드카드 패턴과 weak 키워드의 관계

• 개발할 때 염두해야할 것
  • 기능을 선택할 때에는 비슷한 기능은 무엇이 있는지 탐색하기.
  • 선택한 기능이 다른 기능보다 나은점은 뭐가 있는지 생각해보기
  • 기능을 찾아 사용할 때 선택한 이유를 생각해보기
• CFAbsoluteTime 타입 대신에 Date 타입을 활용하여 연산시간 측정하도록 수정
  • Core Foundation 내장함수보다 Foundation에 있는 기능을 활용하려는 의도
    • Core Foundation vs Foundation
      • 코어 파운데이션에 있는 기능은 Foundation에서 래핑하여 구현되어져있다.
      • 보통 앱개발을 할 때에는 Foundation의 기능 없이 개발하기에는 어려움이 있기 때문에, Core Foundation에 내장되어있는 기능보다는 Foundation에 내장되어있는 기능을 사용하는 것을 선호하는 편이다.
• Delegate 패턴과 ViewController 타입 모두 삭제
  • 다음 STEP를 지레짐작하지 말고 현재 STEP에 충실하자.
  • 시도하고 실패하고 돌아가는 과정을 반복하며 개선해나가는 방향으로 진행하자.
• Message의 네이밍을 명확하게 개선
  • Menu의 프로퍼티를 활용하여 menuList의 프로퍼티 내부 하드코딩을 개선
• NumberFormatter를 활용하였던 부분을 Double을 확장하여 개선
  • String(format:)을 활용하여 description을 반환하도록 구성

은행원 여러명이 업무를 처리할 수 있도록 구현합니다.

• 여러 은행원이 동시에 고객의 일을 처리하는 로직을 고민했다.

1. global() 큐에 은행원의 수 만큼 task를 만들고 각각의 task에서 고객을 dequeue해서 처리하는 방식
2. 하나의 while 구문에서 dequeue 해주고 고객의 은행 업무에 따라 예금 고객은 DispatchQueue.global()에 세마포어를 이용해 은행원 수 == 접근 가능한 스레드 수 만드는 방식
   • DispatchSemaphore의 value를 1이 아닌 2나 3으로 줄 경우 Race Condition이 발생할 수 있다는 가능성이 존재하기 때문에 해당 방법은 적절하지 못하다는 생각이 들었다.
   • Banker가 가지고 있는 work() 메소드는 현재 공유자원에 접근하고 있지 않지만, 추후 해당 메소드가 공유자원에 접근하지 않을거라는 보장이 없다라는 생각이 들었다.

• 추후 은행원의 수가 변경되더라도 대응할 수 있도록 은행원 수 만큼 DispatchQueue.global()에 task를 만드는 1번 방식으로 구현했다.
  • 은행원 수 == DispatchQueue의 수

• 프로젝트 실행예시에는 대기번호 순으로 실행되고 있지 않은 점을 발견하게 되었다.
  • 이 부분을 야곰에게 질문해보았고, 순차적으로 업무를 할 수 있도록 구현해보라고 하셔서 고민하게 되었다.
• 고민한 결과, 대기번호 순으로 차례대로 업무가 처리되야 된다고 생각했기 때문에 대출업무와 예금업무를 보는 고객들을 두개의 고객큐로 나누어 관리하도록 구현했다.

• Banking의 경우 rawValue를 String으로 가지고 있는 형태인데, 이 부분을 은행원이 어떤 업무를 처리했는지 알려주기 위해 사용하려는 의도로 구현하게 되었다. 프로토콜 채택과 연산프로퍼티 중에 어떤 방식으로 활용할 지 고민해보았다.
  • CustomStringConvertible의 경우 인스턴스를 원하는 형태의 문자열로 반환하고 싶을 때 채택하여 사용하는 프로토콜로 우리가 활용하고자 하였던 부분이랑은 적합하지 않다는 생각이 들었다.
  • 따라서 description이라는 연산프로퍼티를 활용하여 rawValue를 반환하도록 구현해주었다.

• 처음에 while문 안에 DispatchQueue를 호출하고 DispatchSemaphore의 value를 3으로 주어 3개의 스레드만 접근할 수 있도록 설정해주었다. 그런데 여러번 돌려도 Race Condition이 발생하지 않았다.
• 은행원의 수(DispatchSemaphore value)와 고객의 수를 늘려주고 테스트를 해보았더니 Race Condition이 발생하였다.
  • 테스트를 하면서 알게된 부분은 Banker의 work() 메소드가 공유자원에 접근하지 않기 때문에 발생하지 않았던 것이였다. 프로퍼티 count를 만들어주고 그 count에 접근하도록 구현해주었더니 Race Condition이 발생하는 상황을 확인할 수 있었다.
• 이 의문점을 풀면서 결국 Semaphore의 value를 여러개 주는 것은 공유자원에 접근할 수 있는 상황이라면 Thread-safe하지 않은 것이고, 따라서 은행원의 수를 DispatchSemaphore의 value에 맞춰 설계를 하는 것은 적절하지 못하다는 결론이 났다.

• 상황 프로젝트에서  Bank 타입은 구조체이고, numberOfCustomers 프로퍼티를 가지고 있다. 은행원이 일을 할 때, 처리한 고객의 수를 Dispatch.global().async 클로저 내에서 카운트(numberOfCustomers) 해주도록 하려고 했으나 위와 같은 에러가 발생하였다.
• 이유 Escaping closure의 경우 구조체에서는 캡쳐가 불가능하기 때문에, 프로퍼티를 변경하려고 하면 위와 같은 에러가 발생한다.

// 간단한 코드 예시
struct SomeStruct {
    var num = 0
    
    private mutating func test() {
        let closure = { // Escaping closure captures mutating 'self' parameter
            self.num += 1
        }
        closure()
    }
}

• Escaping closure의 경우 구조체에서는 캡쳐가 불가능하기 때문에, 프로퍼티를 변경하려고 하면 위와 같은 에러가 발생한다.

  class와 같은 참조 타입이 아닌 Struct, enum과 같은 값타입에서는 mutating reference의 캡쳐를 허용하지 않기 때문에 self 사용이 불가능 하다.

• 해결 Bank 타입을 클래스로 바꿔주었다.

• 동기(Synchronous)와 비동기(Asynchronous)의 이해
• 동시성 프로그래밍 개념의 이해
• 동시성 프로그래밍을 위한 기반기술(GCD, Operation) 등의 이해
• 스레드(Thread) 개념에 대한 이해
• GCD를 활용한 동시성 프로그래밍 구현
• 동기(Synchronous)와 비동기(Asynchronous) 동작의 구현 및 적용

• Bank 타입 리팩토링
  • 은행원 수를 나타내는 프로퍼티명 number를 count로 수정
  • Bank타입을 class가 아닌 struct로 수정
  • workBanker() 메소드 내부에 while문을 while let으로 수정
• Banker 타입의 workSpeed() 메소드를 제거
• LinketList의 removeFirst() 메소드 내부를 Thread-Safe하게 개선
  • Thread Safe
    • 기존 로직은 은행원 수만큼 global() 큐에 Task를 만드는 방식이여서 하나의 고객 큐에 여러 스레드가 접근해 Race Condition이 발생할 가능성이 있음.
    • 여러 스레드가 하나의 고객 큐에 접근해도 LinkedList에서 첫 번째 요소를 반환하는 메서드를 하나의 스레드에서만 접근할 수 있도록 SerialQueue.sync를 활용하여 Race Condition을 해결

콘솔앱을 UI앱으로 구현합니다.

• 화면 전체를 스택뷰로 구성할 수 있도록 고민해보았다.
• 동일한 구성을 가지고 있는 뷰를 Custom View로 분리할 수 있도록 고민해보았다.
  • 동일한 요소가 있는 뷰를 커스텀하여 재사용할 수 있도록 구현
• 뷰를 그릴 때 main Thread에서 바로 처리할 수 있는 방법을 고민해보았다.
  • delegate를 활용하여 ViewController가 뷰를 그리는 시점에 DispatchQueue.main.async를 활용하여 비동기적으로 뷰를 그릴 수 있도록 구현
• 각종 예외사항에 대해 대처할 수 있도록 어떤 로직을 추가해야하는지 고민해보았다.
  • 고객 10명 추가 버튼을 클릭시 은행이 일을 하고 있다면 고객만 추가할 수 있도록 로직 추가
  • 고객을 추가할 때 먼저 일이 끝나서 사라진 Thread(은행원)가 있는 경우 다시 일을 할 수 있도록 DispatchQueue를 추가하는 로직 추가 (프로퍼티 옵저버 활용)

• Bool 타입 네이밍을 할때 부정문을 사용해도 될까?

  • Bool 타입 변수를 만들 때 부정문을 사용할 경우 아래 guard 구문을 한국말로 표현하면 타이머 인스턴스가 존재하지 않지 않는다면 함수를 종료 시켜라 라고 표현할 수 있다.

    • 다시 말해 타이머 인스턴스가 존재한다면 함수를 종료시켜라로 다시 한번 생각해야한다.

  • 하지만 코드는 간결하게 작성할 수 있다.

    // 타이머의 인스턴스가 존재할 경우 guard 구문에서 함수를 종료함.
    func open() {
        let isNotWorking = timer == nil
        guard isNotWorking else {
            return
        }
        startTimer()
        
        // ... 
    }

  • Bool 타입 변수를 만들 때 부정문을 사용하지 않는 경우 뒤에 false 구문이 추가된다.

    // 타이머의 인스턴스가 존재할 경우 guard 구문에서 함수를 종료함.
    func open() {
        let isWorking = timer != nil
        guard isWorking == false else {
            return
        }
        startTimer()
        
        // ... 
    }

  • 프로퍼티로 한번에 깔끔하게 만드는 것이 좋은건지 아니면 false문이라도 추가하여 읽기 수월하도록 구성해주어야 하는게 맞는건지 의문이다.

• DispatchQueue는 작업하고 있는 것을 중간에 중지시킬 수 있을까?

  • cancel 메서드를 호출하더라도 작업이 작업 중이라면 중지시킬 수 없다.
  • 우회하는 방법이 존재하지만 GCD가 작업을 취소하거나 하는 것은 할 수는 없다.
  • Operation Queue를 사용하면 작업 중인 작업을 중지 할 수 있다. [참고 링크]

• Custom View 클래스 내부에 프로퍼티를 가져도 되는가?

  • 필요하다면 사용해도 무관하다.
  • 특정 뷰를 찾을 때 Int, String처럼 중복된 값이 들어올 경우 여러 뷰를 찾아올 수도 있다.
  • UUID를 활용하는 활용하면 고유한 값을 가질 수 있다.

• 상황 UIButton에 View의 요소를 업데이트 하도록 기능을 추가하고 테스트 해보았으나, 버튼이 클릭됨가 동시에 화면이 멈추고 에러가 나면서 뷰가 업데이트 되지 않는 상황을 마주했다.

• 이유 비동기 프로그래밍시 뷰를 그리는 작업은 main thread에서 처리해주어야 하는데, 따로 처리해주지 않아서 해당 에러가 발생했던 것 같다.
• 해결 뷰를 그리는 작업을 main thread에서 처리하도록 DispatchQueue.main.async 클로저 구문안에 넣어주었다.

• 상황 고객 추가버튼을 여러번 클릭하고 초기화를 누르게 되면 타이머가 멈추지 않았다.

• 이유 타이머가 추가버튼 클릭시 계속 추가되면서 추가된 타이머가 끝나지 않고 계속 실행되는 듯 했다.
• 해결 초기화 버튼을 클릭할 때, 대기중인 고객이 없을 때 타이머를 멈추면서 타이머에 nil을 대입해주었고, 타이머가 작동중에는 타이머를 추가하지 않도록 하는 로직을 추가해주니 해결되었다.

• 동시성 프로그래밍 중 UI 요소 업데이트의 주의점 이해
• 커스텀 뷰 구현
• 스택뷰 활용
• 코드로 UI 구성(오토레이아웃)
• 타이머 활용방법과 Run Loop