Week2 멘토링 일지

✔️ 결론 및 To Do

공통

• 마일스톤 적용

iOS

• 플로팅 버튼 UIView 서브클래스로 구현
• UIDatePicker :
• 테스트 코드 구현 후에 작성
• 코드 컨벤션

BE

• ORM 확실하게 공부하기

✔️ 아젠다 및 질문

공통

• 현재의 기능적 요구사항의 양이 적당한지 궁금합니다.
• 멘토링 시간 외(코어타임 내)에 질문사항에 대해서 Slack에 올리면 될까요?

iOS 질문

• 테스트 코드를 작성하는 시기가 궁금합니다.
• 대여 가능 시간 설정 기능에 대해 구현중입니다. UIDatePicker를 사용하려 했으나 제공하는 기능인 [년 월 일 시 분]이 아닌 [년 월 일 시]만 필요하여 UIDatePicker에 없는 기능이라고 합니다. 그래서 UIPickerView를 사용했습니다. 찾아보니 UIPickerView를 UITextField와 사용하는 경우가 많았습니다. UITextField는 Text 입력에 사용한다고 판단하여 선택사항이 아니라고 판단했습니다. 다른 UI 요소에 inputView를 사용하여 UIPickerView를 사용할 수 있나요? 아니면 추천해주실만한 구현 방법이 있을까요?
• 각각의 코딩스타일이 다른데, 통일할 수 있는 좋은 해결방안이 있는 지 궁금합니다.
• 플로팅 버튼 커스텀 뷰를 구현할 때, UIView를 상속받고 UIButton을 프로퍼티로 둘지, UIButton을 상속 받아 플로팅 버튼 자체를 UIButton의 구체 타입으로 구현할지 고민했습니다. 현재는 UIButton을 상속 받아 구현했는데, 필요하지 않은 메소드와 프로퍼티들까지 상속 받는다는 느낌도 들었습니다 (너무 다양한 생성자). 현업에서는 커스텀 뷰를 어떤 방식으로 구현하는지 궁금합니다.

BE 질문

• 현재 이미지 저장을 object Storage 를 사용해서 진행하고 있는데 mysql 에 직접 저장하는 것 보다 좋은 방법인지 궁금합니다.
• ERD 구조 , db 를 join 없이 그냥 여러번 찾는 방식이 유행이라고 하는데 이게 맞는지 궁금합니다.
• 로그를 어디까지 남겨야 하는지 궁금합니다. (저희가 로그를 가지고 분석해보거나 오류를 찾아본 경험이 없어서 어떻게 활용할지 잘 모르겠습니다.)
• user 닉네임 중복 체크 없이 해시를 사용하는데 이 방법이 보안상으로 괜찮은 방법인가요?
• 개발용 db , 서비스용 db 를 현업에서 어떻게 사용하는지 궁금합니다 + (DBA)

진행상황

• 스프린트 1주차 백로그

• 전체 백로그

  현재 전체 백로그는 업데이트하고 있지 않습니다.

  작업 관리를 GitHub Project를 통해서 관리하고 있습니다.

저번주 멘토링 반영

공통

• 기획상 구현할 기능의 양이 많다는 피드백을 반영하여 기능을 많이 덜어냈습니다.
  • 대여 시간 관리 기능을 없애고 대여를 중개하는 플랫폼으로 전환했습니다.
  • 알림 기능을 없애는 것을 고려했지만, 채팅 기능에서의 알림을 남기기로 했습니다.

iOS

• JK님 프로젝트 제한사항으로 3rd-Party 라이브러리를 모두 금지했습니다…
• UIKit과 Combine만을 사용하기로 했습니다.

BE

• NoSQL 은 권장사항이기도 했고 다른 새로운 기능들 (채팅 , CI / CD , TypeORM ) 에 더 집중하고 싶어서 익숙한 MySQL 을 사용하기로 했습니다.

✔️ 멘토링 내용

멘토링 시간에 나눈 이야기를 기록해보세요.

공통

• 마일스톤 추가도 좋을 것 같다.

iOS

• 테스트코드 작성 - 개발과 동시에 진행하는게 좋은데 개발이 우선이다.
  • 현업에서도 테스트 코드 작성하는데 드는 시간이 요구사항 분석, 구현 시간보다 압도적으로 크다
  • 구현보다 테스트 코드가 우선시되는 것은 주객 전도다.
  • 대표적인 케이스에 대해서는 필수적이다.
• 코딩 스타일은 협의를 거쳐 진짜 한 사람이 작성한 것 처럼 맞춰야 한다.
• 커스텀 뷰는 UIView로 구현하는 것이 맞다. 플로팅 버튼도 UIButton이 플로팅 되는 것이 아닌 UIButton을 담고 있는 UIView가 플로팅되는 것일 것이다. 현업에서도 커스텀 뷰는 모두 UIView로 구현된다.

BE

• rocket.chat이라는 채팅 오픈소스가 있는데 채팅기능을 설계할 때 참고할 수 있다
• rocket.chat api 문서를 보면 설계할 때 도움이 된다. 따라하지는 말고 구조를 참고하여 공부해보면 좋다.
• Docker에 시간 쏟지 말고 api 기능 구현이 우선이다.
• MikroORM이란 ORM도 좋다. unit of work라는 기술이 있는데 이것이 특징이다. 또한 ORM 끼리 기능 비교하는 학습도 꼭해야한다.
• object storage대신 nginx, apache 같은 거 띄워서 직접 정적 파일을 서빙하는 서버를 구현해 볼 수도 있다. 이 방법이 좀더 학습하는데 좋다. 꼭 한번 해보면 좋겠다고 하셨다.
• ORM 은 확실히 알아야 한다.
• 외래키로 join 하는것은 선택의 문제이므로 상황에 따라서 선택해야 하는 문제임
• 객체 모델링 (UML) 은 꼭 해보는 것이 좋음
• 로그는 request , response 정도는 남겨라,모든것을 다 남기는 건 좀 비효율적임
• DB를 Docker 를 사용하면 로컬에서 하는게 편하다.
• 채팅할 때는 소켓, HTTP 둘 다 사용한다. 두 개 모두 경우의 수를 따져봐야함

✔️ 체크리스트

이번 주 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 멘토님과 이야기 나눈 후 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.

• 기술적 도전 과제를 중심으로 기획서와 백로그 및 feature list 등이 완비되었다.
• 기술 스택의 선정 이유 혹은 구현 방식에 대해 나만의 근거를 가지고 설명할 수 있다.
• 이번주 스프린트 계획을 세웠고, 목표한 만큼 구현하고 있다.
• 다른 팀원의 과제가 무엇이고 왜 그 일을 하고 있는지 설명할 수 있다.