호구마츄로그

2024 회고

호구마츄 — Sun, 29 Dec 2024 14:41:21 +0900

2024에는 많은 일이 있었다.

특히 기존에 겪었던 환경과 매우 다른 환경의 회사에 입사하게 되었고 이를 통해 많은 것을 경험하였다.

1. 새로운 회사 그리고 새로운 사람들 그리고 새로운 불만

긴 이직 준비를 끝으로 5월에 새로운 회사에 입사할 수 있었다.

전에 다녔던 회사와는 굉장히 달랐다.

스타트업에서 직급이 있는 회사로 가게 되었고 많은 부분에 불만이 많아졌다.

커뮤니케이션에 정말 불필요한 리소스를 쏟아야 하는 것이 싫었다. 특히 담당자에게 직접 이야기하기 어려운 경우와 담당자가 누구인지 파악하기 어려울 때 정말 현타가 왔다.

일정 또한 기획과 디자인이 나왔는데 ASAP..? 이게 가능한가… 회사를 봉사 차원에서 운영하는 것인가 하는 생각이 들었다.

의사결정 또한 이해가 안되는 것이 많았다. 이미 결정되었는데 회의를 하는 이유가 무엇일까? 그냥 통보해 주면 되는데.

의사결정에 ‘그냥’, ‘뭔가’ ‘약간’ 이라는 말을 하는 이유가 무엇인가? 이러한 이야기를 듣고 나도 그냥 뭔가 약간 답답했다.

A/B Test나 Analytics는 왜 활용은 안 할까? 일정이 병목이 되었다면 어떤 곳에서 병목 있는지 확인을 해야 하는데 단순히 가장 마지막 결과물이 나오는 모바일 팀에 프레셔가 들어와야 하는가?

정말 셀 수 없는 많은 불만이 있었지만 기술적으로 하고 싶은 것은 다 할 수 있어서 좋았다.

2. iOS 개발자

입사했을 당시 iOS 앱은 존재하지 않았고 안드로이드 앱만 존재했다.

또한 1년 정도 먼저 개발되었으며 iOS 팀도 내가 최초였다.

새로운 프로젝트를 위해 설계 및 여러 작업을 해야 했으며 추후 들어올 팀원을 위해 문서화 및 최대한 불편하지 않게 하기 위해 했다.

의사 결정에 대해서는 모두 ADR을 작성하였고 가이드라인 등 여러 문서화를 꼼꼼하게 하였다.

다행히 새로오신 분도 잘 적응하시고 함께 열심히 서비스를 만들었다.

몇 개월 정신없이 기능 개발을 하니 iOS 개발자로서 도파민이 굉장히 떨어졌다.

전 회사에서는 업무를 스프린트 방식으로 진행하고 정말 야근도 하며 서비스를 만들고 데이터도 함께 보며 개선점을 이야기를 했는데 현재는 칼퇴에 업무 기간은 그냥 내가 정하면 된다.

그러다 보니 열심히 해야겠다는 동력이 많이 사라졌다.

3. 그럼에도

내가 어떤 사람들과 일을 하고 싶은지 알게 되었다.

또한 그렇지 않은 사람들과 함께 일을 하며 상생하는 방법을 조금 알게 되었다.

정말 커뮤니케이션의 중요성을 뼈저리게 느꼈으며 초등학생이 이해할 수 있을 정도로 설명해줘야 한다는 것도 느꼈다.

모든 사람이 일을 통해 성취감을 얻으려 하지 않고 일은 그냥 일이다라고 생각하는 사람도 많았으며 열심히 일을 하는 사람을 좋지 않은 시선으로 보는 사람도 있었다.

굉장히 많은 불만이 생겼지만 나와 비슷하게 불만이 있지만 젠틀하게 이를 해결하는 사람도 있었다. 그는 나에게 ‘지금 개발로서 배우는 것이 적을 수는 있어도 이러한 사람들에게 잘 설명하고 이야기할 수 있는 것도 개발자로서의 역량이고 이를 키울 수 있는 좋은 기회다.’라고 얘기해 주었다.

불만이 많이 생겼지만 그 안에서 배우는 것도 많이 생겼다.

4. 2025년에는

커뮤니케이션 역량을 더 키우고 싶다. 초등학생도 이해할 수 있도록 잘 대화하고 싶다.

사이드 프로젝트를 크게 하나 하고 싶다. 단발성이 아닌 지속 가능한 것으로.

Analytics를 꼭 추가할 수 있도록 필요성에 대한 설득을 해야겠다.

블로그 글을 더 자주 발행 해야겠다.

클린 아키텍처 반드시 필요한가? (Mobile)

호구마츄 — Mon, 18 Nov 2024 09:46:29 +0900

굉장히 어그로성이 강한 제목이다.

클린 아키텍처는 왜 이리 인기가 많을까?

그리고 모두에게 필요한 것일까?

최근 (아마도 오래 전부터) 에 모바일 개발에는 대부분 클린 아키텍처로 되어있다.

왜 이렇게 인기가 많을까?

클린 아키텍처가 인기가 많은 이유

확장성과 유연성이 뛰어나다

말 그대로 클린 아키텍처는 확장성과 유연성이 뛰어나다.

즉 쉽게 변경할 수 있고 테스트에 용이하다. (의존성 역전)

Domain과 Data Layer 를 잘 분리하여 서버의 응답이 변경 되어도 쉽게 반영할 수 있다.

이것만 봐도 굉장한 장점이다.

멋지다

일단 뭔가 멋지다.

클린 코드 책과 더불어 클린 아키텍처 책도 굉장히 인기가 많다.

책이 먼저인지 아니면 아키텍처 자체가 먼저 유명해진 것인지는 중요하지 않다. 일단 멋지다.

클린 아키텍처는 과연 모두에게 멋진가?

'클린 아키텍처가 모두에게 잘 어울리는 아키텍처인가' 라는 생각이 든다.

정말 작은 앱을 확장성이 매우 뛰어난 앱으로 만드는 것이 과연 좋은 것인가?

클린 아키텍처를 반영하다보면 종종 UseCase가 단순 Repository에 있는 데이터를 변경만 해주고 있다.

API Response가 변경이 되면 Entity도 변경이 된다.

즉 클라이언트-서버의 관계가 강하게 결합이 되었다는 의미이다.

과연 이런 상황에서 Domain Layer는 필수적으로 존재해야 하는가?

클린 아키텍처가 필요 없는 경우

API Response가 변경될 때 매번 Entity도 함께 변경되는 경우

물론 기능이 변경된 경우는 당연히 변경되는 것이 맞지만, 매번 변경이 된다면 이는 과연 필요한 것인가?

UseCase가 단순히 Repository의 결과 값을 전달만 해주는 경우

UseCase에서 아무 로직이 없고 Repository의 결과만 전달해주는 경우 굳이 없어도 되지 않을까?

