3️⃣ 3주차 멘토링 일지

✔️ 멘토링 아젠다

멘토링 24시간 전에 준비하여 멘토에게 공유합니다.

논의 사항 및 질문

멘토의 조언이 필요한 부분을 질문으로 정리합니다.

걱정했던 협업은 많이 해결된 것 같습니다.

빠른 공유와 실시간 소통 → 슬랙과 게더 타운 활용
같이 논의해야하는 부분 → 페어 프로그래밍
회의를 통해 업무 목록 작성 후 분업

웹소켓 관련 테스트가 어려울 것 같음

백엔드는 서비스 계층을 분리해서 단위 테스트 유지하면 될 것 같은데 → 이것도 잘 쓰이는 방식인지 모르겠습니다.
프론트엔드 테스트는 어떻게 해야 하죠…

단위 테스트에 대해서

지금은 결과를 정해놓고 테스트 코드를 맞추는 느낌이라, 이게 의미가 있나 생각이 듭니다. → 리팩터링 시 빠르게 확인할 수는 있지만, 리팩터링이 자주 일어나는 일은 아니니까…
TypeORM이 제공해주는 레포지토리를 래핑한 메서드 같은 것도 테스트 대상이 되어야 할까요?
- → 커버리지만 올리는 단위 테스트가 될 것 같습니다. ⇒ 그래도 기분은 굿
- ++ 모킹을 하면 레포지토리 계층에 대한 테스트가 큰 의미가 있을지도 잘…

API 명세 공유에 대한 이야기

노션 명세서로 API 리턴 타입을 공유하고자 했었는데, 실시간 업데이트가 힘들고 관리가 잘 안됨
그래서 프로젝트 루트에 shared 디렉터리를 두고, 공유되는 타입을 적자고 결정을 했었습니다.
근데 매번 공유 타입을 빌드 해줘야하는 등 관리가 힘든건 마찬가지 인 것 같습니다.
그래서 nestia나 nestjs-trpc 같은 헬퍼 라이브러리를 알아보았지만, 오히려 추가적인 학습 곡선에 부하가 걸릴 것 같아서 배제했습니다.
FE/BE로 나뉘었던 dev 브랜치를 하나로 합쳐서 개발 서버를 하나 띄우고, swagger를 통해 확인하자고 최종 결정한 상태입니다.
→ 아직 전부 완료하진 않아서 괜찮은 방식인지 궁금합니다. 많이 사용하는 방식인가요?

프로젝트와 이슈에 대한 관리

현재 Github Projects가 잘 관리되고 있지 않습니다.
이슈 - PR - 브랜치 자동 연동이 잘되지 않아서 사용성이 떨어지는 상황입니다.
하지만 작업 상황에 대한 공유는 되어야 할 것 같아서 한 단계를 더 거치더라도 노션을 사용하는게 더 편할지 아니면 Github 프로젝트 자체 기능을 잘 활용하지 못하고 있는 것인지 궁금합니다.

다른 파트의 코드에 대한 이해 부족 문제

다른 파트에 대한 코드 리뷰를 진행하지 못하고 있습니다.
우려되는 점: 서로의 코드베이스에 대한 리뷰 부족
- 엄청나게 큰 문제는 아니지만 그래도 우리는 다같이 웹풀스택으로 들어왔는데… 루시님의 눈빛이 느껴집니다
- 서로 파트에 대한 진행상황을 정확히는 파악하지 못하고 있는 기분… 파악하고 싶어하는 상황이지만 nestJS, React 등 상대 파트 코드에 대한 진입장벽이 큰 것 같습니다

진행상황 및 참고 자료

멘토가 일지를 보고 멘토링을 준비할 수 있도록, 팀의 진행상황과 참고 자료를 정리해서 넣어주세요.

https://github.com/boostcampwm-2024/web15-OctoDocs

[지난 주 데모 영상]

Week.1.Demo.mp4

[그래프 뷰 동시 편집]

Liveflow.Screencast.1.mp4

[에디터 동시 편집]

Recording_3.mp4

웹 소켓 + YJS + Tiptap를 이용한 동시 편집 시연 영상

