-
Notifications
You must be signed in to change notification settings - Fork 2
Boost‐SwiftUI‐2024.11.12(화).md
유정주 JeongJu Yu edited this page Nov 12, 2024
·
4 revisions
Boost‐SwiftUI‐2024.11.12(화).txt
- 2024.11.12 화 오후 9:02 ・ 98분 52초
- 권승용 유정주 윤동주 이준복 이창준 홍승현
- 클로버노트를 이용해 회의 내용을 기록하고, Claude를 이용해 요약, 편집했습니다.
- 참석자들이 WWDC 세션을 듣고 각자 다른 인상을 받음
- 한 참석자는 실무에서 직접 사용하지 않아 크게 와닿지 않았다고 언급
- CG(Core Graphics) 관련 내용이 재미있었다는 의견 제시
- 새로운 개념들에 대한 첫 인상
- 디클레어 뷰(Declare View)와 리졸브(Resolve) 개념을 처음 접함
- 설명을 위해 의도적으로 키워드를 붙인 듯한 느낌이 있다는 의견
- SwiftUI 빈센트의 유튜브 영상 참고
- 13일 전에 업로드된 영상에서 매크로 엔트리 관련 내용을 다룸
- 이를 통해 매크로 엔트리의 도입 배경을 이해
- Environment 관련 개선사항
- 기존 방식:
- 구조체로 Environment Key 준수
- Environment Values Extension 작성 필요
- 상대적으로 복잡한 구현 과정
- 매크로 사용 시:
- 간단하게 구현 가능
- 확장성이 좋음
- 코드 작성량 감소
- 기존 방식:
- 정의: 인터페이스를 너무 크게 잡지 말아야 한다는 원칙
- 목적:
- 클라이언트가 불필요한 인터페이스에 의존하지 않도록 함
- 인터페이스를 작은 단위로 분리하여 유연성 확보
- Java의 경우:
- 인터페이스라는 명확한 개념이 존재
- 언어 차원에서 인터페이스 지원
- Swift의 경우:
- 프로토콜을 통해 ISP 구현
- 프로토콜 합성을 통한 유연한 구현 가능
- 작은 프로토콜들을 조합하여 사용 권장
- 추상화 가능한 객체는 모두 인터페이스로 볼 수 있다는 의견 제시
- 객체지향 설계 원칙과의 연관성 논의
- 실제 개발에서의 적용 방안 토론
- 코드의 모듈화 향상
- 유지보수성 개선
- 테스트 용이성 증가
- 재사용성 향상
- 바깥쪽 원의 의미
- UI와 서버가 외부 세계와 연결되는 지점
- 의미론적으로는 맞지만 개발자 입장에서는 불확실한 표현이라는 의견
- 계층 구조의 흐름
- Entity부터 UI까지의 데이터 흐름 설명
- 실제 구현시 고려사항 논의
- API를 통해 데이터를 받아오는 패키지의 구조화 논의
- 다른 서비스의 API를 처리하는 전용 패키지 필요성
- 메인 프로젝트에서의 데이터 처리 방식 고민
- DTO/VO 변환 관련 고려사항
- 패키지에서 DTO를 VO로 변환하는 작업의 중복성 문제
- 각 계층에서의 데이터 변환 필요성 검토
- 장점:
- 모듈 간 의존성 분리
- 코드 재사용성 향상
- 유지보수성 개선
- 단점:
- DTO/VO 변환 작업 중복 가능성
- 개발 복잡도 증가
- 팀 내 커뮤니케이션 비용 증가
- 기존 프로젝트에서 패키지 분리 경험 공유
- 하나의 프로젝트를 패키지로 분리하는 과정의 어려움
- 팀원들 간의 협업 방식 변화
- 패키지 분리 결정 기준
- 프로젝트 규모
- 팀 구성원의 역량
- 유지보수 용이성
- 재사용 가능성
- 프로젝트 초기 단계에서는 작은 규모로 시작
- 필요에 따라 점진적으로 모듈화 진행
- 팀의 현재 상황과 리소스를 고려한 결정 필요
- 데드라인과 실용성 사이의 균형 고려
- 실무에서의 모듈화 경험 공유
- 신입/주니어 개발자의 성장 관점에서의 조언
- 기술적 선택의 이유를 명확히 할 것
- 현재와 미래의 트레이드오프 고려
- 실무 경험을 통한 판단력 향상
- 면접 상황에서의 활용 방안
- 모듈화 경험을 구체적 사례로 설명
- 의사결정 과정과 고민점 공유
- 기술적 성장 과정 표현
- Task와 Task.detached의 차이점
- 캔슬 전파 방식의 차이
- Task Local Values 공유 여부
- 구조체와 메모리 관리
- Reference Counting 관련 질문
- 메모리 해제 메커니즘
- 스터디에서 다룬 내용의 중요성
- 실제 면접 상황에서의 답변 방식
- 예상치 못한 질문에 대한 대처 방법
- 데이터 전송 시 안정성 확보 필요
- 오류 발생 시 리트라이 처리
- 불안정한 네트워크 상황에서의 데이터 전송 보장
- 백그라운드 상태에서의 처리 방안
- 두 가지 주요 접근 방식:
- 타임아웃 시간 조정
- 데이터 객체 크기 최적화
- 백엔드 연동 고려사항:
- API 분리 시 비용 대비 효과 분석
- DB 구조 변경 필요성 검토
- 다양한 테스트 방법 제안:
- 코드 레벨 테스트
- 시뮬레이터를 통한 네트워크 상태 테스트
- 3G/LTE 전환 상황 테스트
- Wi-Fi/셀룰러 전환 테스트
- 실제 사용 환경 시뮬레이션:
- 엘리베이터 상황 등 극단적 케이스 테스트
- 앱 백그라운드 전환 시 동작 확인
- 사용자 커스터마이즈 옵션 제공:
- 타임아웃 설정 가능하도록 구현
- 지역별 네트워크 환경에 따른 최적화 옵션
- 글로벌 서비스 고려사항:
- 국가별 네트워크 환경 차이 대응
- 유연한 설정 옵션 제공
- 폰트 레지스터 함수 구현 방식
- 중복 등록 문제
- 로그 출력 이슈 처리
- 실제 사용 시 고려사항:
- 다중 호출 허용 여부
- 에러 처리 방식
- 패키지별 독립적인 로컬라이제이션 파일 관리
- 각 패키지에서 사용되는 문자열만 포함
- 중복 방지를 위한 전략
- 구현 방식:
- 패키지별 독립적인 문자열 관리
- 네임스페이스 분리
- 스태틱 함수와 인스턴스 차이
- 레퍼런스 카운팅이 필요없는 경우
- 타입 함수 접근 방식
- 메모리 관리 관점:
- 인스턴스 생성 없이 코드 레벨 접근
- 스태틱 함수의 특성 이해
권승용 | 김대황 | 김인환 | 유정주 | 윤동주 | 이준복 | 이창준 | 홍승현 |
---|---|---|---|---|---|---|---|
ericKwon95 | qwerty3345 | loinsir | jeongju9216 | yoondj98 | junbok97 | SwiftyJunnos | WhiteHyun |