# 4/7

### Scrum
- [x] 리뷰를 보고서 개선하기
- [ ] Component 를 위한 패턴 적용하여 화면 띄우기( 이슈 하나라도 해결 )

### FE 리뷰

- 웹팩 번들링 결과물 디렉터리
- BB: 놓쳤던 부분이었고, .gitignore에 추가하여 앞으로 커밋에 반영되지 않도록 할 예정입니다!

- Source-map
- 파크: BB가 처음보는(?) source-map 관련 코드를 적었을 때 ( eval-cheap..? ) 적용이 안되신다고 하셔서 저는 source-map 으로 적었을 때 동작했기 때문에 source-map 으로 해보시라고 권유드렸었는데 이렇게 다양한 tools 가 있는지 알게되었고, 단순히 안된다고 되는 해결법으로 빠르게 고치기보다 왜 안되는지에 대해서 <a href="https://webpack.js.org/configuration/devtool/#devtool">공식문서</a>를 꼭 참고해야겠다는 생각을 했습니다.
- BB: 미션 요구사항에 source map을 적용해 보라고 되어있어서 검색을 통하여 (일단 되는지 한 번 확인해 보기 위해) `eval-cheap-source-map`을 적용해 보았으나, 원하는 대로 적용이 되지 않았습니다. 관련 공식 문서도 보고 여러 devtool option을 적용해 보아도 잘 되지 않아서 막막한 마음에 사용 경험이 있는 파크에게 물어보았고, 파크의 조언대로 source-map을 적용해보니 잘 되어서 더이상 알아보려 하지 않고 적용만 하고 끝내버렸습니다! 앞으로는 문제를 만나면 문제가 왜 생겼는지, 해결되면 왜 해결된 것인지 확실히 알아보고 학습하도록 해야겠다는 생각을 했습니다.

> 웹팩 번들링 결과물이 들어가는 디렉토리는 gitignore에 추가하지 않은 것은 릴리즈를 대비한 것인가요?

- BB: 놓쳤던 부분이었고, .gitignore에 추가하여 앞으로 커밋에 반영되지 않도록 할 예정입니다!

> package-lock.json은 프로젝트를 진행하는 과정에서 어떤 의미를 지닐까요? (~, ^의 의미)

- commit prefix
- prefix 를 미리 정해두고 시작하니 `내가 지금 보내는 commit 이 어떤 prefix 를 달아야 할 지` 를 참고하는 용도로 사용할 수 있었습니다.
- 반대로 생각해보면 작업을 한 이후 어떤 prefix 를 달 지를 고민한다는게 주객전도가 된 것이라고 생각이 들었습니다.
- issue 내부에서 task 를 나눴듯이, `task 의 commit 단위를 어떻게 쪼갤것인가` 를 개발하기 전에 좀 더 고민해본다면 prefix 가 명확해지고, commit 이 prefix 에 맞추어 더 명확해지지 않을까 생각했습니다.

- Env 타입같은 경우에는 프로젝트를 진행하면서 필요로 해서 임의로 추가했던 타입이었는데, 반대로 기존에 존재하던 많은 prefix 에서 실제로 필요로해서 쓰는 경우가 없을 수도 있겠다는 생각이 들었습니다.
- `prefix 가 많으면 무조건 좋다!` 라고 막연히 생각했었는데, 새로 들어온 개발자가 어떤 prefix 를 사용해야할 지 판단하기 어려울 수도 있겠다는 생각도 하게되었고, 진짜 필요로 하는 커밋 prefix가 무엇일까를 고민해서 정제하는 과정도 필요하겠다는 생각을 했습니다.
- Env 타입을 필요로 해서 추가했듯이, 중간에 필요로 하지않은 prefix 를 한번 정제하는 과정도 프로젝트를 진행하면서 의논하여 결정해야겠다고 생각했습니다.

- eslint
- eslint + prettier 를 사용할 기회가 없었고 코드를 직접 작성해보면서 생기는 문제에 대해서 애자일하게 고쳐나갈 생각으로 따로 lint 의 예외를 정해두고 시작하지 않았습니다.
- 프로젝트를 진행하면서 서로 합의하에 너무 불편하다고 느껴지는 부분을 예외로 지정하는 방식으로 진행하려고 합니다.
- 파크: eslint 는 코드를 작성하는데 지켜야할 규칙을 지정하는 것이고, prettier 는 자잘한 코드 컨벤션을 맞추기위해 사용합니다.
- BB: lint로 문법적 오류를 찾아낼 수 있고 prettier는 단순히 코드 포맷터로서의 역할만 한다고 생각했습니다. eslint는 이번에 처음 사용해 보는 것이라 지식이 부족한 것이 사실입니다. 더 학습하고 배워보아야겠습니다.

- babel.config.json
- BB: 미션의 요구사항을 만족시키기 위해서(`전세계 1%범위에서 사용되는 브라우저에서 동작가능하도록`) 추가하게 되었는데 각 프로퍼티들의 의미까지 생각하면서 작성하지는 못했던 부분이었습니다. 이번 기회에 한 번 더 찾아보고 공부하게 되었고, 앞으로도 프로퍼티 값이 왜 필요한지에 대해서 생각을 해 보아야겠다고 생각했습니다.

- 레포지토리 관리(fork 방식)
- 해당 방식을 선택한 이유: `PR 을 통한 코드관리를 해서 의존적인 작업을 해보자`는 목표로 반장의 레포지토리는 팀을 위한 레포지토리의 느낌으로 사용하려 했습니다.
- 이렇게 쓰기위해선 반장의 레포지토리에 직접 fork 하기보다 organize 같은 팀 레포지토리를 만들어서 쓰는게 해당 목적에 더 부합하겠다는 생각도 들었습니다.
- 각자 코드의 추적을 해야할 필요성을 아직 느끼지 못했지만, 그 필요성이 무엇인지는 명확히 이해를 했기 때문에 작업을 해나가면서 해당 방식의 불편함을 느낀다면 고쳐나갈 수 있도록 계속 고민해보겠습니다.

- PR 템플릿
- 이슈 번호를 제목에 달던 것에서 본문에 다는 것으로