Swift 코드 작성 체크리스트!

SeSAC 리뷰어님들의 코드리뷰와, Swift 코드 리뷰 체크리스트 들을 보고 정리 한 내용입니다.
꼭 이렇게 하자! 가 아닌, 이 부분들을 우선으로 고려해보자! 가 맞을 듯 합니다 :)

안전성, 성능

• ⭐️ 코드에 ! 는 없어야 한다 (강제언래핑, IUO 사용 ❌)
  • IBOutlet, 테스트의 sut, Bool의 느낌표 등… 특수한 경우 제외
• ⭐️ delegate 변수는 weak var 로 선언 (순환참조 방지)
  • +) Delegate protocol 채택은 extension 부분에서 해주자 (컨벤션)
• ⭐️ escaping closure 내부에서 self 사용시 [weak self] 처리 (순환참조 방지)
• ⭐️ 배열을 인덱스로 바로 접근하지 말자 (런타임에러)
  • 배열의 범위를 확인 한 후에 접근하는 extension 을 활용하자
  • ex) array[safe: 1]

    extension Array {
        subscript (safe index: Int) -> Element? {
            return indices ~= index ? self[index] : nil	
        }
    }

• ⭐️ private, private(set) → 캡슐화 체크
  • 객체 외부에서 접근할 일이 없으면 꼭 붙여주자
• ⭐️ 변경되지 않을 var 는 let 으로 선언
• ⭐️ 상속이 불필요한 class 의 final 키워드 붙이기
  • 메서드 디스패치 성능 최적화) dynamic → static
• ⭐️ 무거운 작업은 메인스레드에서 하지 말자
  • 메인 스레드는 주로 UI 작업을 하기 위해 디자인 되었다. UI가 멈추게 하지 말자
• .count == 0 , == nil 대신 .isEmpty 사용
  • 이와 같은 더 많은 컨벤션들은 아래 글 참조
    Performance, functional programming and collections in Swift
• 특정 이벤트에만 사용되는 객체의 경우 lazy 키워드를 사용
  • lazy 는 접근시에만 생성되므로, 메모리 효율성을 위해서. ex) ImagePicker...
• 모델은 Class 일 필요가 없다면 Struct 를 우선으로 고려
• 작성한 코드를 애플이 제공하는 API 로 대체할 수 있는지 체크
• 고차함수를 성능 개선 보다는, 가독성 개선을 위한 측면에서 바라봐야 한다.
  • map은 for-in 보다 빠를 수 있다
  • filter, reduce는 for-in보다 느릴 수 있다
  • 고차함수를 복합적으로 사용하는경우, 성능이 심각하게 저하될 가능성이 있다.
    출처 - https://jeong9216.tistory.com/403 (for-in과 고차함수 시간비교)
• 고차함수 내부에는 순수함수만 와야 한다
  • ex) 상태를 변경하는 순수하지 않은 함수라면 forEach 대신 for 문을 사용하자

Swift 스러운, 깔끔한 코드

• ⭐️ 반복되는 코드는 없는지 확인
  -DRY: Don't Repeat Yourself
• ⭐️ 일어나지 않을 일을 대비해서 작성한 불필요한 로직이 없는지 확인
  • YAGNI: You Aren't Gonna Need It
• ⭐️ 함수가 두개 이상의 역할을 하지 않는지 확인
  • KISS: Keep it small and simple
• ⭐️ 하드코딩 된 값들은 따로 빼주기
  • ex) ID값, 매직넘버, 매직스트링… → 아래의 이유로 enum으로 묶는 것을 추천
  • 클래스, 구조체가 인스턴스화 될 일이 없으면 enum을 선택하자
• if 문 보다는 guard 문의 로직을 적극 활용
  • 조기 종료의 성격을 적극 활용
• if-else 조건이 많을 시, enum-switch 로 변경을 고려
• class 상속 보다는 protocol 을 우선해서 고려
• 사용되지 않는 변수, 함수, import 문 삭제
• 불필요한 주석 삭제, 주석의 파일명과 실제 파일명 일치여부 확인
• String들을 합칠 때 + 대신 \() 을 쓰자

네이밍

• 네이밍이 명확하고 일관적인지 확인
• 네이밍이 “역할” 을 잘 드러내는지 확인
• Bool 타입은 is, has, can, should, will… 로 시작
• 메서드는 동사로 시작
  • get 메서드는 명사를 사용해도 괜찮음 (getName(of:) 보다 name(of:) 가 낫다)
• 배열은 복수형으로 작성 (ex [Student] 배열 → students)
• 축약보다는 길게 쓰더라도 명확하게 네이밍
• 중복되는 단어 제거
• IBAction 의 함수 네이밍은 action부터 시작하게 네이밍
  • ex) someButtonTapped → tappedSomeButton _ (필수가 아닌 추천 사항일 듯 합니다)
• Extension 파일을 만들 때는 파일명에 타입과 함께 표기해주자
  • Extensions → Extension+String or String+Extension
  • 개인적으론 기능에 따라 String+Parsing 형태로 분리해서 관리하는 것을 선호합니다.

코드리뷰 외에 참고 한 글들:

https://medium.com/@ashokrawat086/code-review-checklist-483614b91821
https://dev.to/bornfightcompany/ios-code-review-checklist-53ia
https://isameh.medium.com/the-checklist-of-my-code-review-18cc6f6fb5b3
https://linux-studying.tistory.com/22