그냥 이유 없이 UseCase, Repository, Entity, Model, DTO... 등 나누고 있을 때

여기서 이유 없이라 함은 클린 아키텍처에 대한 니즈가 없지만 단순히 트렌드를 따라가는 것을 의미한다.

모듈화, 테스트 코드 등 해당 아키텍처에 대한 활용이 없다면 단순히 앱을 복잡하게 만드는 것이 아닐까?

개발자가 적을 때

전체적인 개발자가 적을 때는 굳이 복잡한 아키텍처를 선택할 필요가 없다.

어차피 내가 개발하거나 내 옆에 사람이 개발할 것인데 굳이 복잡하게 나눌 필요가 있을까?

소수의 인원이라면 그들만의 룰을 만들고 추후 유지보수만 생각하면 괜찮지 않을까 싶다.

그냥 주저리 주저리

클린 아키텍처를 사용해야만 확장이 가능하며 테스트가 가능한 것이 아니다.

의존성 주입을 잘하고, 필요에 따라 Helper 객체를 주입해주면 잘 분리되지 않을까?

근래에 자꾸 클린 아키텍처를 신봉하는 사람이 많아져서 반발 심리가 도진다.

그러나 결국 회사에서는 클린 아키텍처로 설계하고 있는 내 모습

개인적으로 앱에 있는 기능이 꽤 오래 살아서 새로운 기능이 덕지덕지 붙을 가능성이 있으면 클린 아키텍처

진짜 너무 린해서 기능을 업데이트하기 보다 새로 만든다면 그냥 테스트나 확장 가능성 버리고 빨리 만드는 것도 하나의 방법 같다.

그럼 다들 이렇게 말하는 사람도 있겠지? '테스트 코드를 작성해야 오히려 개발이 더 빠르다'

어느정도 동의는 하는데 전제조건이 필요하다.

일단 사용자가 많아야 된다. (보통 QA 팀이 다 걸러주더라 )

또한 기능을 금방 버리는데 테스트 코드를 빡세게 짜면 그냥 테스트 코드를 짠 시간을 버리는 느낌이 든다.

기능이 변경이 된다면, 테스트 코드도 바꿔줘야 한다. TC가 많다면? 그냥 가끔 현타온다.

코드에 애정을 주지 말라는 얘기가 있는데 나는 사랑쟁이인가보다.

그래도 테스트 코드는 작성한다. 안그러면 나중에 변경사항이 있을 때 너무 헬이다.

이 얘기가 테스트 코드가 생산성을 증가 시킨다는 의미인가?

그냥 미래 (추후 변경사항) 를 생각해서 현재 노력하는 느낌이다.

쉽게 말하면 보험료를 내는 것이다. 나중에 아프고 나면 돈이 많이 드니까 지금 야금야금 내는 느낌

미라클 모닝 후기

호구마츄 — Sun, 2 Jun 2024 14:00:19 +0900

최근 미라클 모닝을 실천하고 있습니다.

아래 게시글에서 매우 일찍 출근하기를 언급한 적이 있습니다.

2024.05.12 - [잡담] - 탑다운 회사에서 개발자로 잘 자라기

탑다운 회사에서 개발자로 잘 자라기

개요시드 단계(+ 시리즈 A)의 스타트업에서 재직을 했을 때는 정말 빠르게 움직였습니다.소수의 인원으로 행동하다보니 많은 역할을 담당하였습니다.이때 배운 것은 매우 소중했습니다. 그러나

hogumachu.tistory.com

미라클 모닝에 대한 저의 생각은 다음과 같습니다.

장점

이동 시간이 줄어든다

지하철만 이용한다면 관계는 없겠지만 버스를 이용하는 입장에서 확실히 차가 막히지 않습니다.

보통 새벽에 버스를 타면 1시간 20분 정도 걸립니다.

일반적인 출근을 하게 되면 최소 2시간이 걸립니다.

사실상 40분 이상을 세이브 하고 있습니다.

업무 집중력이 올라간다

출근하자마자 바로 컴퓨터에서 앉아서 일하는 것은 쉽지 않습니다.

와서 커피도 내리고 더우면 에어컨, 선풍기를 통해 조금 식혀줘야 합니다.

일찍 출근하게 되면 위의 일은 이미 다 진행한 상황이며 이미 개인 공부를 하고 있었기 때문에 업무 시간에 더 높은 집중력을 발휘할 수 있습니다.

퇴근 후에 놀아도 된다

저 같은 경우에는 퇴근 후에는 보통 방전이 됩니다.

일찍 출근하나 늦게 출근하나 방전되는 것이 똑같아서 퇴근 후에 공부하는 것을 출근 전으로 당겨서 썼습니다.

그러니 퇴근해서 띵가띵가 놀아도 마음이 편하더라고요

단점

야근하면 큰일

야근하면 진짜 치명적입니다.

저는 보통 11시~12시쯤 취침하는데 이 시간을 넘어가면 다음날 영향이 너무 크게 옵니다

결론

사실 퇴근하고 자기 계발에 열심히 한다면 똑같습니다.

그러나 퇴근 시간의 지옥철을 경험하면 쉽지 않더라고요.

5월 동안은 출근해서 책을 읽었는데 대략 2권 정도 읽을 수 있었습니다.

조용하다 보니 책을 읽을 때 집중도가 확실히 올라가더라고요.

집이 멀거나, 퇴근 후에 자기 계발이 어렵거나 하시면 미라클 모닝 추천드립니다!

탑다운 회사에서 개발자로 잘 자라기

호구마츄 — Sun, 12 May 2024 10:48:16 +0900

개요

시드 단계(+ 시리즈 A)의 스타트업에서 재직을 했을 때는 정말 빠르게 움직였습니다.

소수의 인원으로 행동하다보니 많은 역할을 담당하였습니다.

이때 배운 것은 매우 소중했습니다.

그러나 최근 이에 비해 많이 경직된(부정적인 것이 아닌, 탑다운 의사결정) 회사에 입사하게 되었습니다.

어떻게 잘 성장할 지에 대한 생각을 나열한 글입니다.

Case 1. 회사의 업무는 경직되지 않았을 때

제 생각에 가장 최고의 케이스라고 생각합니다.

자신이 하고 싶은 일, 추가하고 싶은 기능 등 여러 요소를 비교적 편안하게 선택할 수 있습니다.

만약 프로젝트를 처음 시작할 때 React, Vue 등 어떤 것을 사용할지 선택하게 됩니다.

그리고 선택을 하기 전에 각 선택지에 따른 장단점과 선택하며 얻는 것을 작성하기를 바랍니다.

ADR(Architectural Decision Records) 방식으로 문서화하는 것을 추천드립니다.

https://swalloow.github.io/feat-adr/

개발자가 의사결정을 기록하는 방법 (feat. ADR)

