오토레이아웃 Storyboard vs Custom Code

[Youngminah]

스토리보드

• 스토리보드는 다음을 처리할 때 사용하면 유용.
• 인증 및 등록을 하기 위한 뷰 구성
• 여러 단계 주문 입력 플로우 구성
• 튜토리얼과 같은 흐름 구성
• 상위 집합과 하위 세부사항 집합의 뷰 구성

스토리보드의 장점

• 성능: 스토리보드가 로드되면 모든 뷰 컨트롤러가 인스턴스화 된다고 가정할 수 있습니다. 이것은 실제 구현에 해당되지 않고 초기 뷰 컨트롤러만 생성.
• 프로토타입 제작: 빠르고 단순하게 프로토타입을 구성 가능.

스토리보드의 단점

• 재사용성: 스토리보드는 의존하는 모든 뷰 컨트롤러와 함께 복사하거나 이동해야 합니다. 단일 뷰 컨트롤러를 추출하여 다른 곳에서 재사용할 수 없음.
• 데이터의 흐름: 앱이 전환될 때 뷰 컨트롤러간에 데이터를 전달해야 하는 경우가 있습니다. 그러나 스토리보드는 뷰 컨트롤러간의 흐름을 처리하지만 데이터의 흐름을 처리하지는 않음

코드

스토리보드와 NIB로 할 수 있는 어떤 것도 코드로 가능하며, 스토리보드와 NIB로 할 수 없는 것도 코드로 가능

코드의 장점

• 성능: 스토리보드와 NIB는 로드 및 구분 분석의 오버헤드가 발생합니다. 코드로 구현한 UI에서는 발생하지 않음
• 동작방식의 이해: UI를 코드로 구현하면 내부적으로 어떤 동작이 수행되는지 이해할 수 있음. (ex: view생명주기)
• 코드로만 구현할 수 있는 경우: 스토리보드와 NIB로 구현할 수 없는 기능을 구현할 수 있음
• git 충돌 병합: 코드는 스토리보드와 NIB보다 문법적으로 의미를 가지고 있기 때문에 충돌을 쉽게 해결할 수 있음
• 재사용성: 코드로 구현된 모든 뷰는 재사용 가능한 방식으로 디자인할 수 있음

코드의 단점

• 프토토타입 제작: 레이아웃하고 화면에 어떻게 보여지고 작동하는지 보여주기 위한 작업 시간이 오래 소요.
• 리팩토링: 다른 사람이 작성한 코드를 리팩토링하는 것이 훨씬 복잡해짐.

현엽 개발자들의 선호도는?

• 혼자 개발을 하지 않는 이상 코드를 훨씬 선호. But 둘다 적절히 섞어서 사용하는 경우도 꽤 많음

TMI: 재밌는 사실

• 코드로 잘 구현하는사람보다 스토리보드로 오토레이아웃을 완벽히 잘 구현하는사람을 더 찾기 어려움
• 의외로 현업에서 선호도가 높지도 않은데 어렵기만한 스토리보드의 오토레이아웃을 때려치고
• 코드로 짜는사람이 많다는 사실
• 그런데 스토리보드로 오토레이아웃을 완벽히 구현하는 사람은 코드로 오토레이아웃 구현을 쉽게 가능
• 그래서 스토리보드로 오토레이아웃을 시작하는 사람은 코드 걱정을 크게 안해도된다... ❗️

결론

• 중요도: 코드 > 스토리보드
• 진입장벽: 스토리보드 > 코드
• 둘다 잘하는 것이 가장 좋음