april

Self-Review/review_240430April.md

@@ -0,0 +1,109 @@
+# 24년 4월 회고 / 5월 목표
+
+
+5–7월간 육아휴직을 앞두고 있어서 나의 4월은 앞으로 7월까지의 대략적인 작업을 하느라 불태웠던 한달이었다.
+
+우리 iOS팀은 4인체제로 이루어져 있다.
+
+팀장님은 주로 PM역할을 하고 계시고
+
+내 위의 2명은 주로 신규프로젝트를 하나씩 맡고 있다.
+
+그리고 난 막내로서 자사 7개의 앱 프로젝트를 유지보수를 하면서, 아주 쉬운 신규 프로젝트를 들어가곤 했다.
+
+근데 이제 육아휴직으로 자리를 비우게 되자 이 업무들을 전부 나눠드리게?? 되었다.
+
+
+<br><br>
+
+# PrivacyInfo.xcprivacy🔑
+
+몇년 전부터 애플에서는 보안에 관하여 많은 무게를 두어왔다.
+
+2024년 연말부터 언급해왔던 PrivacyInfo 관련 업데이트를 실질적으로 해야할 시기가 되었다.
+
+내가 맡은 업무는 PrivacyInfo가 무엇인지, 그리고 어떻게 작성하는지에 대해 조사하는 것이었다.
+
+며칠간의 해당 작업에 대한 조사가 이루어졌고, 사내 iOS팀의 PrivacyInfo 작성 매뉴얼 또한 작성하였다.
+
+해당 내용은 관련 포스팅 ([https://h1guitar.tistory.com/323](https://h1guitar.tistory.com/323))으로 아웃풋을 마쳤고, 현 시점에는 ([https://wemakeapps.medium.com/how-to-quickly-get-a-privacyinfo-xcprivacy-file-for-your-ios-app-9b43e7b938fe](https://wemakeapps.medium.com/how-to-quickly-get-a-privacyinfo-xcprivacy-file-for-your-ios-app-9b43e7b938fe))이런 페이지도 생성되어 마치 Quicktype이라는 페이지를 통해 Codable모델을 만드는 것 처럼 간편한 생성이 가능해졌다.
+
+이 작업을 통해, 애플이 얼마나 보안과 관련하여 신경쓰고 있는지를 알았고,
+
+해당 프로젝트 및 서드파티 SDK에 대해서 내부 구조를 파악하고, 해당 버전들을 살펴보면서 기존에 사용하던 라이브러리들에 대한 이해도도 높아지는 계기가 되었다.
+
+앱스토어커넥트에서 베타심사를 진행하면 해당 작업이 잘 되어있는지에 대한 피드백 메일을 받을 수 있어서 사내 모든 앱 프로젝트를 점검받았다.
+
+
+<br><br>
+
+# DaumMap(KakaoMap V1) 서비스 종료로 인한 마이그레이션
+
+PrivacyInfo와 관련하여, 사용중인 라이브러리들을 조사하던 중
+
+2024년 7월부로 기존 카카오맵 ( DaumMapSDK )가 서비스 종료됨을 발견했다.
+
+그래서 KakaoMap V2 로 이전해야함이 공지되어있었다.
+
+자사 앱중 애슐리에서 해당 서비스를 이용중이었다.
+
+각 지점별 정보에서 지점위치를 클릭하면 해당 위치가 다음페이지로 넘어가면서 MapView를 생성하는 방법이었는데, 문제가 몇 가지 있었다.
+
+1번: 기존 DaumMap(KakaoMap V1) 의 사용법과 KakaoMap V2가 완전히 달라졌다는 것
+
+2번: 기존 애슐리에서도 단순하게 위치만 찍는게 아닌, 현재 위치에 대한 정보를 가져오는 비즈니스 로직이 결합되어, 해당 로직 종료후에 위치를 찍어야한다는 점
+
+덕분에 V1과 V2, 기존 앱의 비즈니스 로직 까지 3중으로 분석을 했어야만했다.
+
+그러다 보니 왜 V1에서 V2로 갈때 이런게 없어졌는지에 대한 이해도도 높아질 수 있었다.
+
+
+<br><br>
+
+# 사내 앱 모의해킹에 따른 앱 보완 작업
+
+자사 앱들은 하이브리드앱들의 비중이 높다.
+
+그래서 해당 웹페이지에 따른 ISMS 관련 앱 모의 해킹이 정기적으로 이루어진다.
+
+이번에 피드백 받았던 내용은 탈옥 루트에 따라 새로운 조치가 필요했다.
+
+구글링을 해보면 이에 관련하여 동일한 고민을 하는 사람들이 있었고, 신규로 추가된 탈옥 경로를 추가, 배포하는 작업을 매번 하는 것들도 동일하였다.
+
+현재 앱 유지보수 담당자로서 iOS팀에 제안한 것은, 자체 API에 탈옥경로를 추가하여
+
+매번 앱내에 탈옥 경로를 추가하여 배포하는 리소스를 줄이는 것이었다.
+
+물론.. 제안했던 사람으로서 책임지고.. API를 개발하였고, 자사 SPM 에서 해당 API를 호출하는 방식으로 탈옥체크하도록 수정하였다.
+
+다이나믹 스플래시(앱 스플래시를 다운로드하는 방법) 와 마찬가지로 심사 없이 Fetch할 수 있도록 처리한 것이다.
+
+기존 사내에서 구축한 API는 C# 으로 구축되어있어 오랜만에 하는 API 생성작업이었다.
+
+아내의 조리원 복귀후, 아빠로서 남편으로서, 팀의 막내로서 동시에 해내야할 것들이 많았던 한달이었다.
+
+또 육아휴직을 하기전, 유종의 미를 거두고 싶었기에
+
+회사업무도 치열하게 플래너에 적어가면서 진행했다.
+
+과연 질적으론 괜찮았을까? iOS개발 3년차로서는 스스로 생각하기에 부족했다고 생각한다. 더 효율적으로 처리할 수 있었을 순간들이 하루에도 여럿 있었을 뿐더러, 때로는 궂이 이렇게 까지 매달리지 않아도 됐었던 일들이기도, 아직 하지않아도 됐어야한 일이기도했다.
+
+그렇다면 양적으로는?
+
+선임 개발자분들이었다면 좀더 빠르게 개발할 수 있었을 것이라는 생각이 드는 업무들이 많았다.
+
+이번 카카오맵작업만 해도 개발문서를 보는데 들었던 시간이 생각보다 많이 들었기에 스스로 자존심도 많이 상했고, 나에 대한 메타인지도 좀 낮았다는 생각이 든다.
+
+그럼에도 해당 작업을 마치면 항상 매뉴얼을 작성하였고, 팀원들에게 공유했다. 이 작업은 앞 선 시간들로 이해도가 높았기에 오히려 시간이 적게 들었지만 내스스로 생각하기에 반드시 해야만하는 작업이었다. 이런 습관은 앞으로도 나를 위해서 혹은 팀을 위해서도 지속해야겠다는 생각이 든다.
+
+[##_Image|kage@b3NwyM/btsHqu5RmNe/AxtA1zz7G6wtfv6Linm2wk/img.webp|CDM|1.3|{"originWidth":1400,"originHeight":1867,"style":"alignCenter","width":500,"height":667,"filename":"1_P1lfi2RTcWwfDZ7lP1yKKg.webp"}_##]
+
+
+<br><br>
+
+## 5월 목표
+
+- 부족했던 iOS 동시성 보완하기
+- 커리어 정리하기
+- 아이에게 집중하기
+- 알고리즘 공부하기

iOS-Framework-UIKit-UIResponder-UIView-UIScrollView/UITableView_01_basic.md

@@ -71,7 +71,8 @@ class ViewController: UIViewController, UITableViewDelegate, UITableViewDataSour
 
 ```
 
-혹은 아래와 같이 나눠서 구현하기도 한다.   
+보통은 편의상 코드가독성을 위해 extension을 사용한다.  
+
 
 ```swift
 class ViewController: UIViewController { }
@@ -176,31 +177,47 @@ extension ViewController: UITableViewDelegate, UITableViewDataSource {
 
 <br><br>
 
-## TableViewCell을 재사용하기
+## 셀의 재사용 개념
 테이블뷰에서 가장 중요한 요소 중 하나이다.  
 테이블뷰는 스크롤할 정도로 여러개의 셀을 가지고 있을 때,  
 추가적으로 화면에 표시할 셀을 생성하게 되어있다.  
 
-그런데 매번 새로 생성하게 되면 자원을 낭비하게 된다.  
+그런데 매번 새로 생성하게 되면 자원을 낭비하기 때문에 사용하는 개념이 재사용이다.  
+
+메모리의 HEAP영역에 셀 관리용 Queue를 두고,
+한번에 화면에 표시될 분량의 셀들을 이곳에 저장해둔다. 
+그리고 화면을 스크롤 할 때, Heap영역에 저장된 셀을 꺼내서(Dequeue) 사용하는 것이다.
+
+이방법을 사용하게 되면 메모리를 보다 효율적으로 사용할 수 있다.
+
+다만 기존 셀의 UI와  새롭게 나타나야할 셀과 다른 경우에 UI를 업데이트 하기위한 로직을 추가해야한다는 것을 유념하자.
 
-그렇기 때문에 사용하는 개념이 재사용이다.  
 
-tableView에 셀을 관리할 Queue를 두고, 
-미리 그 Queue에 넣을 셀을 등록한다. 
-또 Queue에서 뺄 셀도 등록을 하게 된다.  
 
 <br><br>
 
 ### 셀 등록하기
-- UINib : 내가 사용할 테이블뷰셀 클래스
-    - 만약 커스텀 클래스를 사용한다면 해당 클래스를 넣어준다.  
+셀을 사용하기 위해서는 미리 그 Queue에 넣을 셀을 등록해야한다. 
+이 때, 어떤 셀을 사용할 건지 해당 셀의 객체타입의 타입 (메타타입; `ex UITableViewCell.self`)과 해당 셀 구분에 사용할 Identifier를 입력해야한다.  
+
+이 과정은 스토리보드를 사용하는 경우에는 Cell에 Class를 지정하고 ID를 선언함으로 대체된다.   
+
+
+- UINib : 내가 사용할 테이블뷰셀 클래스의 메타타입
+    - 만약 커스텀 클래스를 사용한다면 해당 클래스의 메타타입을 넣어준다.  
 - forCellReuseIdentifier : 구분에 필요한 ID
+
+
 ```swift
 // 재사용할 셀을 등록하는 메서드
 func register(UINib?, forCellReuseIdentifier: String)
 
 // 사용예
 tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell")
+
+// 커스텀 테이블뷰 셀인 경우
+tableView.register(MyTableViewCell.self, forCellReuseIdentifier: "cell2")
+
 ```
 
 <br><br>
@@ -211,6 +228,8 @@ UITableView는 reusableCell 큐에서 지정된 식별자(identifier)를 가진
 
 - withIdentifier : 구분에 필요한 ID
 - for : indexPath 
+
+
 ```swift
 func dequeueReusableCell(withIdentifier: String, for: IndexPath) -> UITableViewCell
 
@@ -221,7 +240,15 @@ func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> U
   cell.textLabel?.text = "Row \(indexPath.row)"
 
   return cell
+
+
+  // 커스텀 클래스 인경우에는 반드시 커스텀 테이블뷰 셀로 타입캐스팅을 해준다.
+  // let myCell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) as! MyTableViewCell
+  // cell.mainImageView.image = UIImage(named:"test")
+  //
+  // return myCell
 }
+
 ```
 
 <br><br>
@@ -270,3 +297,9 @@ extension ViewController: UITableViewDelegate, UITableViewDataSource {
 }
 
 ```
+
+<br><br>
+
+
+## HISTORY
+- 240514: register, dequeue개념 수정