## 1. 고민한 부분

1-1. linked list 로 구현해야 하는 이유?

- dequeue의 시간복잡도를 줄이기 위해서
- array는 인덱스에 다음 인덱스 정보가 없는 반면, linked list는 node로 정보를 가지고 있어서

1-2. linked list 단방향 vs 양방향

- 단방향으로 구현했습니다.
- 필수로 구현하라고 되어있는 기능에서 양방향이 불필요하다고 판단했습니다.

1-3. LinkedList 클래스 vs 구조체

- 구조체로 구현했습니다.
- 현재로서는 LinkedList 데이터 접근은 Queue에서만 이루어진다고 판단하고 있습니다.
- Queue에서 직접적으로 LinkedList의 값을 변경해주는 형태가 아니기 때문에 참조가 불필요합니다.
- 만약 참조 타입을 선택한다면, 다른 클래스에서 LinkedList를 상속하지 못하도록 final 키워드를 붙여줘야 한다고 생각합니다.
- `final class` 와 `mutating을 사용하는 struct` 사이의 성능상 차이를 아래와 같이 정리해보았습니다.
- final class는 기존 class가 dynamic dispatch인 것과 다르게, `static dispatch`가 되면서 비용절감이 이루어집니다.
- mutating을 사용하는 struct는 non mutating struct와 성능상 큰 차이가 없다는 것으로 검색되었습니다. 정확히 파악하기는 어려워서... 우선 이 정도로만 이해해보았습니다.
- 결과적으로 final class는 일반 참조타입에 비해 비용절감이 되는 것은 사실이지만, 값 타입에 비해 여전히 비용적으로 불리하다는 결론을 내보았습니다.

1-4. Queue 클래스 vs 구조체

- 구조체로 구현했습니다.
- 현재 공개된 스탭을 기준으로는 클래스가 오버엔지니어링이라고 생각하였습니다.
- [Choosing Between Structures and Classes](https://developer.apple.com/documentation/swift/choosing_between_structures_and_classes) 문서를 참고했습니다.
- 문서를 보면 디폴트로 구조체를 사용하는것을 권장하고 있습니다 (**`Choose Structures by Default`** )

1-5. convenience initializer

- Node 타입의 이니셜라이저로 next의 기본값을 nil 할당했을 때 `(사진1)`, 인스턴스 생성시 next가 파라미터로 노출되는 것을 피하고 싶어`(사진2)` convenience init을 사용해보았습니다.`(사진3)`

사진1
<img src="https://i.imgur.com/jrOmiJ1.png)" width="50%" height="30%">

<br>

사진2
<img src="https://i.imgur.com/zOIn0FO.png)" width="50%" height="30%">

<br>

사진3
<img src="https://i.imgur.com/veBYq45.png)" width="50%" height="30%">

이렇게 convenience initializer를 만들었지만 `Node(data: next:)`는 사용을 하지 않아서 convenience initializer를 삭제해주었습니다.

따라서 이니셜라이저는 data만 노출되도록 만든 상태입니다.

1-6. dequeue의 의미

- dequeue: 맨 앞의 요소를 삭제하는 것
- delete: 특정 요소를 삭제하는 것
- 현재는 특정 요소를 삭제할 일이 없다고 생각하여 맨 앞에있는 요소를 삭제하도록 전자를 구현했습니다.

1-7. dequeue의 반환값을 어떻게 줘야 할까?

- peek 기능을 필수로 구현해야 한다면 반환값 없이(peek + dequeue 조합으로) 사용할 수도 있을것 같습니다.
- peek이 왜 필수 기능인지 이해하지 못해, `first`로 리네이밍을 해서 `외부에서의 head 데이터 접근을 직관적으로 수행`할 수 있도록 유도해보았습니다.

1-8. 기본값을 할당하는 방법

- `(1)비어있는 연결 리스트를 프로퍼티에서 기본값으로 할당하는 방법`과 `(2)init으로 할당해주는 방법` 두 가지를 고민해보았습니다.
- 굳이 후자일 필요가 없다고 생각하여 방법 1로 적용했습니다.

// 번외) 둘의 차이는 무엇일까? 

// 방법 1 - 현재코드
struct Queue<Element> {
    var linkedList = LinkedList<Element>()
}

// 방법 2 
struct Queue<Element> {
    var linkedList: LinkedList<Element>
    
    init(linkedList: LinkedList<Element> = LinkedList<Element>()) {
        self.linkedList = linkedList
    }
}

## 조언을 얻고 싶은 부분

- Unit Test가 적절한지
- 현재는 Int타입에 대해서만 테스트를 작성했는데
- 다른 타입들도 확인을 해봐야 할지 궁금합니다
- test 내용이 중복되고 있다는 느낌이 드시나요?

func test_enqueue메서드로_1_2_3을넣었을때_first가_1인지() {
		sut.enqueue(data: 1)
		sut.enqueue(data: 2)
		sut.enqueue(data: 3)
        
		XCTAssertEqual(sut.first, 1)
 }
    
func test_enqueue메서드로_1_2_3을넣었을때_first가_5가아닌지() {
		sut.enqueue(data: 1)
		sut.enqueue(data: 2)
		sut.enqueue(data: 3)
        
		XCTAssertNotEqual(sut.first, 5)
 }

## 해결되지 않은 문제

1. 현재 Queue의 dequeue()메서드의 리턴타입은 optional입니다.
- 따라서 리스트에 값이 없을 때 dequeue메서드를 호출하면 nil을 반환합니다.
- 추후 스텝에서 에러타입을 정의할 필요가 있다고 생각되면 에러타입을 추가할 생각입니다.
2. 고사리의 xcode에서만 아래와 같은 오류가 발생하고 있습니다.


해결방법을 모르겠습니다.... 해결되지 못하고 있습니다....

## 트러블 슈팅

1. 문제상황: 빌드를 하려고 하면 아래 사진처럼 동작할 수 없다는 경고를 보여줬습니다


- 해결방법: product>scheme>edit scheme>run>info>executable>러닝할 앱 선택
- 만약 프로젝트를 다운받았는데 빌드가 안되신다면 위 방법을 적용 부탁드립니다!

2. 문제 상황: Unit Test 실행시 아래와 같은 문제가 발생했습니다.


- 해결 방법: macOS deployment target을 11.5로 낮추었습니다.