1월 1주차 주간 회고
===
## TGIF
### 많은 후회는 날 천천히 가게 할 뿐이다. 후회하지 말자

###### tags: `20220107` `주간 회고`

아키텍처 및 패턴 점검
- 우리 아키텍처 잘 만들고 있습니까?
- 리뷰 받기
- 플랜을 확인 받자 서로

생산성 관리
- 스프린트 및 이슈 점검 - 달성률

개인화 문서화 계획 점검(시간 갖기)
- 스프린트 단위 개인별 목표에 대한 문서 작성 결과 점검

### 패턴 & 아키텍쳐 점검

#### 김완기 <달성률 30%>
- 홈 뷰 구현
- MVVM 이해 및 바인딩 방법 학습 및 예제 프로젝트를 활용한 적용 진행
- 홈 뷰를 구현하기 위한 계획을 세웠지만, 실제로 계획했던 홈뷰를 제대로 구현하지 못함.
- 첫 뷰부터 MVVM 패턴을 활용해 구성하려고 했으나, MVVM의 동작 방식은 이해를 했지만, 실제로 코드로 작성했을 때 생각보다 잘 적용이 되지 않았다.
- 여러 개발자의 포스팅된 글을 비교해보고, 살펴봤지만, 구현 방법 또한 오픈 소스를 활용해 다양하게 진행할 수 있는 것 같기도 했고, 이 부분에서 어떤 구현 방법을 택해야 하는가에 대한 고민에 대해서 빠른 해결책을 내지 못했다.(결국은 모두 같은 흐름을 가진다는 생각에 이젠 좀더 빠르게 진행할 수 있을 것 같다.)
- 실제 뷰 구현
- 일단 MVVM의 동작 방식에 대해서는 많은 부분 이해를 했다고 생각한다.

저조한 달성률 : 실제 구현 과정에서 각 뷰 별로 모두 MVVM의 구조를 가지고 짜야한다는 생각에 첫번째 뷰부터 MVVM으로 잘 짜자 라는 마인드 때문인 것 같다.

#### 이강호 <달성률 70%>
- #### msa 인증 서버 아키텍처에 대한 고민
- 인증서버를 구성하기 위해 게이트 웨이에 커스텀 필터를 적용했다.
- 스프링 시큐리티를 모든 서버에서 구현하는 것보다 간단한 인증만 거친 토큰을 사용하는 것이 좋겠다는 생각을 했다.
- 이메일 인증과 리프레시 토큰을 위해 redis를 이용하기로 결정했다.
- 많은 예제들과 다른 팀원들의 의견을 종합해서 결정했다.
- 스프링 시큐리티에 대한 개념 정리를 했다.
- 구조상 유저 인증서버에는 시큐리티를 적용할 수 밖에 없었다.
- 나는 인증서버와 유저서버를 같이 쓰고 있었기 때문에 결국 내 정보를 반환하기 위해서 스프링 시큐리티의 사용법을 좀 더 정확하게 알고 있어야 했다. (로그인, 회원가입, 내 정보, 회원 수정, 로그 아웃이 한 서버에 위치함)
- 또한 중요한 것이 게이트웨이에서 커스텀 필터로 걸러질 때와 시큐리티의 반환하는 response형태가 같아야 했기 때문에 관련된 정보를 많이 찾아보았다.
- weflux와 webmvc에서 request, response를 반환하는 이름이 조금 다르고 메소드가 조금 씩 달랐고 webflux는 byte형식을 담아주었다.
- #### 프로젝트 전체에서 사용되는 부분에 대한 고민
- 에러 핸들링에 대한 고민으로 관련된 블로그 글을 통해 나중에 한번에 적용할 계획을 세웠다.
- 에러코드와 response를 통일 시켜야 할 계획을 세웠다.
- 에러코드는 음수로 결정 (양수도 ㄱㅊ지만 혹시나 나중에 status코드와 겹칠 위험이 있다.)
- data를 굳이 내려주지 않아도 괜찮겠다는 생각을 했다. - 만약 내려준다면 err: 0을 고정시켜야 할 것이다.
- entity와 dto 사이의 변환에 대해 고민을 했다.
- 코틀린을 이용해 편리하게 변환하는 방법에 대해서 찾아보았고 생성자를 여러개 만드는 것으로 data class를 정의했다. + fun toEntity라는 메소드를 따로 정의했다.
- 필터에서 받은 토큰을 변환해서 내려줘야 할지 서버들 마다 json을 가지고 있을지에 대해 고민했다. -> 결국 그냥 변환해서 내려주는 것이 좋겠다고 판단해서 userId를 헤더나 바디에 추가해서 내려주기로 했다.

