- @State
- @Environment
- @Published property Wrappers
- @Main Actor
- AnyObject (why deprecate class?)
- GCD
Premature Optimization
나름 변명을 하자면 이 때문에 정말 많은 시간을 허비하고 있지 않나 싶다.
불필요한 최적화/고민이다!
개발 자체를 하는 건 재밌다. 물론 막히는 부분이 반복해서 생기다보면 자책을 하는 시간이 많아진다. 하지만 요즘들어 느끼는 건 하나의 코드를 작성하더라도 시간을 너무 많이 소비하는 경향이 생겼다.
이 문제를 Premature optimization이라고 볼 수 있을 것 같다.
해외에서는 이를 'root of all evil' 악의 뿌리 그 자체라고 설명을 한다.
그 이유는 구현, 구동, 실행 등 실질적으로 서비스가 돌아갈 수 있도록 만들어야 하는 개발자들이 더 빠른 속도, 최적화 혹은 지금은 불필요할 수 있는 아키텍쳐 등에 더 많은 시간을 소비하고 있다는 점이다.
개인 프로젝트를 잡은지 2주일 되는 시점에서 나는 여전히 UI를 다 그리지 않았다.
어떻게 하면 더 깔끔하게 만들 수 있을지 고민을 하고 이것저것 찾아보고 적용해보고 지우다보니 시간이 흘러 가버렸다. (진짜 변명이다...)
오늘 나에게 있어 가장 중요한 점은 개발이란 속도전 이라는 점이다.
코드가 좋을 수 없다. 특히 아직 주니어면 더더군다가 무엇이 좋은지 경험 자체가 부족한 상황이다. 그렇다면 적어도 빠르게, 많이 만들어 내어야 오히려 좋을 수 있다!
한 해외 블로그에서는 시간을 허비하는 몇 가지를 예시로 주고 있다.
1. 구글 에널리틱스 데이터를 위한 다양한 DB, 저장소 옵션을 고려하는 상황
2. 매주 수많은 웹사이트 페이지를 크롤링할 수 있도록 대규모 큐, 스케일링을 적용할 수 있는지
3. 보다 많은 리치를 이루기 위해 멀티 클라우드 배포를 고려하는 점
4. 작성한 코드를 100% 테스트 했는지 파악 여부
5. 자동화 테스트 구축 등
이외에 크고 작은 포인트들이 많았다.
중요한 포인트를 잊지 말자!
Tamic(TranslatesAutoResizingMaskIntoConstraints)
The O-Famous TAMIC. I never spent the time to rethink why it has to be toggled 'off'. As it caused an issue to me recently, I'd like to go over what it means
먼저 공식문서를 읽어 보자!
"A Boolean value that determines whether the view’s autoresizing mask is translated into Auto Layout constraints." - 쉽게 보면 뷰의 autoresizing mask를 autoLayout으로 변경할지 묻는 참/거짓 값이다.
1. AutoResizing Mask란?
AutoResizing Mask에 대한 설명은 꽤 과거로 돌아가는데, 오토레이아웃 이전에 사용되던 방식으로 이해된다. 한 redditer에 의하면 과거 USIMS(User Interface Management System)에서 사용된 Structs and Springs라는 레이아웃 컨셉에서 파생된 것으로 설명한다.
해당 레이아웃에서는 '면' 혹은 '차원'의 값을 변경할 수 있는데 여기서 Springs은 넓이와 높이를, Structs가 좌, 우, 위, 아래의 간격을 의미한다고 한다. 이때 struct는 고정적인 값 또는 어떠한 값도 받을 수 있는데, 이 기능을 활용해서 면을 자유자재로 이동시키는 autoresizing mask를 구현할 수 있다고 한다.
mask는 bitwise OR(연산자 '|')의 값들이라고 한다! - 자세한 내용은 아래에서~
structs와 springs에는 아래와 같이 다양한 옵션들이 존재한다.
1. UIViewAutoresizingFlexibleWidth
2. UIViewAutoresizingFlexibleHeight
3. UIViewAutoresizingFlexibleLeftMargin
4. UIViewAutoresizingFlexibleRightMargin
5. UIViewAutoresizingFlexibleTopMargin
6. UIViewAutoresizingFlexibleBottomMargin
해당 옵션들과 bitwise OR 연산자를 활용하여 오토레이아웃 기능을 구현할 수 있게 된다고 한다. 말 그대로 '또는' 이라는 특징을 활용해서 조건을 통해 view의 크기를 자유자재로 바꾸게 만든다는 점이다!
예를 들어,
let subView = Frame(CGRect(x: 10, y: 10, width: 50, height: 50))
let superView = Frame(CGRect(x: 0, y: 0, width: 70, height: 70))위 상황에서 "UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleRightMargin"를 조건으로 내세운다면, subView는 superview의 bottom과 right margin 값을 유지하기 위해 높이와 넓이를 자유자재로 움직일 수 있게 된다. 하지만 x,y 좌표 값이 10, 10으로 고정이 되어 있기에 subView의 네모난 view는 고정된 크기를 가지게 된다고 한다.
2. 그렇다면 왜 TAMIC은 꺼야할까?
이건 기본적으로 공식문서에서 언급을 하는데, true일 경우 배치된 뷰의 제약 값을 자동적으로 제공한다고 한다. 따라서 NSLayouConstraint를 따로 작성했다면... 나처럼 엄청난 conflict 문제를 경험하게 된다는 점이다.
코드로 뷰를 구현하고 있다면 기본적으로 true로 제공되며 IB를 활용한다면 false 값이 적용된다고 한다.
따라서 TAMIC을 false로 토글하지 않는다면 상황에 따라 두 번의 오토레이아웃이 적용되기에 코드로 구현을 하는 편이라면 항상 false 값을 적용하는 것을 까먹지 말아야 한다!
참고
- https://www.reddit.com/r/iOSProgramming/comments/3f88uh/autoresizing_masks_what_are_they/
- https://stackoverflow.com/questions/70039220/translatesautoresizingmaskintoconstraints-meaning
- https://www.swiftwithvincent.com/blog/do-you-know-what-translatesautoresizingmaskintoconstraints-actually-does
- https://stackify.com/premature-optimization-evil/
