이 포스팅은 iOS Experience 시리즈 18 편 중 16 번째 글 입니다.

  • Part 1 - 01: 스토리보드의 장단점
  • Part 2 - 02: 코드리뷰 Part 1
  • Part 3 - 03: 코드리뷰 Part 2
  • Part 4 - 04: IBOutlet에서의 Optional
  • Part 5 - 05: Optional Chaining의 동작 방법
  • Part 6 - 06: UITableView에 대해서
  • Part 7 - 07: 코드리뷰 Part 3
  • Part 8 - 08: 패키지 매니저
  • Part 9 - 09: URL Loading System
  • Part 10 - 10: Lazy를 잘 안쓰는 이유
  • Part 11 - 11: iOS Gitignore
  • Part 12 - 12: Toast UI에 대한 생각
  • Part 13 - 13: XCTest
  • Part 14 - 14: RunLoop
  • Part 15 - 15: UIApplication
  • Part 16 - This Post
  • Part 17 - 17: MVC to MVVM
  • Part 18 - 18: VIPER
▼ 목록 보기

코드리뷰

  • 내부의 속성을 변경하는 작업의 경우, 메서드를 만들게 되면 능동적인 모델로 변경할 수 있다.
    • 코드도 지저분해지지 않는다.
  • property의 경우 위에, computed property의 경우 아래에 적는 방법도 있다.
  • 개체 수를 관리하는 것을 Factory에서 처리하는 것이 좋을 수 있다.
  • extension에도 접근 제어를 걸 수 있다.
  • 이미지는 URL만 가지고 있다가 보여지는 시점에 이를 로딩하는 것이 더 좋다.
    • 즉 보여지는 시점에 그리도록 하는 것이 자원을 적게 먹는다. image는 자원이 높다.
  • 특정 로직 자체를 활용하는 방법 자체가 달라질 수 있는 경우라면 UseCase라는 객체를 만들어 사용하는 것이 모듈화 측면에서 좋다.
  • 프로토콜을 동작(메서드) 측면에서 나눈 뒤에, 이를 기반으로 활용한다면 좋다.
    1. 상속이외에 다른 특징(형용사)으로 Group화가 가능하다.
    2. 해당 객체를 사용하는 쪽에서 역시 명시적으로 해당 객체 타입을 선언하지 않고 프로토콜을 타입으로 사용하여 interface로 사용하여 결합도를 낮출 수 있다.

0001 0002 0003