[22.04.12 ~ 22.04.20] 노션 프로젝트 팀 회고

Keep

• 코드와 결과물 공유 : 중간 점검 + 코드 공개

• 중간 중간 모르는 부분 질문 공유 + 해결 방법 같이 해결

• 자료 공유

Problem

• 프로젝트를 진행하면서 막혔던 부분을 초반에 적극적으로 공유하지 못한 점

• 프로젝트 초기에 요구 사항 분석이나 설계 등을 제대로 구상하지 못한 점

• 팀원들과 프로젝트 진행 사항을 공유하지 못해서 사실상 혼자 프로젝트 하는 것과 다른 점이 없었음. 내가 잘하고 있는 건지, 못하고 있는 건지 알 수 없다는 문제

• 멘토님의 도움을 적극적으로 활용 못한 점

Try

• 스크럼 때 만났던 문제 + 해결했던 문제를 공유하자
• 누군가의 도움을 받아 문제 해결을 했다면 혼자만 알지 말고 반드시 해결 방법을 공유하자
• 해결했던 문제를 문서화 하자
• 팀 문제해결 페이지를 만들어 그곳에 문서들을 정리하자

• 다음 프로젝트 + 과제 때에는 과제 진행 기간의 첫날 스크럼 미팅 시간에 설계+기획을 얘기하자

• 팀 내 문제상황 공유 후 해결이 안되는 경우 멘토님에게 도움을 요청해보도록 하자
• 문제 상황 - 시도한 점, 해결이 안되는 점

• 소통을 하자 (slack, 스크럼) 등등
• 확인했으면 반드시 이모지+댓글을 달아 읽은 표시를 하자!
• 호출은 대상이 있을 경우에만 달자

• 스크럼 시간 끝나고 리뷰 시간 을 만들어서 코드와 진행사항 무조건 공유

• 강의를 듣고 문제점이나 더 알아본 것을 공유하자

👤 개인회고

KEEP

권내영

• 프로젝트의 문제 사항들을 공유하고 토론했다

• 기본 기능 및 부차적인 기능을 구현했다.

• 상태관리에 대해 어느정도 배울 수 있었다.

김재호

# 팀 전체 관점

• 승희님이 스크럼 때 계속 화면 또는 코드를 보자고 하시는 부분이 좋았다. 처음에는 의아한(?)부끄러운(?) 느낌이었지만, 언젠가 팀 or 부서인 단체로 활동하며 나만의 코드가 아닌 다른 사람에게 보여야 한다는 것을 생각하니, 중간 중간 검사(?)받는(좋다는 뜻) 느낌도 들었고, 코드 공개에 대한 두려움(?)도 사라지는 듯했다.

• 프로젝트의 요구사항을 이해하고 생각하는 것에 사람마다 조금씩 차이가 있을 텐데 이를 좁히고자 각자 구현한 화면을 보이고 의문점을 갖고 대답하는 것이 좋았다. → 앞 내용과 비슷한 내용

# 개인 관점

• 이벤트 위임 중요하고 거의 모든 부분에 쓰여질 것 같다

• 항상 개발자 도구를 키고 각 요소의 프로퍼티를 이용하여 코드를 작성하기 → 근데 가끔 더러워지는? 경우도 생기는데 그럼 Problem으로도 가야겠지..? 일단 그럴 땐 팀원+멘토님께 여쭤보기

• reflow repaint 관점에서 생각하여 마구 코딩하지 않기 CSS로 가능한 부분은 최대한 CSS로, HTML은 최대한 필요한 것만 작성하고 CSS 가상선택자 이용하기

• 잘 만들어진 서비스의 코드를 계속 분석하며 따라해보기, 의문점 갖기 → Github 코드 보면서 도움이 많이 됨

조계진

• 컴포넌트 단위에 대해 조금 익숙해졌다.

• 추상적이던 SPA라는 개념에 대해 직접적으로 알게 되었고, CSR과 SSR을 비교할 수 있다.

