week1 멘토링 일지
결론
FE : 기술적 우선순위를 정하여 먼저 구현할 기술을 정해야 함. 너무 깊게 파지 않는 한에서 학습 및 구현하기. 야크 털 깎지 않기.
BE : 기술적으로 도전할거리를 찾는 것도 좋지만 우선 FE에서 주는 요구사항 빠르게 구현하는 걸 우선으로 하고, 리팩토링에서 기존에 어떤 패턴이 녹아있는지 살펴보고 추후 새 패턴 시도하자. 다이어그램 그리면서 기능적 요구사항에 따라 패턴을 먼저 짜보자.
To Do
- 환경 설정 협의
- 사용할 언어의 버전
- 사용할 프레임 워크
- 네이밍 규칙
- 특정 문법 사용 방법
- 커밋 룰 정하기
- FE
- 기술 우선순위 정하기
- 코딩 컨벤션 정하기 (CSS 스타일 포함)
- CI / CD 파이프라인 구축 (github action)
- BE :
- 아키텍처 다이어그램 그리기
- 클래스 다이어그램 그리기
- ERD 그리기
- CI / CD 파이프라인 구축 (github action vs 젠킨스+webhook)
- 프레임워크 협의. (Nest.js, typeORM 버전은 최신 stable 사용)
현황 및 계획 공유
강서(대문)구의 현재 팀 프로젝트 상황을 멘토님들께 공유!
공통 질문
코드 작성 계획
브랜지, 머지 룰 공유 후 피드백
백로그 작성 방식
- 개발자도구 성능 기능으로 메모리 확인
FE
반응형 UI / UX 를 깊게 해 본 적이 없다. 반응형 UI를 깊게 해보고 싶은데 다음과 같은 것들이 궁금하다.
- 다양한 종류의 디바이스 화면 크기에 어떤 식으로 접근해야하는지 잘 모르겠다. 협업에서는 미디어 쿼리 중단점을 단순히 pc, tablet, mobile 3개로 나누시나요? 아니면 갤럭시 폴드 같은 정말 특이한 디바이스도 고려하여 중단점을 정하시나요?
- 반응형 UX를 구현하고 싶으나, 단순 미디어쿼리 만으로는 깊이 있는 반응형 UX를 구현할 수 없을 것 같습니다. 반응형 UX를 구현할 때는 적응형 웹을 적용하는 것이 일반적인가요?
현업에서는 웹 접근성을 어느 정도까지 고려하는지 궁금합니다. 웹 접근성에 대한 테스트는 어떤 방식으로 진행되나요?
학습 스프린트에서 배웠던 개념들 중 깊게 학습하여 기능에 적용해볼만한 개념이 무엇이 있을지 궁금합니다.
-
Promise,Observer Pattern,HTTP…etc
랜더링 최적화에 관심이 있습니다. 현업에서는 어떤 방식을 통해 랜더링 최적화를 이루어내는지 궁금합니다.
BE
-
프로젝트를 진행하며 다양한 트러블슈팅 경험을 하고 싶습니다. 이 과정에서 os 또는 node.js에 대한 지식을 활용해보고 싶습니다. 이를 위해 도전해볼만 것이 어떤게 있을까요?
ex) OOM 상황에서 gc 의 작동방식을 고려하여 메모리 최적화
관심 기술:
- 쓰레드
- db 트랜잭션
- 로드 밸런싱
-
디자인 패턴을 배웠지만 프로젝트에 접목해본 경험이 없습니다. 어디에 어떻게 적용해야 할지 잘 파악이 안됩니다. 이번 프로젝트에서 사용을 해보고 싶은데 멘토님들의 디자인 패턴 사용 사례를 여쭤보고 싶습니다.
-
배포(k8s) Application Performance Monitoring (ELK, datadog, pinpoint) WebRTC 부하테스트 및 개선 시간이 있다면 위의 내용도 추가적으로 구현해볼 생각이 있습니다. 우선순위를 어떻게 두는게 좋을까요?
멘토링 시간에 나눈 이야기를 기록해보세요.
- 기능 명세서 피드백
- 기능에 관해 구체적으로 협의가 이루어져야 함 (로그인시 Oauth사용 등)
- 해야할일
- FE
- 사용할 기술 정의
- 디자인
- 명확한 역할 분배 (ex 마크업 작성 따로, 같이)
- 컴포넌트 작성시 충돌 방지
- 일관성 있는 명명법 사용(확장시 용이)
- 질문답변
- FE
- UI/UX는 전혀 다름
- 중단점을 추가로 만드는 것은 안함 다만 새로운 기기일 경우 만드는 것을 고려
- 피시, 스마트폰, 태블릿 세 화면을 지원하게 하는 것은 기간을 고려했을 때 어려울 것 같음 (작은 PC, 큰 PC도 나누는 경우도 있음)
- 반응형 UX로 스와이프 정도만 구현해보는 걸 추천(+ 마우스 관련 이벤트;좌클,우클,호버)
- 웹접근성은 시간여유 있으면 조금 개선하면 좋음( 어떤 방식인지 알고 있으면 됨)
- Promise (await, then 통일, try..catch, then..catch 통일하면 좋음)
- http → 코드 레벨에서 고려할 점은 아님 (nginx 세팅 때 결정할 내용)
- Observer Pattern → 써도 되지만 기간을 못 맞출 염려가 있으므로 나중에 적용을 고려했으면 함.(or 리팩토링 주기를 짧게 가져가서 패턴 적용 해보는 것도 고려)
- 성능최적화 → 초기 렌더링 속도 빠르게, 사이트 전체의 속도를 빠르게 등 여러가지 고려 (각각 방식이 다름)
- 개발자 도구 performance(?)로 성능 측정(?)
- BE
- 개발 환경 세팅을 미리 모든 부분에 대하여 해두기 (i.e, 사용할 언어의 버전, 프레임워크, 코드 컨벤션, 사용할 DB, E2E test / 부하 테스트)
- CSR, SSR 협의 (우리 프로젝트는 React를 사용하므로 CSR 사용할 것임)
- 어떤 기능들까지 할지 고민해 볼 것
- 트러블 슈팅을 위해 프로젝트를 진행하는 것이 아니라 프로젝트를 진행하며 트러블 슈팅을 경험해볼 수 있음
- 대규모 데이터(mock 데이터 포함)을 다뤘을 때 속도에 관한 테스트 필요
- request가 많이 도착해도 메모리 누수 안나게 잘 처리해야함
- nodejs에서 memory 프로파일러를 지원하니 고려해볼 것
- 클래스 다이어그램을 그림으로써 어떤 패턴을 적용할지 생각하거나 리팩토링 주기를 자주 가져서 패턴 적용해보기 하지만 일단 기능에 대한 구현이 완료되어야 함 디자인 패턴을 꼭 사용해야하는 것은 아님
- 현재는 프론트엔드를 위한 백엔드 서버인데 server to server, 크롤링 서버도 한번 생각해보기
- 어떻게 하면 적은 db, 확장성 있는 db 설계 할 수 있는지 고려해보기
- nodejs는 싱글 쓰레드인데 멀티 쓰레드가 어떻게 작동될 수 있는지 면밀하게 공부해볼 것
- 트랜잭션은 안정성과 관련되어있어서 결제와 같은 기능을 구현할 때 사용되지만 이런 기능이 없더라도 한번쯤은 써보는 것이 좋을 수도 있음
- 트랜잭션을 최대한 안쓰려고 노력하는 경우가 있음
- DB성능상의 문제가 아니라 유저의 케이스가 너무 다양하기 때문
- 이를테면 사용자가 무엇을 저장하다가 갑자기 브라우저가 종료된 경우 다시 들어 왔을 때 마지막으로 작업하고 있던 페이지가 유지 됨
- 클로바 노트를 예로 들자면
- 녹음 전, 녹음 중, 녹음 완료, 변환 시작, 변환 중, 변환 완료, 에러 와 같은 상황이 존재함
- 이러한 상태를 정의하여 상태를 기반으로 기획이 이루어져야함
- ORM을 사용할지 결정하기
- 로드 밸런싱은 별로 중요한게 아니긴 한데 L4, L7 layer에서의 로드 밸런싱 차이를 한번 생각해볼 것
- 분배할 때의 로직을 생각해보는 것을 의미
- 이를테면 한번 들어온 애가 또 들어 왔을 때에는 어디로 가는지 생각해보기
- 새로운 기술을 사용하고 싶다면 WebRTC 사용해보는 것도 괜찮음 다만 프론트엔드와 협의 필요
- request를 날려서 어느 부분에서 병목이 생기는지 성능 모니터링 해보는 것도 괜찮음
- CI/CD를 해보는 것이 도움이 많이 될 것 같음
- 6주내에 구현을 다 했을 때엔 리팩토링을 해보기
- TDD를 시도해보는 것이 도움이 될 것 같음
- FE
- FE
이번 주 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 멘토님과 이야기 나눈 후 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.
- 기술적 도전 과제 수립이 되었다.
- 현실성 있는 계획 수립이 되었다.
- 프로젝트 기획과 설계의 뼈대가 나왔다.