1주차 멘토링

일자

2022년 11월 9일 수요일 19:00 ~ 21:00

체크리스트

• 앱 기획 의도
• Swift 컨벤션

미팅 진행사항

회원 가입 로직

• 6주 프로젝트에서 기획빼고 개발 5주이면 시간이 촉박하다. 회원가입은 공수(工數)가 크다. 웬만하면 회원가입, 로그인 로직을 빼고 MVP 기능에 집중하는게 좋다.
• 현재 캠퍼를 인증하려면 깃헙 로그인이 필요하다. 깃헙 권한 이슈를 해결해야 그 다음 단계가 가능해보인다.

MVP

• MVP 기능을 위주로 로직과 UI를 구현하고 추후에 기능을 추가하는게 좋아보인다. MVP를 먼저 뽑아내고 될지 안 될지를 확인하는게 필요할 것 같다.
• 현재 기획에서 블로그를 피드와 상세화면에 보여주는게 제일 우선순위가 높아보인다(= Home, Detail 화면). RSS로 받아온 블로그 정보를 목업으로 만들어 빠르게 확인하는 것이 필요해보인다. mocki 같은 사이트를 통해 목업 데이터를 사용해보자
• 앱 기획은 좋지만 현재 프로젝트에서는 서버가 없다. 6주 프로젝트 안에 서버를 구현할 수는 없다. 서버가 있다 가정하고, json 데이터를 받아 사용하자. 실제 로직(블로그 RSS를 구독해 피드를 업데이트하는 것)은 프로젝트가 끝나고 서버를 추가해서 진행하자.
• RSS로 오는 XML의 내용이 블로그마다 다른데 이걸 경우에 따라 파싱해서 보여주는 것이 충분히 도전적으로 보인다. 처음부터 모든 블로그 사이트를 처리할 수 없으니 1개를 하고 계속해서 추가하는 방향으로 가자.
• 블로그 상세화면에서 웹뷰로 연결 로직인데, 추후에 웹 뷰 이벤트 공부도 필요해보인다.
• 아무튼 가장 큰 우선 순위는 MVP를 정하고 빠르게 확인해보는 것이다.

디자인 시스템

• 우선 UI를 쪼개서 어떤 식으로 컴포넌트를 만들지 설계하는게 좋아보인다.
• 시간이 남으면 설정에 디자인 시스템 확인하기 창을 만들어보자. 컴포넌트를 마음대로 조정할 수 있는 화면을 만들면 시각화해서 보여줄 수 있으니 좋아보인다.
• 디자인 시스템을 분리하고 싶다 했는데, 서브 모듈로 쓸건지 라이브러리로 만들어서 쓸 건지 정하자. 큰 차이는 없지만 둘 중에 하나만 해야한다. 구조가 조금 다르다. 그래서 어떤 걸 하고 싶은지 잘 정해보고 정하자. 분리를 하게 되면 dependency 고민도 해야하고 복잡하지만 얻는 것도 많을 것 같다.

그 외 기능들

• 여러 가지 알람
  백엔드의 역할이다. 이게 중요하진 않으니까 나중에 확장할 때 하자. 파이어베이스로만 하면 오래걸림. (백엔드야 와줘…)
• 확장성
  확장성을 고려하자. 너무 많은 참조를 가지면 복잡해진다. private을 잘 사용해보자.
• 추가적인거 한다면 실시간 디버깅 할 수 있는 깃헙 레포가 있다. 레포를 설치해 활성화하면, 시뮬레이터에서 title 17 → 18 수정시 UI가 바뀌는 것을 한 번에 확인할 수 있다. 즉 특정상황에 대한 디버깅이 좋다. 디자인시스템이 컨셉이니까 디자인에 대한 예외 처리를 하면 좋아보인다.

Swift 컨벤션

• 파일 길이 (수정완료)
  개인적으로 400자는 조금 적어보인다. 개인적으로 700자 이내로 작성하는 것 같다
• 파일 구조
  이거는 프로젝트마다 다 다르다. 개인적으로 화면 단위로 나눈 다음에 그 안에서 Model, ViewModel을 나누는 것도 좋다. 아키텍쳐 정하고 추후에 확정하면 될 것 같다. 아키텍쳐가 중요하긴 하지만 개인적으로 MVVM이나 클린 아키텍쳐나 비슷하다는 생각을 한다. 뭐로 하든 잘 분리만 하면 될 것 같다.
• 함수 길이
  50줄 짧아 보이긴하다. 우선 사용해보고 추후에 짧다고 생각되면 늘려도 될 것 같다.
• 주석
  개인적으로 어떤 정책을 반영했는지, 어떤 의도에서 작성했는지를 주석으로 작성하는 편이다. 주석으로 문서화를 해도 되고, PR에 작성하는 팀도 있고 해서 이건 팀에서 정하기만 하면 될 것 같다.
• 결론
  컨벤션은 답이 없다. 팀끼리 잘 맞추는게 중요하다.

질문

• 🐶 승민 : 작은 기능 단위의 MVP를 먼저 만들어볼 때 4명이서 어떻게 일을 나눌지 모르겠다.
  기능 안에서 A타입, B타입을 나누고 2명씩 진행하면서 어떻게 되는지 확인해보자. 현재 기획을 예시로 들면, 블로그 피드 셀에 텍스트와 이미지가 같이 있는 경우 텍스트만 있는 경우가 있는데 이걸 나눠서 구현해보고 비교해보면 좋아보인다. 기능을 나눈다고 혼자서만 하는게 아니라, 각자 진행하고 합칠 때 공유를 잘해야 한다. 구조 잡을 때 (탭 바, 공통 컬러 설정 등) 할 때만 페어프로그래밍을 진행하고 그 외에는 기능을 나눠야 한다.
• 🐶 승민 : 기능이 너무 적은 거 같다.
  "무엇을", "왜" 했는지를 설명하면 충분하다고 생각한다. 추가로 무언가 하고 싶다면 프로젝트를 앱 출시까지 연결해보면 좋을 것 같다.
• 🐱 유탁 : 최신 블로그 피드를 업데이트 하려면 서버가 필요할 것 같다.
  현재 기획대로 하려면 서버가 무조건 필요해보인다. 다만 서버를 만드는 것은 6주 프로젝트에서 너무 무리해보인다. 서버가 있다는 가정하에 json을 파일 받아서 진행하자.
• 🐙 늘이 : 애니메이션 프레임워크로 만들어 많이 사용하는지?
  만들라면 만들 수 있다. 보통은 디자이너가 정해서 주는 걸 사용한다.
• 기훈 : 타입을 명시해주는 것과 추론하는 것의 성능차이

기타

• 현업에서 보통 백 -> 프론트로 API 명세서를 주는데, 역으로 프론트 -> 백으로 요청하는 경우도 있다. 비록 서버가 없지만 후자와 같은 상황을 가정하고 프론트가 직접 데이터 구조(=json)를 만들면서 학습할 수 있는 좋은 기회로 보인다.