• API, 커스텀 이벤트 listen, dispatch 등 기능을 따로 하는 함수들을 utils 디렉토리에 분리하여 필요한 곳에서 사용하였다.

조승희

• CSS 적인 부분 성장 (가상선택자, 가상요소에대한 이해)

• Contenteditable 에 대한 이해 증가

• key, mouse 이벤트에 대한 이해 증가
• key 이벤트를 이용한 마크다운 편집
• 모달 구현

• 최대한 관심사의 분리 (코드 분리)
• helpers 로 로직들을 분리

PROBLEM

권내영

• css실력이 부족한데 시간 분배를 하지 못했다.

• 상태관리를 효율적으로 하지 못했다

• 폴더 구조, 파일 관리 미흡

• 기록을 하지 못한 점

김재호

# 팀 전체 관점

• 각자 막히는 부분에 대한 공유가 잘 안되어서 우리 팀의 퍼포먼스를 끝까지 끌어올리지 못한 느낌을 받았다. 다시 생각해보면 나 스스로도 말하지 않던 것 같기도 하다.. → 소...통?

• 어떤 팀원에게는 알고 있어서 쉽게 넘어갈 수 있는 것이고, 어떤 팀원에게는 처음 보거나 항상 헤매는 것이어서 오래 걸리는 상황은 어떻게 해결하면 좋을지 고민이다. → 결국 소통?

• 개발하면서 더 좋은 아이디어(예를 들어, 작게는 함수작성에서 구현 방법론)가 있을 지 팀원과 상의하는 것도 좋지만, 멘토님에게도 여쭤보기

# 개인 관점

• 오늘같이 내가 일정을 잘못 이해해서 팀원들에게 불편함을 주었을까 하는 생각에 죄송해진다.

• 요구사항을 제대로 이해했는지, 팀원에게 꼭 물어보기...

• html의 id 값을 이용하는 것보다 data-*를 이용하기

조계진

• 설계가 구체적이지 못하여 진행 중간에 모두 지우고 새로 시작하게 되었고, 3일의 시간을 낭비했다.

// 위험을 슬슬 감지하던 때의 구조(3일차)

.

├── index.html

└── src

├── App.js

├── main.js

├── components

│   ├── SideBar.js

│   ├── DocumentList.js

│   ├── EditableBlock.js

│   └── Editor.js

└── utils

├── api.js

└── storage.js # localStarge 이용

```

```

// 최종 디렉토리 구조

.

├── index.html

├── style.css

└── src

├── App.js               # main에서 App 컴포넌트 생성

├── main.js              # js의 entry

├── components

│   ├── WelcomeBlock.js  # 초기 페이지에 이용할 컴포넌트

│   ├── SideBar.js       # 좌측 사이드바

│   ├── SideBarHeader.js # 사이드바의 헤더

│   ├── DocumentList.js  # 사이드바에 들어가는 Document List

│   ├── EditableBlock.js # 우측 편집기 블록

│   └── Editor.js        # 편집기 블록에 들어가는 편집기 컴포넌트

└── utils

├── router.js

├── titleEditor.js   # 커스텀 이벤트 관리

└── api.js           # fetch