개발자들에게는 항상 다양한 선택지 중에 하나를 골라야 하는 상황이 주어집니다. 가장 간단한 예시로는 어떤 언어/프레임워크를 사용할지, 어느 버전을 사용할지에 대한 결정입니다. 오늘은

swalloow.github.io

Case 2. 회사의 업무가 경직되었을 때

단순히 작업이 주어지고 이를 그냥 해결하면 되는 상황입니다.

회사에서 "React 말고 Vue 사용하고 결제는 Toss SDK 써" 라고 말합니다.

(만약 내가 ADR을 잘 작성해서 보고하여 바뀐다면 Case 1에 해당합니다)

이럴 때는 회사에서 선택한 기술에 대한 ADR을 작성합니다. 마치 내가 의사결정을 내린 것처럼 말이죠.

이렇게 하면 좋은 부분이 있습니다.

바로 스스로 세뇌를 합니다.

React가 Vue 보다 좋은데, Kotlin이 Java보다 좋은데, SwiftUI가 UIKit보다 좋은데...

이런 생각을 가지고 있어도 각자의 좋은 부분을 찾게 됩니다.

그러나 역효과가 발생할 가능성도 있습니다.

바로 ADR을 작성하는데 도저히 장점을 못 찾을 때입니다.

Case 3. 회사가 진짜 별로인 선택을 할 때

(당연히 설득을 해봤지만 통하지 않을 때라고 가정합니다)

가장 쉬운 방법은 런(이직)입니다 ( )

다음은 힘 빼기입니다.

아, 회사에서 내가 일을 하며 발전하는 것은 어렵겠구나라고 생각해야 합니다.

이럴 때는 정말 회사에서 원하는 업무의 양과 힘을 주어 퇴근 후에 스스로 성장하기 위한 노력을 더욱 해야 합니다.

기본적인 것들

1. 문서화하기

신입 이후에 이직을 하며 느낀 것이 바로 일하면서 문서화를 바로바로하자입니다.

내가 어떤 업무를 하였고 그 업무로 인해서 어떠한 결과가 있었는 지를 반드시 작성해야 합니다.

나중에 이력서 쓸 때 있고 없고 차이가 너무 컸습니다.

2. 매우 일찍 출근하기 (선택)

매우 일찍 출근하여 일찍 퇴근이 가능하면 빠르게 하는 것도 좋습니다 (빨리 퇴근하고 집에서 자기 계발)

또는 일찍 퇴근이 불가능하다면 출근 시간 이전에 개인 공부를 하고 출근 시간부터 업무를 시작합니다.

이렇게 되면 업무 집중도 또한 늘어서 예상보다 빠르게 회사 업무를 마무리할 수 있습니다.

저도 7시 이전에 출근하여 개인 프로젝트나 책을 읽고 있는데 꽤 만족스럽습니다.

3. 블로그 (또는 아카이빙)

문서화와 비슷합니다.

나의 생각이나 경험을 사내의 규정에 어긋나지 않은 선에서 게시합니다.

글을 쓰면 장점이 어쩌고저쩌고... 가 있지만 일단 뭔가 한 것 같습니다 (성취감)

내가 어떤 사람인지 표현하기 쉽습니다 (자기 PR 가능)

마지막으로 이력서에 활용하기 좋습니다.

예를 들어, 저는 개발을 사랑하며... 이렇게 얘기하면 설득력이 적습니다.