[J248]

Recording_4.mp4

[J032]

-.-2024-11-12-.-9.20.41.mp4

현재 진행도

에픽	FE 진행도	BE 진행도

노트 CRUD | 90% | 90%
연관 관계 보여주기 | 75% | 20%
실시간 편집 | 25% | 10%
추가 기능 | 0% | 0%

이번 주 예상

에픽	FE 진행도	BE 진행도

노트 CRUD | 90% | 90% → 이미지 업로드가 남아서…
연관 관계 보여주기 | 100% | 100%
실시간 편집 | 75% | 50%
추가 기능 | 0% | 0%

아직 부족한 점

[FE] 코드 퀄리티 (로직 분리, 재사용 가능한 컴포넌트 구성)
[BE] 통합 테스트
데모 배포
추가 기능에 대한 기획

✔️ 멘토링 내용

멘토링을 진행하며 나눈 이야기가 휘발되지 않게 기록해보세요.

팀 vs. 숙달된 개인
- 팀은 서로가 성장할 수 있는 구조. 한 명이 쉬어도 작업이 진행될 수 있다
소켓 테스트?
- Mock vs. Stub vs. Fake vs. Spy → 차이점에 대해 잘 숙지해보자
- 소켓을 통해 데이터를 받았을 때 어떤 비즈니스 로직이 실행 되는가에 대한 테스트를 진행해야 함
단위 테스트
- 정상 동작 happy pass / 실패 케이스 / 엣지 케이스
  - 현업에서는 4:3:1 (case by case / 엣지 케이스를 점진적으로 늘려가는 형태)
- 현준) https://tosspayments-dev.oopy.io/share/books/unit-testing ← 오...
- 커버리지 숫자에 집착하지 말고 중요한거 (비즈니스 로직)
- 필수 e2e: FE에서 회원가입, 로그인, 결제 → 잘 안바뀌지만, 정말 중요한 페이지
  - 유틸리티 성격, 훅, 서비스레이어 → 단위 테스트
  - ORM이 만들어주는 기본적인거 → 굳이?
- 코드로 모든 걸 테스트하기에는 한계가 있어요
- 테스트 코드도 코드다 → 유지보수가 용이한 형태로 작성할 것
타입 공유
- 모노레포의 공유타입을 권장합니다 → 기술 스택이 같기 때문에 장점이 극대화 될 수 있다.
- 간편하고 쉬움 / Swagger는 관리 요소가 늘어난다는 단점이 있음
- 최대한 집중할 수 있는 환경을 마련하는게 좋지 않을까?
이슈관리
- 클릭업..? https://clickup.com/ 오 이쁘다
- 깃헙은 구린 것 같아요
코드베이스 이해 문제
- 스크럼 처럼 기술 공유 시간을 가지는 건 어떨까요?
- 비즈니스 로직을 작성하는 경우엔 페어프로그래밍을 추천 → FE와 BE가 보는 관점이 다르다
  - 성능에 대한 관점 → BE는 안정성 FE는 반응성
  - 언어와 기술 스택이 같은 장점을 활용하여, 내비게이팅만 잘 하면 서로의 코드를 잘 작성할 수 있을 것
- 학습 곡선이 가파른 경우에는 안하는게 좋음
  - 서로의 분야 지식에 깊게 의존성이 걸려있는 경우
- 권장 학습법
  - 서로 설명을 번갈아가서 하는 것
  - 먼저 아는 사람이 설명 후 설명 들은 사람이 다시 설명해보기
함께 성장하고 자라는 프로토콜을 맞춰봅시다
- 적어도 같은 분야 코드, 작업을 다른 분야한테 설명할 수 있을 정도로!!!
- 배포 자동화처럼 시스템을 미리 갖춰둬야 나중에 할 일이 몰렸을 때 편합니다
LETS 프레임워크
- 왼쪽: 알려줄 수 있는 것
- 오른쪽: 알고 싶은 것
  - → 수요조사해서 다 설명할 시간을 정하고, 서로 설명해주기
  - 노션 / 구글 스프레드시트