```

• 함수 선언문, 함수 표현식의 스코프에 대한 이해도가 떨어졌다.
• 호이스팅에 대한 개념과 더불어 실행 컨텍스트에 대한 공부가 필요하다.(코어 자바스크립트 꼼꼼하게 읽기)

• 파일 분할 관련 가독성
• 절대적으로 정해진 규칙은 없지만, `component lines of code`라는 키워드로 구글링을 해보면 50 ~ 150 라인이 이상적이라고 한다.현재 `DocumentList.js`에는 200 라인 가까이 적혀있는데, 한눈에 잘 들어오지 않는다. 해당 컴포넌트에서 사용되는 함수가 모두 한 파일에 들어가 있어 가독성이 떨어지므로 컴포넌트별로 아예 디렉토리를 분리하고 그 디렉토리 안에서 함수들을 분리하여 export/import하는 방법이 있을 것 같다.
• 현재 `DocumentList.js`에는 200 라인 가까이 적혀있는데, 한눈에 잘 들어오지 않는다. 해당 컴포넌트에서 사용되는 함수가 모두 한 파일에 들어가 있어 가독성이 떨어지므로 컴포넌트별로 아예 디렉토리를 분리하고 그 디렉토리 안에서 함수들을 분리하여 export/import하는 방법이 있을 것 같다.

• 여전히 문제인 변수명과 파일명 작명
• 화면에 표시하는 함수라 해도 `show~`, `print~`, `paint~` 등 많은 동사들이 활용될 수 있듯이, 그 역할에 맞는 동사를 적절하게 사용하는 것이 중요하다.
• 그 코드가 어떤 일을 하는지는 변수명으로만으로도 파악할 수 있게 명확한 단어를 사용하고, 그 코드가 `왜` 사용되었는지가 필요하다면 주석을 이용하자.
• 좋은 코드와 컨벤션을 자투리 시간에 읽어 보는 습관들 들이자.

• CSS 미숙으로 인한 조촐한 스타일
• JS와 다르게 HTML 구조와 CSS는 개발자 도구에서 모두 확인이 가능하다. 한 웹 사이트를 잡아 놓고 스스로 클론을 해보자.

• 성능에 대한 고려가 전혀 되어있지 않다.
• FE 개발자는 최소한의 데이터로 사용자에게 가장 빠른 최적의 화면을 제공할 의무가 있다.
• 현재는 소규모의 데이터를 fetch하고 5개 남짓 컴포넌트를 조작하지만, 데이터와 컴포넌트 수가 늘어나면 렌더링에 대해 더 민감하게 생각해야 한다.
• Lighthouse, PageSpeed Insights에 대해 알아보고, 불러오는 script 크기에 대한 고민도 해야할 것이다.

조승희

• 코드부터 작성하고보는 주먹구구식 프로젝트 진행

• 수많은 변수사용에서 undefined null ..... 타입스크립트의 필요성을 느낌

• 상태관리에 대한 어려움 , 일관성 부족
• 사이드바 컴포넌트 ↔ Document 컴포넌트 ↔ 모달 컴포넌트 간의 상태 송수신
• CustomEvent로 상태를 변경하기도 하고 , 컴포넌트 setState로 상태를 변경하기도 함

• 컴포넌트 패턴으로 작성했지만, 사실상 재사용한 컴포넌트가 많지 않음

• CSS 부족한 지식 (어제 특강을 통해 보완점을 많이 찾음)

• 서로 의존성이 많은 컴포넌트 구조
• 최대한 독립적인 컴포넌트구조로 개선해야겠음

• 부족한 SPA 기능

TRY

권내영

• 프로젝트를 할 때에 TIL과 별도로 반드시 하루 회고 및 버그 수정, 공부한 내용을 노션에 기록한다.(간략하게라도)

• 할 일을 체크리스트로 표시해서 일정을 분배한다.

• 노션 프로젝트 리팩토링 및 css 수정

김재호

# 팀 전체 관점

• 각자 막히는 부분에 대한 공유가 잘 안되어서 우리 팀의 퍼포먼스를 끝까지 끌어올리지 못한 느낌을 받았다. 다시 생각해보면 나 스스로도 말하지 않던 것 같기도 하다.. → 소...통?
• : 비록 개인 프로젝트이지만 개인의 막히는 부분을 좀 더 빨리 뚫었다면 더 많이 구현하지 않았을까 싶다. 그래서 막히는 부분은 필히 질문해야하지만, 그렇다고 막히는 족족 뚫는 법 아시나요는 X
• 막혀서 찾아봤다의 기준은 사람마다 다르다고 생각하여, 특정한 기준으로 도움을 요청하는 것은 불가능하다고 생각된다.
• 따라서 막혀서 적당히 찾아본 후, 도움을 통해 해결하면 도움을 받은 사람이 해결된 내용을 좀 탐구해서 다음 스크럼때 이야기하면 서로 좋지 않을까 싶은 생각이다.
• 그러는 과정에 도움을 준 사람도 도움을 받은 사람이 탐구해 온 내용을 (복습 + 새로운 지식 습득) 을 할 수 있지 않을까 싶다.

• 어떤 팀원에게는 알고 있어서 쉽게 넘어갈 수 있는 것이고, 어떤 팀원에게는 처음보거나 항상 헤매는 것이어서 오래 걸리는 상황은 어떻게 해결하면 좋을지 고민이다. → 결국 소통?
• : 1번과 동일한 해결방법으로 진행하면 적절하게 해결될 것 같다

• 개발하면서 더 좋은 아이디어(예를 들어, 작게는 함수 작성에서 구현 방법론)가 있을 지 팀원과 상의하는 것도 좋지만, 멘토님에게도 여쭤보기
• : '상대방의 생각도 이해가 되지만, 난 이게 더 적절하다고 생각하는데..' 와 같은 생각에 찝찝함 또는 고집을 부리는 것보다 그래도 현직+경력자이신 멘토님께 물어보면 더 사이다 아닐까?
• (무엇보다 잘 모르겠으면 좀 여쭤보자 재호야. 그래야 견문이 넓어지지 않을까)

# 개인 관점

• 오늘같이 내가 일정을 잘못 이해해서 팀원들에게 불편함을 주었을까 하는 생각에 죄송해진다.
• : 우아한 블로그의 KPT 링크 볼 때 '똑같은 질문을 100번 하면 100번이라도 대답해주겠어요' 부분을 읽고 앞으로 팀원이 이해한 것과 내가 이해한 것을 동기화하는 작업이 필요하다고 느꼈다.
• 그리고 이러한 작업은 더 큰 피해를 막기 위한 작은 피해(?)인 점에서 동감하였지만,,, 나만 질문하면 어떡하지..;;

• 요구사항을 제대로 이해했는지, 팀원에게 꼭 물어보기...
• : 1번과 비슷한 내용으로 비슷하게 해결하기

• html의 id 값을 이용하는 것보다 data-*를 이용하기
• : 새로 배웠으면 이제 써먹으면서 우아하게 코딩해보자
• 태그의 id를 주는 것보다 훨씬 좋은 것 같은데.. 생각해보니 태그의 id, class를 주는 것은 좀더 CSS에 가까운 용도로 쓰는 게 적절할 것 같고, data-*은 JS에서 활용하기 적절할 것 같다

조계진

• 재사용성을 높이고, 유지 보수를 쉽게 하기 위해서, 컴포넌트를 적극 활용하고자 한다.
• 별일을 안 하는 것 같은 SideBarHeader, WelcomeBlock 컴포넌트처럼 ..

• 생성자 함수가 아닌 class를 적용해보고 싶다.

• 머리로만 하려고 하지 말자. 순서도를 정리하거나 그림을 그려보는 등 온/오프라인의 노트를 적극 활용해야 할 것 같다.

조승희

• 다음 프로젝트부터는 칸반보드, 일자별 TODO를 작성 하자

• 타입스크립트로 마이그레이션해서 보완된 프로젝트 경험을 이력서에 추가해보자

• 제대로 배포 해보자

• flex를 이용한 사이드바 CSS 보완

• 컴포넌트간 의존성을 줄여보자 - 의존성 주입(DI)를 공부해보고 적용해보자

• MVC , MVVM 디자인패턴을 공부해보자

• 상태관리를 위해 전역상태를 관리하는 Storage 를 만들어보자

• Histrory API 관련 블로그 글을 작성해보자

• 중요) 💥💥문서화를 잘하자!!! 남는 건 문서

• 배운 것, 문제해결했던 것 블로그에 작성하기