[개인회고] ‐ 1주차
- 프로젝트 기획 및 디자인 확정
- iOS 프로젝트 설계 확정
- ⚙️ iOS 프로젝트 설계
- coordinator 패턴과 UIViewController를 반환할 ViewFactory
- 💪🏻 나의 성장 목표 설정
- 전체적인 프로젝트 진행 과정 + iOS 기술 습득의 부담
- ✍🏻 기획
- Epic, Story, Task로 기획을 분리하고 관리하는 것
- 문서화의 중요성
- ⚙️ iOS 프로젝트 설계
- coordinator 패턴의 학습과 샘플 코드 학습
- 💪🏻 나의 성장 목표 설정
- 하나의 기능, 하나의 패턴에 집중하자, 모든 걸 소화하는건 욕심!
- ✍🏻 기획
- 문서화와 습관 습득
iOS 아키텍처 설계
기본적으로 JK의 버터플라이 아키텍처를 사용하는 것으로 선택했습니다. 버터플라이 아키텍처란 Clean Architecture를 활용한 아키텍처로 UseCase로 의존성이 집중화 되는 구조입니다.
문제상황
- UI -> Presentation - Domain 까지의 의존성주입은 평소에 하던 방법대로 진행가능
- Network -> Data -> Domain으로의 의존성 주입은 조금 생소했습니다
- 모든 의존성을 UseCase로 모으는 과정에 있어 Coordinator역할을 하는 Router 외의 새로운 역할이 필요했습니다
해결방안
-
ViewFactory라는 새로운 역할을 가진 객체를 만들어 UIViewController를 반환하도록 했습니다 - Router는 ViewFactory를 가지고 상황에 맞는 ViewController를 네비게이션 해줍니다
의문점
- 아키텍처를 선택하는데에 있어 고민하는 것은 좋은 것 같습니다
- 다만 이 아키텍처의 장점이 무엇일까? 고민이 많이 되었습니다
- 의존성을 밖에서 관리해주면 무엇이 좋을까?
- 추상화를 하면 어떠한 장점이 있을까?
- 물론 추상화와 의존성에 대한 중요성은 스프린트기간동안 충분히 학습했습니다
- 하지만 아직 이 구조가 가지는 명확한 장점은 아마 프로젝트를 진행하며 느낄 수 있을 것 같습니다
- 코어타임에는 정말 최선을 다하자, 밤샌다고 되는거 아니다
- 기능 보다는 학습을, 사용보다는 이유를 중요시하자
아직 모르는게 많다는 건 초심자의 행운, 이를 소중히 여기자
의존성 방향이 신기한걸?
버터플라이 아키텍처에서는 양쪽 날개가 중앙의 Domain에 의존한다. 어떻게 의존성 방향을 중앙으로 모이게 할 수 있을지 고민이다.
화면사이의 데이터 전달은 어떻게 해야하지?
버터플라이 아키텍처에는 라우터가 있다. 라우터를 코디네이터 패턴으로 만든다면 UI가 트리구조로 나타내어질 수 있다.
화면 이동간 데이터를 전달하기 위해서 부모/자식 유즈케이스 사이에서 전달해야할지 부모/자식 라우터 사이에서 전달해야할지 고민이다.
의존성 주입은 누가해야할까?
전체적인 의존성 주입은 누가하는가? Router, View, ViewModel, UseCase, Repository를 만들어 서로의 의존성을 주입하는 역할은 어디서 하는지 의문이다.
- 기술적 성숙
- 이유있는 의사 결정
- 버터플라이 아키텍쳐에서 의존성이
UseCase로 몰리는 구조를 볼 수 있다. -
UseCase는 의존성 주입을 할 때,ViewModel과Repository를 주입 받아야 한다. - 결국, 모든 의존 관계를 알고 있어야 하는 객체가 필요하다.
- 그럼
누가모든 의존 관계를 알아야 할까? - 그
객체의 이름은 어떻게 해야 할까?
문제 상황
- 한 화면에서 대/중/소 카테고리에 대해 선택해야 함
- 각 카테고리에 대해 한정된 카테고리(6~8개)로 체크리스트를 분리해야 함
- 결국 모든 카테고리에
기타항목을 추가해야 하는 문제 발생
문제 해결
- 대/중/소 카테고리에 대해 화면별로 분리함
- 대/중/소 카테고리에 대해 많은 카테고리를 보여줄 수 있음
- 진행률을 위에 보여주어 Depth를 예측할 수 있어 사용자의 답답함 해결
- Depth가 많아지는 문제를 모든 단계에서
건너뛰기기능을 제공하여 사용성 증대
- 근거 있는 기술 스택 선정
- 다음 주까지 db와 인공지능 api를 선정하고 어떤 부분을 고려해 근거를 기록해두자!
- 세세한 기획과 계획을 바탕으로 개발 진행
api versioning
- NestJs에서는 api versioning을 지원을 해서 버전별로 api들을 관리할 수 있다.
- 앱 개발 같이 지속적으로 업데이트 하는 서비스에서 버저닝을 이용하면 api를 관리하기 좋다고 해 세부적으로 어떠한 기능인지 알아봐야겠다고 생각했다.
oracle 무료 인스턴스
- 아직 조금 먼 이야기지만, 실제로 앱 서비스를 배포하고 부스트캠프가 끝나고 서비스를 유지하기로 팀에서 결정했다.
- 네이버 클라우드 db와 서버 비용이 크레딧이 있어도 생각보다 비싸(월 18만워) 고민이었는데, 오라클에서 램 24기가 무료 인스턴스를 사용할 수 있게 해준다고 피어세션에서 공유해주셔서 오라클 쪽을 긍정적으로 검토해봐야겠다고 생각했다.
- 기획을 다같이 진행하며 화면 디자인부터, 에픽-스토리-태스크 정의까지 기획에 정말 많은 시간과 노력이 들어가 이게 잘하고 있는 것인지 걱정이 되었다.
- Notion에 다 만들어둔 Task들을 쭉 보니 세부적으로 나눈 만큼 개발할 때 큰 고민 없이 집중할 수 있을 것이라는 말이 무슨 말인지 알 것 같았다.
- 의사결정하는 과정들이 재미있었고 경험들이 많은 팀원들에게 많이 배우고 있어 최대한 많은 것을 배우고 기록하려고 노력하고 있다.
- 다음주부터 조금씩 조금씩 만들 건데 기대가 된다.
- 이번주까지는 열심히 NestJs 강의를 듣고 마무리할 수 있도록 할 것이다.
- 프로젝트 기획 및 디자인 확정
- NestJS 강의 시청
- 코어 수면 시간 지키기
프로젝트 기획 및 디자인 확정
- 기획이 생각보다 많이 어렵다. 하지만 다같이 회의에서 의견 교환을 통해 진행하니 나름 순조롭게 진행되었다.
NestJS 강의 시청
- 처음으로 NestJS에 대해 공부를 하고 있는데 진짜 너무 좋아보인다. 기존에는 다 직접 구현했던 것을 NestJS가 대부분 자동으로 해주고 그리고 반복적인 단순 노동을 줄여준다. 이를 통해 단순한 기능들은 최대한 빨리 구현해서 시간을 단축하고, AI API 최적화에 좀 더 집중할 수 있을것 같다.
코어 수면 시간 지키기
- 원래는 오전 7시에 자서 9시에 일어나고 낮에 다시 자는 망가진 생활 패턴으로 지냈는데 처음으로 12시에 자서 7시반 기상을 했다. 집중도가 올라가고 일의 능률이 증가했다.
스웨거
- 팀원 중 한분이 스웨거에 대해 알려주셨는데 NestJS를 구조를 알아서 분석해서 자동으로 API 명세서를 만들어 주는게 너무 신기했다. 이를 이용하면 API 명세서를 작성하는데 시간을 낭비하지 않아도 되고, 또한 구조가 바뀌면 즉각 반영되고, 또한 내가 짠 코드를 기반으로 만들어지니까 명세서를 만들때 실수할 일이 많이 줄어든다. 그렇기에 클라이언트와 소통할 때도 굉장히 좋아보이기에 스웨거에 대해 추가적으로 공부해보고 도입해봐야겠다.
도커
- 기존에는 도커를 postgres에만 적용했는데 팀원 중 한분이 nodejs까지 미리 세팅을 하셨다. 이렇게 하면 클라이언트에서는 도커 파일만 있으면 따로 환경 세팅 할 필요 없이 자동으로 세팅이 다 되기 때문에 협업 할 때 효율성이 매우 증가할 것 같다. 그래서 도커로 모든 환경을 세팅하는 것을 검토해서 도입할 예정이다.