티스토리 뷰
입사 후 지금까지의 개발 타임라인 별 프로젝트 후기를 작성하는 글입니다.
포토위젯은 2주에 한번 빌드하고 있습니다.
1. 설정화면 리펙토링.
기간은 약 1달이였습니다.
처음 SwiftUI와 TCA를 사용하며 적응하는 기간이였습니다.
사실 별 건 없었고, OldMySettingViewController를 SettingView로 리펙토링하는 작업이였습니다.
너무 어려웠고, TCA의 화면전환 방식도 머리속에 들어오지 않아 정말 간단한 작업인데도 꽤 오랫동안 작업하였습니다.
해당 기술들을 적용시켜 개발하는 것은 거의 iOS개발을 처음하는 듯 한 느낌이였습니다...
2. 포토위젯의 메인화면 투데이 페이지 개발.
기간은 3주였습니다. iOS - 1인
처음으로 SwiftUI를 제대로 사용하고, 많이 공부한 프로젝트 입니다.
그림자 설정, 기기별 화면에 맞춰 뷰의 비율을 갖게 유지하기 등 많은것을 공부하고 구현하였습니다.
하지만 그 중 가장 기억에 남는 것은 Today화면 상단의 메인배너 입니다.
요구사항은 3'.12초에 한번 애니메이션과 함께 페이지가 전환되며, 사용자가 스크롤 중엔 페이지가 전환되면 안된다.' 였습니다.
일단 상위의 Vertical 방향의 스크롤뷰에게 뺏겨 해당 뷰의 좌우 스크롤 이벤트 감지가 되지 않았습니다.
그리하여 해당 뷰는 UIKit으로 구현하였습니다.
3초에 한번 멈추는 것은 Combine을 이용하여 Timer를 구현하였습니다.
해당 화면은 24년 3월부터 현재까지 포토위젯의 메인페이지를 유지중입니다.
구현 후 뿌듯함을 많이 느껴 함께 협업한 서버개발자, 디자이너, 기획자 4명이 투데이드림팀이란 팀명도 얻었습니다.
투데이드림팀은 대표님에게도 애정을 받고 있습니다 ㅎㅎㅎ
3. 포토위젯 API 교체작업
iOS - 3인, 담당 (회원관리, 투데이페이지 API)
약 4주간 포토위젯 앱내의 모든 API를 교체하는 작업을 하였습니다.
이전 포토위젯의 API는 C#으로 구현되어 있었으며, 사용하지 않는 API와 비효율적인 값을 받고 주는 API들이 존재하여 이를 정리하는 빌드였습니다.
그 중에서도 2번의 투데이화면과 함께, 로그인 관련 로직을 모두 작업하였습니다.
기존 게스트로그인 방식을 없애고, 이와 연결된 필요없는 로직들을 모두 정리하였습니다.
애플로그인을 한 이후, AccessToken값을 서버로 전송하여 포토위젯의 AccessToken값을 받습니다.
이후 이를 Header에 넣어 API통신을 하도록 구현하였습니다.
또한 로그인 상태에 대한 구독방식을 구현하였습니다. 그렇기에 로그인 여부에 따라 노출되는 UI가 다른 화면에서 이를 채용하여 사용합니다.
Token검증에 대한 API도 구현하였고, 이 또한 구독방식이 존재합니다.
4. 아이돌 구독 페이지 개발
약 4주에 거쳐 개발하였습니다. iOS - 3인
외주로 받은 프로젝트 였지만 완성도가 많이 부족하여, 사내 iOS팀원 전원이 개발하여 4주동안 완성도를 높이고 QA작업까지 완료하였습니다.
UI관련 QA를 주로 작업하였습니다.
5. 익스플로러 프로젝트.
iOS - 4인, 담당 ( 마이페이지, 위젯 다운로드 페이지 )
포토위젯의 앱 페이지 전반을 교체하는 프로젝트입니다.
해당 프로젝트 이전에 포토위젯 Splash 화면에서,
앱내에 존재하는 모든 위젯모델들을 압축파일로 다운받은 후 -> 이를 해제하고 -> json 디코딩을 완료한 뒤 -> ContentsManager 싱글톤에 이를 모두 저장합니다.
그렇기에 Splash화면에서의 로딩시간이 평균 40초정도로 상당히 길었습니다.
이러한 방식이 아닌, 사용자가 다운로드 받으려는 위젯모델만 다운로드 시 서버api로부터 가져오는 방식으로 변경하였습니다.
마이페이지를 구현하였습니다.
뷰 요소들이 상당히 많았고, 상황에 따른 애니메이션, 조건에 따른 노출화면의 경우의 수가 많아 뷰가 많이 무거워 졌습니다.
추후 이를 리펙토링 할 예정입니다.
이번 프로젝트는 SwiftUI + TCA보다 많은 요구사항들을 구현하는 과정, 정해진 일정안에 구현하기 위한 노력, 협업하는 과정이 제일 힘들었습니다.
기획서에 명시되어 있지 않았던 내용이 QA티켓으로 발행된 경우
QA마감기한까지 얼마 안남았는데, 누락되었던 내용에 새로운 요구사항이 추가되어 QA티켓으로 발행된 경우 상당히 당혹스러웠습니다.
사실 "이전부터 직빌드를 여러번 받아 드렸었는데, 한참 뒤 QA티켓으로 발행되었다는 것은, 중요도가 낮다고 판단하겠다."고 협의하였습니다.
디자인 QA.
1px, 1padding 등의 디자인QA 작업을 완료하자, 다음QA때 "그냥 원래대로 돌려주세요" 나 "아직 작아보이니 2px사이즈로 바꿔주세요~" 등의 내용들이 멘탈적으로 조금 힘들었습니다.
사실 리펙토링할 시간도 없이 일정에 쫓겨 최적화또한 정말 최소한으로 작업한 채로, 즉 기술부채를 잔뜩 쌓아둔 채로 달려왔는데, 디자인QA에 시간을 많이 쓰는게 조금 딜레마였습니다.
그래서 기"능적인 내용들과 사용자가 사용하는데 문제없을만큼의 최적화를 디자인보다 높은 우선순위로 두고 작업하겠다"고 디자이너들과 협의하였습니다.
입사 초에는 새로운 기술스택에 적응하며 기능을 구현하는게 가장 어려웠고, 현재는 타 팀원들과 의견을 조율하며 결정된 기한내에 개발을 하는것이 가장 어려운 것 같습니다.
왜 어려울까? 고민해보면
어려운 이유는 "상대방의 기분을 나쁘지 않게 하며, 저 또한 화내거나 당황하지 않고 제 상황을 잘 설명하며 협의점을 찾는 과정"이라 생각합니다.
이는 개발자로서 계속 노력해야 하는 과제라고 생각합니다.
'iOS > 스위프트' 카테고리의 다른 글
[iOS][Swift] 최근 채용공고 기술스택을 읽으면 드는 생각 (1) | 2024.10.13 |
---|---|
SwiftUI + TCA를 1년간 사용하고 느낀점. (2) | 2024.06.22 |
[Swift] 비용을 절약하는 앱 개발하기 (빠른앱 만들기) (0) | 2023.10.03 |
[SwiftUI] NavigationTree vs NavigationStack (0) | 2023.10.03 |
[RxSwift] Publish, Behavior, Replay 각각의 차이점. (0) | 2022.10.31 |