저는 SOLID 원칙의 장단점을 파악하여 프로젝트를 설계하였습니다. (https://hogumachu.tistory.com/38)
또한 최근에는 테스트 코드의 중요성을 뼈저리게 느껴 테스트 작성을 열심히 하고 있습니다. (https://hogumachu.tistory.com/36, https://hogumachu.tistory.com/37)
개인 프로젝트에서 테스트 자동화 및 커버리지를 80%로 올려 기능 추가 및 변경에 안정성을 부여하도록 노력하고 있습니다 (https://github.com/hogumachu/InMyMemory)

결국 글을 남기지 않는다는 것은 자신이 한 행동이 팩트인지 아닌지 확인하기 어렵게 만드는 것입니다.

결론

핵심은 문서화(회사에서)와 블로그(또는 아카이빙)입니다.

이를 통해 내용 정리를 하여 내 머리에 한 번 더 각인시키며 이직 시 어느 정도 설득력을 얻게 됩니다.

다 작성하고 보니 커리어 향상보다는 글 써라 라는 내용이 되었습니다 (ㅋㅋㅋ)

근데 진짜 중요한 것 같습니다.

귀찮아도 언젠가는 '아 저 때 뭐였더라', '아 그때 뭐 했는데'라는 순간이 찾아옵니다.

[iOS] SwiftUI, TCA 모듈화 그리고 RIBs

호구마츄 — Sun, 5 May 2024 00:34:03 +0900

개요

최근에 SwiftUI와 TCA 조합으로 개인 프로젝트를 진행하고 있습니다.

사내 새로운 서비스도 TCA를 사용할 것 같은데 아마 설계까지 해야 할 것 같습니다.

그런데 TCA로 제대로된 모듈화가 너무 어렵더라고요..

이에 대한 트러블 슈팅과 생각 정리를 좀 해봤습니다.

TCA에 대해 깊게 알고 작성한 글이 아니므로 잘 걸러서 들어주세요!

다른 좋은 방법이 있다면 말씀해 주시면 조언 부탁드리겠습니다. ‍♂️ ‍♂️

SwiftUI, 모듈화가 어려운 이유

SwiftUI의 장점은 너무 많습니다.

일단 선언형이라 직관적이며 UIKit에 비해 적은 코드로 UI를 그릴 수 있고 등등... 아주 많습니다.

그러나 제 생각에는 단점도 꽤나 치명적입니다. 바로 View에서 내비게이션(라우팅)을 관장합니다.

물론 View를 Builder 패턴으로 주입하는 것도 가능은 하겠으나 결국 Builder가 반환하는 View의 구체 타입을 알아야 합니다.

왜냐하면 View의 body 내부에는 'any View'가 들어갈 수 없기 때문입니다.

Body 내부에 구체 타입 주세요

샘플 코드

이렇게 되면 결국 View는 다른 모듈의 구체 타입인 View를 알고 있게 됩니다.

즉 모듈끼리 강한 연결이 된다는 의미입니다.

이는 결국 반쪽짜리 모듈화가 된다는 의미기도 합니다.

TCA 모듈화

TCA도 똑같습니다.

Reducer에서 다른 Reducer의 State, Action을 알아야 합니다.

결국 연결될 수밖에 없습니다.

Reducer에서 ifLet, Path 등을 활용하여 다른 Reducer와 연결이 됩니다.

해결 방법 (시도만 함)

https://github.com/hogumachu/RIBs-TCA

GitHub - hogumachu/RIBs-TCA: Combination of RIBs and TCA.

Combination of RIBs and TCA. Contribute to hogumachu/RIBs-TCA development by creating an account on GitHub.

github.com

역시 익숙한 것이 좋습니다.

자주 사용했던 RIBs를 통해 시도했습니다.

위에 있던 문제는 사실 UIKit의 계층 구조를 따르면 쉽게 해결됩니다.

(자세한 내용은 해당 링크를 확인해 주세요)

장점

SwiftUI의 UI 그리는 방식 사용 가능
TCA의 좋은 기능 (@Dependency, 단방향 데이터 흐름 기타 등등) 사용 가능
내비게이션 로직 분리

RIBs에서 View 영역을 SwiftUI로 대체했으며 Interactor 내부의 동작을 TCA의 Reducer와 합친 것입니다.

개인적으로 생각했던 SwiftUI의 장점인 선언형과 빠른 UI 구성을 활용할 수 있습니다.

그리고 단점이라 생각한 View에서의 내비게이션도 제거하였습니다.

단점

TCA의 좋은 기능을 사용하지 못함 (내비게이션)
러닝커브 2배 (RIBs, TCA)
불필요한 RxSwift에 대한 의존성 (RIBs는 RxSwift 의존성이 있음, ModernRIBs를 사용하면 해결되긴 함)

결론

다른 좋은 해결 방법이 있을 것 같은데 SwiftUI와 TCA에 대한 이해도가 낮아 다른 방식으로 풀어봤습니다.

기존에 RIBs를 사용했다면 부분적으로 SwiftUI (굳이 TCA가 없어도)를 추가하여 해결해도 좋을 것 같습니다.

그리고 RIBs를 아키텍처로 알고 있었는데 프레임워크라고 하더라고요 ㅋㅋ..

결국 RIBs로 프레임워크를 구성하고 내부의 아키텍처를 TCA로 하는 거라 어울리는 것 같기도 합니다.

3줄 요약

SwiftUI는 View에서 내비게이션 역할을 하기 때문에 인터페이스/구현체 구조의 모듈화가 어렵다.

UIKit의 View 계층 구조를 활용하면 이를 해결할 수 있다.

RIBs+TCA로 시도해 봤는데 잘 되었다.

[OOP] SOLID 원칙 for iOS

호구마츄 — Sat, 2 Mar 2024 17:34:51 +0900

개요

학부 시절에 SOLID 원칙에 대해 열심히 암기했던 기억이 있습니다.

예전에 SOLID 원칙에 대해 잘 지키고 있나요?라는 질문을 받았는데 '네'라는 답을 하기가 꽤 어려웠습니다.

iOS 앱을 만들며 느꼈던 SOLID 원칙을 잘 지키고 있는 지 함께 알아봅시다.

SOLID 원칙이란?

로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙
유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있습니다.
(출처: 위키백과)

결국 핵심적인 부분은 유지 보수와 확장이 쉬운 시스템인 것 같습니다.

S: 단일 책임 원칙

Single Responsibility Principle

한 클래스는 하나의 책임만 가져야 한다

해당 원칙은 핵심은 복잡성을 줄이는 것 입니다.

iOS 개발을 하다 보면 MVC, MVVM 등 여러 아키텍처를 접하게 됩니다.

(아키텍처에 대한 설명은 따로 하지 않고 진행하겠습니다)

MVC

MVC의 ViewController는 정말 많은 역할을 하고 있습니다.

사용자의 이벤트를 받고, 이벤트에 대한 동작을 진행하고, 라우팅도 진행하고...

많은 일을 하고 있죠

결국 단일 책임 원칙을 위반하고 있습니다.

ViewController는 UI 로직, 비즈니스 로직, 라우팅 로직 등 많은 책임을 지고 있습니다.

ViewController의 역할

MVVM

MVVM은 비즈니스 로직을 ViewModel로 이전하였습니다.

ViewController는 UI 로직, 라우팅 로직을 책임집니다.

이것에 만족하지 않고 MVVM-C라는 Coordinator 패턴이 들어간 아키텍처도 있습니다.

Coordinator가 라우팅 로직을 책임지며 많은 부분이 분리되었습니다.

MVVM-C의 역할

이처럼 단일 책임 원칙은 아키텍처뿐만 아니라 앱 개발을 하며 Custom View를 만들어 Custom View 끼리 합치는 것 또한 단일 책임 원칙을 지키는 것이라 볼 수 있습니다.

O: 개방/폐쇄 원칙

Open/Closed Principle

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

즉 새로운 기능을 추가할 때 작성된 코드가 깨지지 않아야 합니다.

앱 개발을 하며 개방/폐쇄 원칙을 가장 어겼던 부분이 바로 enum을 입니다.

한 부분에서만 enum을 사용하면 상관이 없으나 많은 부분에서 enum을 사용하게 되면 케이스가 추가/제거될 때 연관된 코드가 모두 깨지게 됩니다.

enum Fruit {
  case apple
  case banana
}

func calculate(fruit: Fruit) -> Double {
    switch fruit {
    case .apple:
      return 1_000 * 1.1
    case .banana:
      return 2_000 * 1.1
    }
}

func store(fruit: Fruit) {
    switch fruit {
    case .apple:
      storageA.append(fruit)
    case .banana:
      storageB.append(fruit)
    }
}

예시 코드처럼 작성되었을 때 만약 Fruit에 새로운 과일이 추가되면 어떻게 될까요?

기존에 Fruit과 연관된 코드는 모두 깨지게 됩니다.

Fruit 예시

이러한 경우에는 Protocol을 이용하여 해결할 수 있습니다.

protocol Vegetable {
  var cost: Int { get }
  var storageType: Int { get }
}

func calculate(vegetable: Vegetable) -> Double {
    return Double(vegetable.cost) * 1.2
}

func store(vegetable: Vegetable) {
    if let storage = storages[vegetable.storageType] {
      storages[vegetable.storageType] = storage + [vegetable]
    } else {
      storages[vegetable.storageType] = [vegetable]
    }
}

이렇게 해결할 수 있다고 enum 대신 Protocol만을 활용하는 것은 좋지 못한 것 같습니다.

현재 상황에서 가장 적절한 것을 사용하는 게 중요하다고 생각합니다.

L: 리스코프 치환 원칙

Liskov Substitution Principle

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

이는 부모 클래스 대신에 자식 클래스를 넣어도 잘 동작해야 한다는 의미입니다.

즉 자식 클래스가 부모의 동작을 깨뜨리면 안 됩니다.

iOS 개발을 하며 아래와 같은 코드를 많이 보셨을 겁니다.

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

NSCoder를 이용한 초기화를 막는 것입니다.

즉 부모 클래스 동작을 제한하는 것입니다.

required init?(coder: NSCoder) {
    super.init(coder: coder)
}

위와 같이 초기화를 하도록 만들면 해결됩니다.

protocol Animal {
  var age: Int { get }
  var isMale: Bool { get }
}

class Hospital {
  func doSomething(animal: Animal) {
    if animal.age > 10 {
      print("old")
    } else {
      print("young")
    }
  }
}

class MyHospital: Hospital {
  override func doSomething(animal: Animal) {
    // 사전 조건 강화
    if animal.isMale {
      return
    }
    super.doSomething(animal: animal)
  }
}

다른 예시로는 위처럼 부모 클래스의 동작에 사전 조건을 강화하여 위반하는 사례도 있습니다.

Hospital과 다르게 MyHospital은 출력문이 호출되지 않겠죠

I: 인터페이스 분리 원칙

Interface Segregation Principle

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

자신이 사용하지 않는 메서드가 있으면 안 됩니다.

protocol HomeUseCase {
  func requestValues() -> [String]
  func addSomething(value: String)
  func removeSomething(value: String)
}

final class HomeDetailViewModel {
  private let useCase: HomeUseCase
  
  init(useCase: HomeUseCase) {
    self.useCase = useCase
  }
  
  // 모두 접근 가능
  func doSomething() {
    useCase.requestValues()
    useCase.addSomething(value: "A")
    useCase.removeSomething(value: "A")
  }
}

홈 상세 화면에서는 requestValues만 필요한데 위와 같이 UseCase를 사용하면 addSomething, removeSomething과 같이 사용하지 않는 메서드도 사용할 수 있게 됩니다.

물론 그냥 '사용 안 하면 되지 않나?'라고 생각할 수 있지만 의도와 다르게 다른 개발자가 홈 상세 화면에서 해당 기능을 사용할 수도 있습니다.

따라서 의도대로 특정 부분만 열어주어야 합니다.

typealias MyUseCase = MyProfileUseCase & FriendUseCase

protocol MyProfileUseCase {
  func requestName() -> String
  func requestAge() -> Int
}

protocol FriendUseCase {
  func requestFriends() -> [String]
}

위와 같은 방식으로 인터페이스를 분리하여 typealias로 선언하는 방식도 존재합니다.

final class MyUseCaseImp: MyUseCase {
  
  func requestName() -> String {
    return "A"
  }
  
  func requestAge() -> Int {
    return 1
  }
  
  func requestFriends() -> [String] {
    return ["B", "C"]
  }
  
}

let friendUseCase: FriendUseCase = MyUseCaseImp()
let profileUseCase: MyProfileUseCase = MyUseCaseImp()

위와 같이 구현체를 구현한 후 생성하면 열어준 인터페이스만 접근이 가능하게 됩니다.

D: 의존관계 역전 원칙

Dependency Inversion Principle

프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안 된다"

final class Repository {
  func create(value: Int) { /* 생략 */ }
  func read(value: Int) -> Int {  1 }
  func update(value: Int) { /* 생략 */ }
  func delete(value: Int) { /* 생략 */ }
}

final class ViewModel {
  private let repository: Repository
  
  init(repository: Repository) {
    self.repository = repository
  }
}

ViewModel이 Repository 구현체를 의존

위와 같은 코드가 있다고 가정할 때,

만약 ViewModel에 있는 Repository가 CoreData나 SwiftData 또는 Realm으로 변경된다면 어떻게 해결해야 할까요?

1. Repository 자체를 변경한다.

2. ViewModel 전용 새로운 Repository를 만든다.

일단 Repository가 다른 곳에서도 사용될 수 있으므로 1번보다는 2번이 적합해 보입니다.

그러나 이 방법이 과연 옳은 것일까요?

결국 새롭게 변경되는 것은 Repository 부분인데 이로 인해 ViewModel이 깨지는 상황입니다.

이는 개방/폐쇄 원칙을 위반하는 것입니다.

또한 개발을 할 때 실제 데이터베이스를 사용하기 때문에 옳지 않은 방법입니다.

2만 개 정도의 데이터를 보여주고 싶다면 데이터베이스에 2만 개의 데이터를 하나하나 추가해야 됩니다.

protocol MyRepository {
  func create(value: Int)
  func read(value: Int) -> Int
  func update(value: Int)
  func delete(value: Int)
}

final class CoreDataRepository: MyRepository {
  func create(value: Int) { /* 생략 */ }
  func read(value: Int) -> Int {  1 }
  func update(value: Int) { /* 생략 */ }
  func delete(value: Int) { /* 생략 */ }
}

final class MemoryRepository: MyRepository {
  func create(value: Int) { /* 생략 */ }
  func read(value: Int) -> Int {  1 }
  func update(value: Int) { /* 생략 */ }
  func delete(value: Int) { /* 생략 */ }
}

final class MyViewModel {
  private let repository: MyRepository // 인터페이스 의존
  
  init(repository: MyRepository) {
    self.repository = repository
  }
}

ViewModel이 Repository 인터페이스에 의존

구현체가 아닌 인터페이스에 의존하게 하면 됩니다.

먼저 인터페이스를 생성하여 청사진을 그리고 그것에 대한 구현체를 만들면 됩니다.

우리는 MyViewModel에 상황에 적합한 Repository 구현체를 만들어 주입해 주면 됩니다.

이를 통해 MyViewModel과 MyRepository의 의존성이 역전이 됩니다.

결론

SOLID 원칙의 목적은 유지 보수와 확장이 쉬운 시스템이다.

iOS 개발에도 SOLID 원칙을 녹이면 좋다.

그렇다고 모든 부분에 강요하는 것은 좋지 못하다. 상황에 따라 잘 사용해야 한다.

해당 게시글의 전체 소스 코드는 아래 링크에서 보실 수 있습니다.

https://github.com/hogumachu/Laboratory/tree/master/SOLIDSample

참고

https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)

SOLID (객체 지향 설계) - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 컴퓨터 프로그래밍에서 SOLID란 로버트 마틴[1][2]이 2000년대 초반[3]에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어

ko.wikipedia.org

[iOS] ViewController 테스트 작성하기

호구마츄 — Sun, 28 Jan 2024 16:40:16 +0900

ViewController-ViewModel-Service

보통 테스트를 할 때 비즈니스 로직만 테스트를 하고 ViewController(UI)에 대한 테스트 작성은 미흡합니다.

왜 테스트가 미흡했고 어떻게 테스트를 작성할 수 있는지에 대해 알아봅시다.

테스트하기 어려운 이유 - 객체지향프로그래밍

전에 객체지향프로그래밍(OOP)에 대해 글을 작성했습니다.

2023.08.13 - [객체지향프로그래밍] - [OOP] 객체지향프로그래밍 기초

[OOP] 객체지향프로그래밍 기초

OOP의 개념 객체지향 프로그래밍 (Object Oriented Programming)은 프로그램을 단순히 데이터와 처리 방법으로 나누는 것이 아니라, 프로그램을 수많은 '객체(object)'라는 기본 단위로 나누고 이들의 상호

hogumachu.tistory.com

ViewController를 테스트하기 어려운 이유는 바로 캡슐화 때문입니다.

더하기 버튼을 누르면 값이 증가하고 빼기 버튼을 누르면 값이 감소하는 화면이 있다고 가정하겠습니다.

테스트 예시

캡슐화는 말 그대로 캡슐 안에 내용을 숨기는 것 입니다.

(알약 안에 있는 성분을 하나하나 확인하지 않고 우리는 그냥 알약을 먹습니다.)

만약 캡슐화를 하지 않았다면 위 예시를 테스트하는 것은 매우 간단합니다.

// 은닉화 하지 않은 ViewController

final class ViewController {
    let scoreLabel = UILabel()
    let plusButton = UIButton()
    let minusButton = UIButton()
}

func test_plus_button을_누르면_score가_1_증가한다() {
    // given
    let sut = ViewController()
    
    // when
    sut.plusButton.sendActions(for: .touchUpInside)
    
    // then
    XCTAssertEqual(sut.scoreLabel.text, "1")
}

위의 코드에 대한 테스트 작성이 매우 쉽습니다.

그러나 캡슐화(은닉화) 하지 않으면 외부에 의해 변경될 수 있으므로 캡슐화를 반드시 해야 합니다.

은닉화

접근성 식별자를 사용하자

Accessibility identifier를 사용하면 은닉화된 상태에도 UI Test가 가능해집니다.

https://developer.apple.com/documentation/uikit/uiaccessibilityidentification/1623132-accessibilityidentifier

accessibilityIdentifier | Apple Developer Documentation

A string that identifies the element.

developer.apple.com

모든 UI에는 접근성 식별자가 존재하여 이를 통해 은닉화된 값을 가져올 수 있습니다.

extension UIView {
    
    func search<T: UIView>(type: T.Type, accessibilityIdentifier: String) -> T? {
        for subview in subviews {
            if subview.accessibilityIdentifier == accessibilityIdentifier {
                return subview as? T
            } else {
                if let view = subview.search(type: type, accessibilityIdentifier: accessibilityIdentifier) {
                    return view
                }
            }
        }
        return nil
    }
    
}

해당 코드는 접근성 식별자를 통해 값이 존재하면 해당 객체를 반환하는 메서드입니다.

enum UITestError: Error {
    case emptyAccessibilityIdentifier
}

extension UIViewController {
    
    func search<T: UIView>(type: T.Type, accessibilityIdentifier: String) throws -> T {
        if let result = view.search(type: type, accessibilityIdentifier: accessibilityIdentifier) {
            return result
        } else {
            throw UITestError.emptyAccessibilityIdentifier
        }
    }
    
}

이런 식으로 UIViewController에도 메서드를 추가해 주면 사용하기 편리합니다.

ViewController 테스트 작성하기

final class ViewController {
    private let scoreLabel = UILabel()
    private let plusButton = UIButton()
    private let minusButton = UIButton()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        scoreLabel.accessibilityIdentifier = "score_label"
        plusButton.accessibilityIdentifier = "plus_button"
        minusButton.accessibilityIdentifier = "minus_button"
    }
}

먼저 접근성 식별자 값을 설정합니다.

func test_plus_button을_누르면_값이_1_증가한다() throws {
    // given
    let sut = ViewController()
    let button = try sut.search(type: UIButton.self, accessibilityIdentifier: "plus_button")
    let label = try sut.search(type: UILabel.self, accessibilityIdentifier: "score_label")

    // when
    button.sendActions(for: .touchUpInside)

    // then
    XCTAssertEqual(label.text, "1")
}

테스트를 작성합니다.

끝

결론

1. 캡슐화(은닉화)로 인해 ViewController 테스트하기 어렵다.

2. AccessibilityIdentifier를 활용하면 된다.

3. 좋은 라이브러리가 많으니 골라서 사용하면 더욱 쉽게 테스트할 수 있다.

해당 게시글의 소스 코드는 아래 링크에서 보실 수 있습니다.

https://github.com/hogumachu/Laboratory/tree/master/UITestSampleApp

[iOS] 테스트를 작성해야 하는 이유

호구마츄 — Sun, 21 Jan 2024 18:43:33 +0900

테스트 코드 왜 작성?

최근 면접을 보는데 테스트 코드를 작성해야 하는 이유에 대해 질문이 들어왔다.

단순히 내가 작성한 코드가 안전하다는 것을 보장한다는 답을 했다.

그런데 이후에 꼬리 질문이 들어오니 면접관의 질문과 답변에 털리고 왔다.

테스트 코드를 작성하지 않아야 하는 상황?

반대로 생각을 해보기로 했다.

일단 2가지 정도를 생각했는데

유지 보수를 전혀 하지 않을 생각일 때
기억력이 굉장해서 기존 코드를 수정할 때 어디에서 어떤 결과가 나올지 알고 있을 때

2번 케이스는 잘 없을 것 같고..

생각보다 1번 케이스는 많다.

짧은 기간동안 하는 프로젝트 경우에는 테스트 코드를 작성하는 것보다 빠르게 기능 개발을 우선으로 했다.

스타트업에서 재직할 때는 위 상황과는 달랐다.

기존에 추가한 기능이 유지될 가능성이 굉장히 낮았다.

이런 상황일 때 나는 이렇게 합리화했다.

코드 생명 주기가 짧으니 기존 코드 개선보다는 아예 새로 만드는 것이 더 빠를 것이다.
그냥 빠르게 기능 개발이나 하자.
테스트 코드를 쓰면 오래 걸린다.

그러나 반대로 추가한 기능이 오래 유지되는 경우도 있었다.

그리고 아무리 내가 작성한 코드라도 몇개월이 지난 후에 다시 슬쩍 봐도 이해가 되지 않을 때가 있다.

결국 내가 작성한 코드라도 기억력은 완전하지 않기 때문에 언젠가는 남이 작성한 코드가 되는 것이다.

테스트 코드를 작성해야 하는 이유

테스트 코드는 일종의 거름망이다. 라는 이야기를 인터넷에서 보았다.

테스트 코드가 있어야 수정을 했을 때 어떤 상황인지 알 수 있다.

만약 테스트 코드를 작성하지 않았다면 아래와 같은 상황이 생길 수 있다.

특정 코드가 수정이 되었을 때 이에 대한 영향을 받는 것들이 생긴다.
영향받는 것들을 하나하나 확인한다.
컴파일 에러가 난다면 좋지만 예상하지 않은 동작이 발생한다면 큰일이다.
만약 잘 동작한다고 생각하고 배포했지만 이미 배포한 상태에서 에러를 발생할 수 있다.
기존 기능 개발을 멈추고 핫픽스를 나간다.
핫픽스가 나갔지만 또 어디선가 사이드 이펙트가 생겼다.
(반복)

테스트 코드가 없을 때 상황

위의 이미지를 보면 결국 똑같은 것 아닌가? 하는 생각이 들 수 있다.

완벽한 테스트는 존재할 수 없기에 버그 발생 가능성이 0이 되는 것은 불가능하다.

그래도 테스트 코드가 잘 작성이 되어있다면 버그 발생이 줄어든다는 것은 명확한 사실이다.

테스트 자동화를 해야 하는 이유

테스트 코드 자동화는 필수라고 생각한다.

프로젝트의 크기가 커질수록 더욱 필요하다.

처음에는 모든 테스트 케이스를 돌려도 오래 걸리지 않는다.

그냥 몇초면 뚝딱하면서 테스트가 성공되고 PR을 올리면 된다.

그러나 프로젝트가 커질수록 내가 작성한 테스트 코드만 돌리고 프로젝트 전체 테스트 코드를 돌리지 않는다.

이렇게 되면 결국 테스트 코드를 작성한 이유가 사라지는 것이다.

자동화를 통해서 반드시 테스트 케이스를 통과하도록 어느 정도 강제가 있어야 한다.

요약하자면...

Q. 테스트 코드를 왜 작성해야 하나요?

A. 코드를 변경하는 것에 안전성을 부여하는 것 입니다.

Q. 안전하게 코드를 변경하는 것은 무슨 의미인가요?

A. 코드가 되었을 때 영향을 받는 다른 코드가 정상적으로 결과가 잘 나오는지 확인을 해야 합니다. 테스트 코드는 정상적으로 결과가 잘 나오는 지 확인 시켜주는 것이라고 생각합니다.

테스트 코드 작성에 대한 개인적인 생각입니다.

다른 의견 있으시면 댓글 달아주시면 감사하겠습니다! ‍♂️

[iOS] 모듈화를 해야 하는 이유

호구마츄 — Sun, 14 Jan 2024 16:50:10 +0900

개발을 하면서 왜 모듈화를 해야 하는지에 대한 개인적인 이유입니다.

다른 의견 있으시면 댓글 달아주시면 감사하겠습니다! ‍♂️

캡슐화

먼저 캡슐화에 대한 이야기를 하려고 합니다.

2023.08.13 - [객체지향프로그래밍] - [OOP] 객체지향프로그래밍 기초

[OOP] 객체지향프로그래밍 기초

hogumachu.tistory.com

캡슐화에 대한 자세한 내용은 위에 링크를 참조해 주세요.

모듈 수준에서도 캡슐화가 진행되어야 한다고 생각합니다.

만약 진행하지 않는다면 외부에서 마음대로 접근할 수 있겠죠.

특정 ViewController, ViewModel, UseCase 등 마음대로 생성할 수 있고 설정 값을 변경할 수 있겠죠.

기능을 다 쓰지 않고 있다.

모듈로 나누지 않는다면 주어진 기능을 다 사용하지 않는 것입니다.

Swift에서는 open, public, internal, fileprivate, private 이렇게 5개의 접근 제어자를 제공합니다.

모듈로 나누지 않는다면 open과 public을 버리고 있는 거죠.

모듈화 안하면 기능 제대로 안쓰고 있는 것

단일 책임 원칙

MVC 아키텍처의 단점이 ViewController가 많은 기능을 담당하는 것입니다.

저희는 이것을 비즈니스 로직을 처리하는 ViewModel을 만들어 역할을 분리했습니다.

모듈 또한 마찬가지입니다.

필요한 역할을 할 수 있도록 나눠야 합니다.

UIKit, SwiftUI 등 여러 모듈이 하나에 모여있다면 굉장히 무겁고 개발하기도 어려울 것입니다.

MVC & MVVM

Single/Multi Module

독립적으로 만들 수 있다.

만약 모듈화를 진행했다면 인터페이스/구현체 구조로 나누어 느슨하게 연결하여 모듈에서도 의존성 역전 원칙을 지킬 수 있습니다.

모듈에 데모앱을 적용할 수 있게 된다.
온전히 자신의 기능 개발을 할 수 있는 환경이 제공되므로 빠른 개발이 가능하다.
버그가 발생했을 때 무엇이 문제인지 파악하기 쉬워진다.

실제로 프로젝트를 진행하며 팀원들 모두 동일하게 겪었습니다.

그러나 이에 대한 단점도 존재했는데 하단에 서술하도록 하겠습니다.

독립적으로 만들어진 상황에서 개발했을 때 느낀 점

기능이 모두 독립적으로 만들어진 상황에서 개발했을 때 경험은 매우 좋았습니다.

다른 부분을 크게 신경 쓰지 않고 나만 잘하면 되는 상황이므로 속도는 매우 빨랐습니다.

그러나 이러한 상황 때문에 느낀 점이 몇몇 있습니다.

1. 이해도 차이가 굉장히 심해진다.

독립적이라 내가 개발한 기능 외에는 이해도가 현저히 떨어집니다.

이로 인해 추후 유지보수할 때 내 기능을 제외하고는 건드리기 어려워집니다.

이를 해결하기 위해 2가지 방법을 사용했습니다.

코드 리뷰를 꼼꼼하게 한다.
자주 서로 개발하던 기능을 바꾼다.

먼저 코드 리뷰를 꼼꼼하게 하는 것만으로는 해결이 불가능했습니다.

기능 개발이 바빠 꼼꼼하게 하는 것도 어려웠지만 꼼꼼하게 하더라도 이해도 차이가 있을 수밖에 없었습니다.

다음으로 서로 개발하던 기능을 자주 바꾸는 것인데요.

이를 통해 미처 빼먹고 갔던 부분도 파악하고 코드 리뷰를 하면서 왜 이런 식으로 개발했는 지 이해가 안 갔던 부분에 대한 히스토리를 직접 경험을 통해 이해가 되는 등 해당 문제는 해결이 되었습니다.

그러나 이 방식을 사용하며 개발 속도가 많이 줄어드는 단점이 존재하긴 했습니다.

2. 옳게 성장하고 있는 것인가에 대한 의구심

독립적으로 진행하니 사실상 특정 모듈만 공유하는 반쪽짜리 협업이 되었습니다.

서비스를 만드는 입장에서는 굉장히 빠르게 개발이 가능하므로 많은 장점이 존재했습니다.

그러나 배우는 입장에서는 아쉬운 부분이 부분이 많았습니다.

단순히 각 모듈별 연결하기, 공용으로 사용하는 모듈 제작하기 등 많지 않은 부분만 연관되었습니다.

즉, 각 모듈이 인터페이스로 느슨하게 연결된 것처럼 개발자끼리도 느슨하게 연결이 되었습니다.

물론 1번에서 작성한 방법으로 이해도 간격은 줄일 수 있었지만 팀과의 의사결정 방식 등 여러 부분에서는 아쉬운 부분이 많았습니다.

이를 해결할 수 있는 방법이 무엇이 있나 고민해봤습니다.

페어 프로그래밍을 진행한다.
자주 상황 공유를 진행한다.

페어 프로그래밍을 진행해 봤는데 꽤 좋았습니다.

많은 부분에서 비슷한 의사 결정을 하게 되었지만 그렇지 않은 부분도 많았습니다.

그럼 과연 얼마나 페어 프로그래밍을 진행을 해야 하는가에 대한 고민도 생겼습니다.

자주 상황 공유를 진행해봤는데 사람에 따라 불필요하다는 의견이 있어 오래가지 못했습니다.

꽤나 길어지는 경우도 있었기 때문입니다.

해당 경우는 결국 성장 중심으로 느꼈던 것이라 일할 때는 크게 반영되지 않는 부분 같습니다.

[iOS] ViewController Life Cycle (+ ViewIsAppearing)

호구마츄 — Sat, 2 Sep 2023 16:58:12 +0900

Overview

ViewController에 새로운 viewIsAppearing(_:) 메소드가 추가되었습니다.

새로워진 ViewController의 생명 주기와 레이아웃은 어떤 방식으로 설정이 되는 지 알아봅시다.

ViewController Life Cycle

ViewController에도 생명 주기가 있습니다.

메모리에 적재되어 레이아웃을 잡고 사용자에게 시각적으로 보입니다.

그리고 더이상 필요 없다면 사라집니다.

ViewController 생명 주기

init

잘 알고 있는 객체의 init 메소드입니다.

가장 먼저 호출이 됩니다.

loadView

ViewController가 관리하는 View를 만드는 메소드입니다.

View를 로드하거나 생성하여 View Property에 할당합니다.

애플 문서에 따르면 해당 메소드는 직접 호출하지 말라고 작성되어있습니다.

viewDidLoad

ViewController가 View 계층 구조를 메모리에 로드한 후 호출됩니다.

loadView 메소드를 통해 호출되었는지 nib 파일에서 로드되었는 지 관계없이 호출됩니다.

이 메소드를 override 하여 View에 대한 추가적인 설정을 할 수 있습니다.

viewDidLoad는 한 번만 호출되므로 초기 설정을 하기 좋은 메소드입니다.

viewWillAppear

ViewController의 View가 View 계층 구조에 추가될 예정임을 알리는 메소드입니다.

viewIsAppearing

(iOS 13.0 이상 그리고 Xcode 15 (작성일 기준 베타 버전) 에서 ViewController에 viewIsAppearing이라는 메소드가 추가되었습니다.)

ViewController의 View를 View 계층 구조에 추가하고 있음을 ViewController에게 알리는 메소드입니다.

viewDidAppear

ViewController의 View가 계층 구조에 추가되었음을 ViewController에 알리는 메소드입니다.

viewWillDisappear

ViewController의 View가 View 계층 구조에서 제거될 예정임을 알리는 메소드입니다.

viewDidDisappear

ViewController의 View가 View 계층 구조에서 제거되었음을 ViewController에 알리는 메소드입니다.

deinit

인스턴스가 메모리에서 해제될 때 호출되는 메소드입니다.

화면에 View를 표시하는 방법

애플 공식 문서에서는 viewIsAppearing(_:) 메소드에서 View에 대한 Content를 업데이트하라고 합니다.

이미 View는 View 계층 구조에 추가되어있기 때문
frame, bounds, margin 그리고 inset이 정의되었기 때문

viewIsAppearing(_:) 메소드에 작성한 코드는 View가 화면에 처음 보여질 때 반영이 됩니다.

override func viewIsAppearing(_ animated: Bool) {
    super.viewIsAppearing(animated)
    print(" ", #function)
    print("SafeAreaInsets:", view.safeAreaInsets, #function)
    print("ViewFrame:", view.frame, #function)
    print("SomeViewFrame:", someView.frame, #function)
}

viewIsAppearing(_:) 메소드에서는 ViewController의 View와 ViewController의 여러 값들은 잘 반영이 되어있으나 SubView에 대한 값은 아직 반영이 되지 않음을 알 수 있습니다.

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
    print(" ", #function)
    print("SomeViewFrame:", someView.frame, #function)
}

viewDidLayoutSubViews() 메소드를 통해 SubView에 대한 frame 값을 얻을 수 있습니다.

2개의 ViewController에서의 Life Cycle (NavigationController 사용)

ViewController Life Cycle

ViewController의 생명 주기를 다시 살펴보면 위와 같습니다. (deinit이 빠져있군요)

NavigationController를 활용하여 ViewController 이동

초록색 ViewController 에서 붉은색 ViewController 로 이동하고 다시 돌아올 때 ViewController가 호출하는 메소드를 살펴봅시다.

2개의 ViewController Life Cycle

초록색 ViewController (aka. GVC) 에서 붉은색 ViewController (aka. RVC)로 이동할 때를 살펴봅시다.

1. RVC가 init, loadView 그리고 viewDidLoad까지 진행된 후에 GVC의 viewWillDisappear 메소드가 호출됩니다.

2. RVC의 viewIsAppearing 메소드가 호출된 후에 GVC가 사라지고 RVC가 등장합니다.

3. RVC에서 GVC로 돌아올 때, RVC가 먼저 자신이 사라진다고 알린 후 GVC는 viewWillAppear, viewIsAppearing 메소드를 호출하게 됩니다.

4. RVC가 사라지고난 후 GVC는 나타나고 그 후 RVC는 deinit이 되어 메모리에서 해제됩니다.

2개 ViewController의 메소드들을 print로 출력한 것

마무리

간략하게 추가된 viewIsAppearing과 다른 메소드에 대해 살펴봤습니다.

viewIsAppearing 메소드가 한 번만 호출되는 줄 알았지만 여러 번 호출되더라구요. (viewWillAppear -> viewIsAppearing)

viewIsAppearing 에 초기 설정을 하면 다시 돌아왔을 때 초기 설정으로 돌아옵니다. 따라서 잘 확인하고 사용해야할 것 같아요.

읽어 주셔서 감사합니다.

참고

https://developer.apple.com/documentation/uikit/uiviewcontroller/1621454-loadview

https://developer.apple.com/documentation/uikit/uiviewcontroller/1621495-viewdidload

https://developer.apple.com/documentation/uikit/uiviewcontroller/1621510-viewwillappear

https://developer.apple.com/documentation/uikit/uiviewcontroller/4195485-viewisappearing

https://developer.apple.com/documentation/uikit/uiviewcontroller/1621423-viewdidappear

https://developer.apple.com/documentation/uikit/uiviewcontroller/1621485-viewwilldisappear

https://developer.apple.com/documentation/uikit/uiviewcontroller/1621477-viewdiddisappear

https://developer.apple.com/documentation/uikit/view_controllers/displaying_and_managing_views_with_a_view_controller#3370691

https://developer.apple.com/videos/play/wwdc2023/10055/?time=128