- #### 달성률이 저조한 이유
- 생각보다 많은 시간이 kotlin과 스프링 자체 조사에서 시간이 나갔다. 차라리 좀 공부를 깊게 하고 개념을 확실히 하는 게 오히려 빠르다고 느꼈다.
- msa관련 강의를 일요일에 들어야겠다.

#### 홍석기 <달성률 105%>
> [storybook 배포 주소](https://lemondade-storybook.netlify.app/?path=/story/atoms-button--primary)
- `icon` 컴포넌트 관련
- 문제점) Icon을 `svg` 파일로 저장하여 `storybook` 에 보여주는데, `storybook` 자체적으로 `svg` 파일을 읽는데 있어 오류가 발생.
- `storybook` 은 자체적으로 static file를 읽는 과정에서 `file-loader` 라는 모듈을 사용.
- 하지만 `svg` 를 읽으려면 그 `file-loader` 보다 앞서 `@svgr/webpack` 를 통해서 해당 `svg` 파일을 로드해야함.
- 해당 설정에 있어서 정확한 방법을 몰라 시간이 많이 소요함.
<br />
> 결과적으로는 `.storybook/main.js` 에 `webpackFinal` 함수를 통해 해결하였음.
>
- `image` 컴포넌트
- next/image 관련
- next에서 제공하는 태그인 `next/Image` 를 사용했다.
- 하지만 `domain`을 따로 설정해야하는 요구사항이 있었다.
- `./storybook/preview.js` 파일에 설정을 추가하고,
- `next.config.js` 에 `image`를 불러오는 `domain` 을 추가하였다.

### 금주 타임라인(뭐했는지 적으세요)
#### 김완기
- MVVM Binding 진행
- MVVM 관련 예제 프로젝트 총 7개 정도 진행 해봄
하지만 명확하게 이해했다고 보기는 어려워보임.
- KREAM 구현해야하는 뷰들 figma 활용해서 분석 진행
-

#### 이강호

#### 홍석기
- `Button` 컴포넌트 작성
- `Atom` 중의 기본인 버튼을 생성.
- 간단하지만 `props` 를 고려하며 개발이 이루어져야 한다.

        type ButtonProps = {
            category: ButtonTypes;
            children: React.ReactNode;
            onClick?: React.MouseEventHandler<HTMLButtonElement>;
            disabled?: boolean;
            fullWidth?: boolean;
        };

- 위에 보이는 field들을 가지도록 설계하였다.
- 2중 ternary 연산을 피하고 싶다보니 `fullWidth` 관련한 속성은 따로 하단에 뺄 수 밖에 없는 상황이 아쉬웠다.
- 해당 내용을 기반으로 `storybook` 작성도 진행했다.
- `Icon` 컴포넌트 작성.
- 프로젝트 내부에 사용되는 모든 `icon` 들을 조사했다.
- `svg` 파일을 통해 관리하려는 목표가 있었다.
- 해당 과정에서 발생하는 이슈가 있었다. 위에 기술 하였다.
- 총 15개의 아이콘을 작성했다.
- `ProductImage` 컴포넌트 작성.
- 프로젝트에 사용되는 여러가지 이미지들이 있는데, 그 중 제품 이미지 컴포넌트를 작성했다.
- `next/Image` 를 사용하기로 결정했다.
- 이미지 resizing, 최적화 그리고 브라우저 호환성이 좋다.
- 이미지의 개수에 따라 빌드 타임이 길어지지 않는다.
- 설정해주어야 하는 것들이 많아 설정하는데 시간이 조금 걸렷다.

### 개인별 문서화 점검
#### 김완기
트러블 슈팅 진행 사항

#### 이강호
개발 진행 사항 작성

#### 홍석기
Story book 진행 사항