---
tags: project08, 스크럼
---
Week5 Day3
===
## 스크럼
- 이준희
- 끝나고 바로 그냥 정신을 잃어버리고... 잠들었습니다. 5주 프로젝트 동안 가장 오래 잔 듯...
- 이연정
- 늦게 끝나서 이력서 쓰고 잤습니다..!
- 이은솔
- 개발의 진척이 있지는 않지만 이번주는 배우는게 많은 것 같습니다.
- 늦게 끝나서 놀다가 이력서 쓰고 잤다.
- 박은식
- 늦게 끝나서 이력서 쓰고 놀다 잤다.
- 위정훈
- 발표를 어떻게 할까 5분정도 생각하다가 잠들었습니다

---
## 발표주제

 발표 준비는 최대한 여러분들이 5주 동안 어떤 경험을 했는지. 
 기술역량관점에서 도움이 된 부분이 무엇인지를 잘 설명할 수 있는 형태로

> 가제1: 그러면 이 방법 어떤가요? - 그러면을 제시해나가는 개발기
> 5주 동안 개발을 진행하며 집중해서 고민하였던 사항을 말씀드리고자 합니다.

- 키워드; 사용자 편의성? custom hook, 성능/퍼포먼스 향상을 위한 노력, 무엇을 배웠나

- 개발시 고민사항들 / (이전 - 개선사항)
- 소개, 주제 설명 30초 / github, notion 설명, 배포주소 채팅창에 남기기, 실행 결과는 gif
- 차이 전체 (비교하기 / undo / redo)(localstorage) > 성능 개선?
- 체크박스의 역할에 대한 처리방식 > UX
- 있고 없고.. 이렇게 차이가 크다고?!
- Redux를 통한 상태관리 > Redux, custom hook에서 custom hook의 호출 (redux 상태(전역 상태)를 deps로 가진 useEffect 가 있다면 추천 하지 않는다..!) - React

## 발표 흐름...
- 발표 7분 Q&A 8분
- 소개, 주제 설명 30초 (github, notion 설명, 배포주소 채팅창에 남기기, 실행 결과는 gif)
- 팀 소개
- 프로젝트 개요
- 기술 스택 간단히
- 간단히 어떤 주제에 대해 앞으로 말할지
======== 30초
- 고민한 부분 (2분 * 3)

- 히스토리 상태 관리하기. 차이 전체 (비교하기 / undo / redo)(localstorage)
- 우리 프로젝트에서의 히스토리 + undo / redo의 의미 설명 간단히
- undo / redo / 히스토리 어떻게 구현할까?
- 차이를 반영
- 전체 스타일을 반영
- 지도에 스타일을 적용하는 방식에는 '어떤 요소'를 '어떻게' '변경할 것이다'가 필요한데 (시각화가 중요할 것 같아요. 이해를 돕기 위해서)
- 어떤요소: 바뀌어야할 요소, 어떻게: 바뀌어야하는 결과 값, 변경하다: mapbox API 를 통해 앞의 '어떤 요소'를 '어떻게' 바꿀 것이다가 적용
- 편집 상태 데이터 저장 형태의 차이(한 스타일 속성을 바꾸는 편집 |테마나, 가져오기 등의 전체 편집)
- 데이터 처리의 차이 (undo/redo 하나의 스타일만 필요 | 전체 스타일이 필요)
- 특정 히스토리(로그)를 클릭했을때(비교하기 기능) 해당 로그에 대한 스타일 적용을 해주어야합니다. 이때 적용되는 방식이 한 속성의 스타일만 바꿀때는 '시각적 자료 '>'의 연속' 으로 변경된 속성 부분이 적용되어야하고, 테마적용, import, reset등은 전 카테고리의 스타일이 변경되어야한다. 따라서 스타일이 변경될때 저장되어야하는 데이터는 각단계에서 변화되는 부분과 각 단계에서의 전 카테고리의 스타일 속성값들 모두 필요하다.
- 이 두가지 데이터를 가지고 좀 더 효율적인 작업을 진행할 수 있는 방법을 찾고자하였다.
- 따라서 위와 같은 스타일 적용 작업은 API 요청(비용이 높은 맵렌더링)을 필요로 하여 최대한 횟수를 줄일 필요가 있음.
- 차이만을 저장할 경우 연산량이 많아지고, 전체 스타일만을 저장할 경우 API 요청양이 많아진다.

- 그러한 이유로 redux에서 스타일 관련하여 상태를 관리하는 종류를 나눔
- 변경할 당시의 스타일 요소와 해당 스타일 요소에 대한 결과, 변경한 후의 모든 카테고리에 대한 스타일
- undo / redo와 같은 단계별 스타일 적용만으로도 구현가능한 부분에 대하여 변경할 당시의 스타일 요소만 사용. 비교하기와 같이 새로운 스타일의 지도 자체를 만들어내야할때 전체스타일 부분을 사용.
- 위의 설명에 대한 시각자료 필요
- 히스토리 상태 유지?
- 처음에는 상태변경시 무조건적으로 localstorage에 반영. 하지만 local storage io 관련 비용이 큼.
- 따라서 새로고침 또는 창을 닫을 시 localStorage에 history를 저장하도록 변경

- custom hook 관련 시행착오...(?)
- 우리의 디자인 패턴?
- Container-presentational => 각 컴포넌트마다 custom Hook을 두는 방향으로 대체
- Custom Hook을 재사용하고자하는 시도 => custom hook안의 custom hook
- 코드 예시 (useMarkerFeature, useHistoryFeature => 관련 로직을 모아두자..!)
- Redux가 관리하는 전역 상태가 custom hook안의 useEffect deps에 포함되어있는 경우
- 리팩토링 과정에서 useEffect안의 불필요한 사이드 이펙트 중복 처리 발견
- 뭐지...?
- 다른 hook에서 불리는 과정에서 추가적으로 실행
- 만약 custom안에 deps로 redux 상태를 가지고 있는 useEffect를 사용하려면 hook을 좀 더 신경써서 나누어야하는구나...!

- 후보: UI / UX 고민, 현재 색상정보를 사용자가 인식가능하게 할수는 없을까?에 대한 고민

===
- Q&A 예상질문
- 추가적인 UI / UX 개선 사항
-

===
- Q&A 남는 시간 활용
- 데모