팀 스포츠를 시작한다고 할 때 첫 시작 → 기본 동작 → 트레이닝 → 포지션 역할 → 미니게임 → 실전 게임
혼자가 아니라 그룹이 하는 프로젝트 새롭게 시작하는 기간에서는 그룹이 같은 목표를 위해 달려야 함
그랬을 때 프로젝트를 성공하는 방법? 프로젝트의 완성도에 대한 부담감 낮추기 프로젝트 → 상받아야 하고, 경쟁하는 것이 아님 프로젝트에서 남는 것은 내가 무엇을 고민하고, 어떻게 해결하고, 협업하는 경험의 과정이 남는 것이니 결과를 의식해서 성공하기만 하려고 하지 않기
프로젝트는 상황에서 최선의 선택을 하면 좋은 것임 개발자만 가지고 돌아가는 프로젝트가 아님 스스로 여러 역을 해야 함 팀을 위해서 결정, 싫은 일 하기
학계 vs 업계
이론 vs 실무
일하는 방법은 software engineering을 통해 배울 수 있음
일하는 방법이기 때문에 이론적인게 정립이 되기 전에 회사에서 어떻게 시도해보고 하는 것이 더 먼저 되는 것이 많음. 케이스로 정리가 되는 경우는 이렇게 운영해서 어떻게 됐더라 하는 식의 결과가 나오는 경우가 많음
이론적으로 배울 때 업계는 다른 방식을 시도하고 있을 수 있음. 이 자체가 현업에서 모두가 일하지 않는다는 사실 기억하기. 그래서 꼭 이론을 지켜야 할 필요가 없음
닫힌 생각보다는 열린 생각으로!
프로젝트에서는 우리끼리 결정을 해야 하는 것들이 많음. 의견 대립이 있을 수도 있지만 이게 싸우는게 아니라 우리들의 활동을 하기 위해서 우선적으로 해야 할 것이 무엇인가?에 대해 정리하기
→ 그라운드 룰
어떤 시도가 필요한지 함께 결정하기
태도나 말투, 응답 등으로 신뢰가 쌓이기 전에 깨짐
같은 팀에서 작성한 것 같은 코드가 남아야 함
비슷비슷한 코드가 나와야 함
브랜치 전략, 일감의 관리
공동의 목표 세우기 개인의 책임도 있지만 공동의 책임도 있기 떄문에 역할 분담 잘 하기 프로젝트에서 몰아주는 것이 아니라 서로 다 해보기 모두 프로젝트에 주인의식 가지기
waterfall Process
waterfall로 동작하도록 하는 것이 좋지 않음
단계가 불필요한게 아니라 어떤 단계를 어떻게 거치는지가 중요
폭포수의 문제는 위에서 물이 가득 차야 떨어짐
각 단계가 끊어져 있는 경우가 많음
모든 단계가 이어져 있음을 기억하기
기획/요구사항에서 설계하기
- 기획/요구사항(1주차까지 결정하기)
- 시스템 구성도(아키텍처 뷰) → 전체 구성, 서버 구성, 앱 구조 등
- 전체 큰 그림을 그려서 함께 공유
- 그 뒤에 어떻게 만들지를 설계
- 핵심 기능별 동작 흐름 + API 문서
- 동작 흐름을 가지고 동작
- 상세 기능 목록(백로그)
- 중요
- 세 단계로 나눠짐(에픽, 스토리, 태스크)
- 계속해서 명확화와 구체화 시키고 이를 제품으로 만들기
- 요구사항을 구체적으로 어떻게 구현하고 동작하게 만들지를 만들어가는 과정 0은 할 수 있는 정도만 하고 1,2,3에 투자하기!
코드를 구현하기 전에 건물을 멀리서부터 가까이 보는 것처럼 아키텍처를 볼 수 있음
계획하기
할 일을 정해서 PBI(Product Backlog Items) 만들기 팀원 전체의 목표를 공유하고 멋진 세부적인 계획을 세운다 epic → story → task
제품 백로그: 해야 할 일들을 다 써놓은 것들
스프린트 백로그: 이번주에 할 일들
플래닝(A부분 + B 부분)
큰 덩어리를 쪼개서 story를 나누고(A) 예상시간 추정하기(B)
스프린트 기간을 넘어가게 된다면 다음주로 넘겨야 되겠구나 등을 계획하기 위해 예상 시간을 정해놓기
주어 동사 목적어를 한 문장으로 써 놓은 것이 스토리
사용자가 있고 무엇을 해야 하는지 문장으로 표현
주어 동사 목적어가 있는 문장 형태면 오해하지 않고 이해할 수 있기 때문
요구 사항은 다소 불명확함
누가 무엇을 정확히 쓰기
동작 하나를 위해서 프론트, 백에서 필요한 것들을 모두 쓰기
스토리 예상 시간을 추정하기
작업을 다 할 수 있는지 예측해보기 태스크 단위로 예측하는 이유는 너무 크면 이게 언제 끝날지 예측하기 어려움
- 일감 단위로 작업 시간 예측하기
- time-boxed 일감 두기
- 주어진 시간 내에 할 수 있는가 판단하기
- 스펙을 버릴 것인가 선택하기
- 선택과 집중하기
- 배포를 미룰 것인가 선택하기
- 금요일날 매주 배포
- 팀 개발 속도를 측정할 수 있는가
안해본 일들의 경우 예측하기가 매우 어려움 + 사람마다 예측하는 정도가 모두 다름 → 예측 시간을 정할 때 플래닝 포커 등을 해보기 크거나 작다고 예측하는 사람에게 서로의 의견 나눠보기
어떻게 해야 끝났는지가 명확해야 함
→ 인수 조건 Acceptance Criteria 확인해야 하는 사항들
모든 단계에서 실수를 하기 때문에 확인하는 단계가 꼭 필요한데 이를 의식적으로 해야 함
설계도 확인하기
어떻게 완료할 것인지를 꼭 적어놓기
기능 요구사항들이 있는데 이는 테스트하기 쉽지만, 신뢰, 사용, 효율성 등 비기능 요구사항들이 숨겨져 있음
개발 팀에서 필요한 요구사항을 어떻게 구현할 것인지에 따라서 스토리에 가까운 테스트케이스
우리 팀의 절차와 인프라에서 하는 것들을 종합적으로 고려해서 선택
현황판 만들어서 관리하기
감정적인 상태를 공유하기
프로젝트에 역할을 줬는데 상황공유 안하다가 못할 것 같다는 식으로 하지 않기
배포를 못하는 상태로 개발 X 개발할 수 있는 상태로 꾸준히 개발하기
기능을 조금 만들더라도 계속 배포해서 실제 사용자처럼 사용해보기
회고를 하는 목적 → 팩트 중심으로 쓰는 것도 중요하지만 근데 그게 왜 내가 의도했던 것과 달라졌는지, 방해요소, 실패 요인 등에 대해 팀 관점에서 같이 분석
특정 사람을 비난하는 것이 아니라 다 같이 이후에 더 잘 할 방법을 찾기
애자일 방법론
waterfall처럼 모든 단계가 끊어져 있지 않고 다시 수정해야 하는 일들이 많아짐 대부분 앞 단계에서 실수를 하게 됨
무조건 완벽하게 하는 것보다 만들어 가면서 개선하기
스크럼의 용어와 방식을 무조건 따르는 것이 아니라 공동의 목표를 세워놓고 그것을 잘하기 위해서 공유하고 개선
점진적으로 더 잘하게 만드는 방법
뒤에 가서 고치려고 하면 힘듦
이걸 줄여서 1-2주 안에 할 수 있는 만큼만 하자
맨먼스 미신 사람이 많아질수록 커뮤니케이션 비용은 점점 증가한다 소통해야 하는 일들이 많아지기 떄문 업무 시간 일주일 내내 개발 할 수 없음 회사 가서도 비슷함 빠른 피드백 고리와 점진적 개선 + 자동화 도구 활용
품질을 어느정도로 유지할 지에 대해서 합의가 필요
마일스톤 단위로 협업하면서 성장하기
크롱님 마스터클래스
데이터 통신 → swr http 캐싱 표준 라이브러리의 이름을 swr로 라이브러리의 핵심 → 캐싱 라운드 트립 : 클라이언트와 서버가 주고받는 시간은 방해가 되기 때문에 웹의 최대 단점이 됨 캐시 컨트롤 → 60초 동안은 신선한 상태라서 캐시 사용(max-age:60) 60-120초 사이의 구간(stale-while-revalidate=120) Nginx에서 SWR를 설정하려면 Cache-Control 헤더를 다음과 같이 추가
React Query가 캐시를 구현하는 방법
const {data,isLoading} = useQuery({
queryKey: ['todos'],
queryFn: fetchTodos,
cacheTime:
})
컴포넌트 간 상태 공유와 자동 업데이트
- props로 전달
- context API 활용
- Redux등 외부 상태관리 라이브러리
React Query는 queryKey를 기반으로 데이터를 캐싱 동일한 queryKey를 사용하는 컴포넌트들끼리는 상태를 자동으로 공유하고 최신 상태로 동기화 useQuery는 구독을 의미. 처음 실행할 때는 옵저버 생성하는 개념 서버상태의 핵심 → 캐시 데이터 옵저버는쿼리 객체를 구독하고 쿼리의 상태 변화 감시 컴포넌트는 옵저버를 구독하여 쿼리의 상태 변화를 반영하고 필요할 때 리렌더링 querykey 배열의 두번째 요소는 해당 데이터의 의존성 이 값이 변경되면 queryFn이 다시 실행되어 re-fetching됨 useQuery한 결과를 다시 클라상태(useState)로 보관할 필요 없음
mutation → 데이터를 변경 → invalidate시키기 원래는 데이터를 업데이트하면 응답을 받아오고 post→get요청을 다시 함 새롭게 업데이트 되면 이를 구독하고 있는 컴포넌트들이 모두 리렌더링됨
querykey로 구독해서 리렌더링을 시킬 수 있다는 점이 큰 장점 이미 SWR 방법이 캐시에 특화되어있음 라이브러리가 개념을 가져와서 사용하고 있음 fetching 결과를 캐시할까 브라우저에는 cache api가 따로 있기도 함
비동기 상태 관리
로딩중, 성공, 실패의 상태 관리 useActionState → 폼 처리를 용이하게 하면서 비동기 상태를 쉽게 지원
에러 핸들링
- useState로 에러 상태를 설정
- Error boundary
- React Query의 onError
- Error Boundary + React Query(throwOnError 속성)
자동 리페칭
최신 데이터가 아니면 사용자 경험에 문제가 발생할 수 있으므로 특정 조건에서 자동으로 데이터를 리페칭이 필요할 때마다
리액트에서는 포커스가 변경되거나 네트워크가 재연결될 때마다 데이터를 수동으로 갱신하도록 설정 addEventListener → focus, online에 fetchData 달기 ReactQuery → refetchOnReconnect
lazy Loading
대량의 데이터를 한번에가져오는 것은 성능 저하 페이징 및 무한 스크롤과 같은 UX를 통해 필요한 데이터만 부분적으로 불러오기 리액트에서는 →현재 페이지 상태를 관리하고 페이지가 스크롤이나 페이징에 따라 변경되면 새로운 데이터를 가져와 이전 데이터에 추가 스크롤하는 타이밍에 가져오기 화면에 그 부분이 보이느냐를 IntersectionObserver를 통해 보고 관리 Throttling(스크롤이벤트 제어)
서버 상태 업데이트와 동기화
클라이언트에서 데이터를 추가/삭제 등 수정할 경우 서버와의 동기화 필요 post 요청 후에 다시 get 요청을 보내기 React Query의 경우에는 invalidateQueries를 통해 다시 갱신해서 캐시 업데이트를 할 수 있도록 함
갔다가 오고 ok받고 다시 리스트 요청해서 받고 하는 과정이 오래걸림 → 받는 타이밍에 받는 화면에 업데이트 시켜버리기(낙관적 업데이트)
Prefetching
미리 페이지 로드 시점에 데이터를 가져오고 getData에서 캐시된 데이터를 가져올 수 있으면 바로 가져오기 3번 페이지 보고 있다가 4번 페이지를 미리 로드시켜놓고 페이지를 선택하면 바로 데이터를 가져와서 사용 → UX에 도움. 반응성을 높여줌
리액트의 prefetchQuery 사용
클라이언트 비동기 상태 관리: zustand
경량 상태 관리라이브러리 zustand 컴포넌트 간의 상태를 중앙에서 관리하고 컴포넌트가 필요할 때 상태를 직접 구독 create 함수 내부에서 비동기 호출 데이터 로드 이후 set 메서드를 통해 상태를 업데이트 상태 저장 및 구독 useStore를 호출하여 상태를 구독하고 사용
크롱 & 당글
회의의 내용을 문서화함으로써 서로의 커뮤니케이션이 틀리지 않았는지를 확인 기록에 대해서 서로가 이를 확인하는 습관 가지기 일종의 증거자료로 활용해야 할 필요성이 있음 문서화에 대한 이야기를 해놔야 서로의 생각이 달랐네를 확인할 수 있음