• 기존의 가나다 연습이 아닌 부모가 직접 만든 단어장의 단어를 따라쓰기
• CoreMotion을 활용하여 Heads up 게임 구현

다음과 같은 기준으로 개선을 해보면 좋겠습니다.

1. 경직성 시스템을 변경하기 어렵다. 변경을 하려면 시스템의 다른 부분들까지 많이 변경해야만 한다.
2. 취약성 변경을 하면 시스템에서 그 부분과 개념적으로/직접적으로 아무런 관련이 없는 부분까지 망가진다.
3. 부동성 시스템을 다른 시스템에서 재사용할 수 있는 컴포넌트로 구분하기 어렵다.
4. 점착성 옳은 동작을 하는 것이 잘못된 동작을 하는 것보다 더 어렵다.
5. 불필요한 복잡성 직접적인 효용/쓸모가 전혀 없는 기반구조가 설계에 포함되어 있다.
6. 불필요한 반복 단일 추상 개념으로 통합할 수 있는 반복적인 구조가 설계에 포함되어 있다.
7. 불투명성 읽고 이해하기 어렵다. 그 의도를 잘 표현하지 못한다.

1. 코딩 스타일 가이드라인을 잘 지키고 있나
2. 코드를 읽고 이해하기 쉬운가
3. 함수나 클래스가 너무 큰가
4. 단위 테스트나 디버깅이 쉬운가
5. 코드가 여기저기 중복되고 있나

• Pods 디렉토리 제거 : pod install 명령으로 생성되는 파일들을 ignore 시키고 저장소에 올리지 않습니다.
• 클래스 속성 접근 관리자 설정 : 항상 private을 우선적으로 고려하세요. getter가 필요한 경우 private(set) 속성까지는 허용할 수 있습니다. 하지만 private으로 하고 상위 모듈에서 그 값을 가져가서 처리하기 보다는 그 값으로 비교하거나 처리하는 로직을 그 객체가 갖도록 개선해보세요.
  • if page < cardManager.toDoCount - 1 {} 대신 if cardManager.canPaging(page) {} 형태로 메소드를 구현한다.
• Cell을 포함한 UIView 를 상속해서 만드는 경우 init(frame:)과 init(aDecoder:) 필요성과 차이점을 고민해서 코드를 구분해보세요. init에 구현하는 것과 layoutSubviews() 나 다른 메소드에서 구현해야 할 것도 구분해보세요.
• Cell을 포함한 UIView가 Delegate 패턴으로 구현하는게 좋을까요? 나쁠까요? 의존하지 않도록 Observer 패턴을 구현해보는 건 어떤가요?
• InputVC 등 ViewController 클래스 이름은 귀찮더라도 줄여쓰기 보다는 풀어서 쓰는게 좋습니다. 변수명은 줄여서 쓰더라도 클래스명은 수퍼클래스 이름을 유추할 수 있도록 작성하는 게 좋습니다
• fatalError 에 대해서는 꼭 필요한 경우가 아니라면 대신 다른 방법으로 대체해보세요. 앱이 멈출수 있는 여지가 있는건 리젝 사유 중에 하나입니다. 예외적인 상황에서도 앱이 멈추지 않는다면 그 방법을 선택하세요.
• CategoryManager와 같은 싱글톤 객체는 인터페이스를 만들때 주의해야 합니다. init으로도 할수 있고 instance로도 접근할 수 있으면 어떤걸 사용해야 할지 헷갈리거나 실수할 수가 있습니다.
• if-else 구문 보다 guard를 쓰면 좋은 곳도 있습니다.
  • if !didSetupConstraints { .... } 보다는 guard didSetupConstraints else {} 형태로 들여쓰기를 줄이면 읽기 쉬워집니다.
• 하드코딩하는 숫자, 문자열 값을 의미있는 코드(enum 또는 객체)로 표현해보세요. 그러면 실수할 꺼리도 줄어들 겁니다.
• 함수 내부에서 들여쓰기가 3-4단계 이상 들어가면 메소드를 분리해보세요.