회고

진행방식 - KPT (Keep/Problem/Try)

KPT 방식으로 회고를 진행하는 이유

노션 프로젝트 회고

👏🏻 Keep

미현

• 프로젝트 부분
1. 각 컴포넌트들 간의 응집성과 결합력을 고려해서 작성해보려고 했던 것
2. Custom Event를 사용해 볼 수 있었던 것

• 진행 관련 부분
1. 한 가지 이슈에 대해서 의견을 공유할 수 있었던 팀 분위기

규란

• 노션과 비슷한 UI를 구현해보려고 노력했다..

건열

• rich editor를 구현하는 과정에서 시간이 많이 소요됐으나 포기하지 않고 방법을 찾아내서 구현했습니다.

• 강의에서 배운 낙관적 업데이트를 적용해 보았습니다.

승준

• 되도록 state 변화에 따라 화면의 구성이 달라지게 하려고 했었습니다.

• 현재 시점에서 깊게 알 필요가 없는 부분은 따로 모듈화를 진행하면서 추상화하려고 노력했습니다.

• query string, URLSearchParams, Custom Event, window.dispatchEvent, Selection API, range 객체 등 여러 가지를 사용해보려는 시도를 계속 하고 싶습니다.

const queryString = new URLSearchParams(search);

은지

• SCSS를 적용해 스타일 코드를 모듈화하는 경험을 해보았습니다.

• 텍스트 스타일 메뉴 모달을 구현해 리치 에디터를 구현해보았습니다.

👀 Problem

미현

• 프로젝트 마감까지의 구현 분량에 대한 시간 관리

• 프로젝트에 배운 것을 넘어 심화 내용까지 적용해보지 못한 것
• rich content
• 배포
• notion의 다양한 기능들…

규란

• rich editor 구현을 못함..

• 컴포넌트가 이 함수를 가지고있는게 맞나?를 고민하며 함수를 분리하려고 노력했으나 잘 분리된 것 같지는 않다.

• api의 데이터 형태에 기능들이 크게 의존하고 있는 것 같다. (데이터 형식이 바뀌면 다 뜯어 고쳐야할판..)

• 최악의 ux…
• 불필요한 컴포넌트까지 다시 렌더링된다.

• 어느정도 구조 설계를 하고 프로젝트를 진행했지만, 오류가 발생할 때 마다 주먹구구식으로 해결하다보니 해결하는데 시간도 오래걸리고, 내 코드인데도 어떻게 동작하는지 파악하기가 어려웠다..

건열

• rich editor를 만들기 위해 window.getSelection(), range 등 다양한 시도를 했으나 실패했습니다.

• 하나의 컴포넌트의 여러 기능이 들어가 있다 보니 state의 관리가 원활하게 이뤄지지 않고 있는 것 같습니다.

• 마지막 기능으로 외부 페이지 링크 기능을 추가할 때, 시간이 부족하여 버그가 많이 존재하는 것을 파악했습니다. (ex: 이벤트를 모달 컴포넌트에서 설정하다보니 외부 페이지로 이동했다 다시 왔을 때 링크가 걸리지 않는 문제 등)

• document list를 불러올 때 클릭 시 하위 컴포넌트를 렌더링하는 것이 아닌 처음에 전체를 불러와서 리렌더링 시 비효율적..?

승준

• 현재 문서까지의 경로가 어떻게 되는지, 그리고 query string과 URLSearchParams 객체를 써보고 싶다는 욕심에 currentPath라는 것을 구현하였습니다.
• 하지만 작은 기능임에도 불구하고 많은 부분에서 코드가 더 복잡해지기 시작했습니다.
• 그리고 예기치 못한, 그리고 쉽게 고치기 어려울 듯한, 고쳐도 더 큰 문제가 생길 듯한 버그가 생기기도 했습니다.(하위 Document를 보는 상태에서 상위 Document를 지우면 경로가 곧바로 반영되지 않는 등)

• 또 다른 저의 문제점은 Commit 이력을 효율적으로 관리하지 못했었던 점입니다.

• 그리고 ‘일단 구현하다보면 보이겠지’라는 막연한 생각에 막 구현하다보니 어떤 컴포넌트에서는 불필요한 state를 가지고 있기도 했고, 저도 헷갈리기 시작했었습니다.

은지

• 초반의 컴포넌트 설계를 탄탄히 하지 않아 기능 구현하는 데까지 다른 팀원들보다 시간이 좀 걸렸다.

• 초반에 욕심내서 효율적인 state 관리 방법을 고민하다 아무것도 해내지 못한 것이 아쉽다.

• 낙관적 업데이트를 구현하지 못한 점이 아쉽다.

• 불필요한 컴포넌트는 랜더링되지 않도록 개선해나가고 싶다.

👍🏻 Try

미현

• 부족한 시간에 맞추기 위해서 욕심을 내려놓고 완료 기간까지 목표를 선별하기.

• 현재는 삭제된 부분이지만, autosave 당시, 저장이 마무리 되지 않은 시점에서 페이지 이동이 일어날 때, 데이터를 보호하기 위해 임계영역과 Mutual 키를 이용해서 autosave 구현해본 것

• 제목 작성 시, document 목록도 동기화하기 위해 setState를 거쳐서 데이터를 전달했었지만 렌더링 과정에서 제대로 반영되지 않는 무제 발생, custom event를 통해서 해결.

규란

• api의 데이터 형태에 기능들이 크게 의존하고 있는 것 같다. (데이터 형식이 바뀌면 다 뜯어 고쳐야할판..)
• (그냥 드는 생각으로는..) 컴포넌트에서 api를 무조건 호출하지 않고, 중간에 호출해서 일관된 값을 전달하는 전달자를 두는 방법이 좋을 것 같기도 하다. 관련된 자료 찾아봐야지!

• 최악의 ux… 불필요한 컴포넌트까지 다시 렌더링된다.
• 부분적으로 렌더링하는 로직이 필요한 것 같은데.. 외부에서 setState나 render 함수는 되도록 호출하지 않는 편이 좋다는 의견을 얼핏 본 것 같은데.. 여러분의 생각이 궁금하네요..ㅠ0ㅠ..
• 낙관적 업데이트

• 어느정도 구조 설계를 하고 프로젝트를 진행했지만, 오류가 발생할 때 마다 주먹구구식으로 해결하다보니 해결하는데 시간도 오래걸리고, 내 코드인데도 어떻게 동작하는지 파악하기가 어려웠다..
• 각 컴포넌트에서 어떤 역할을 할건지 혹은 하고 있는지 정확하게 파악할 필요가 있다는 것을 깨달아서 정리하고 있다..

건열

• range로 rich editor를 만드는데에 실패하여 getSelection() 으로 현재 키보드 커서가 위치한 곳을 가져와 상위 element에 특정 class name을 추가하는 형식으로 rich editor를 구현하였습니다.

• 컴포넌트 기능 단위로 분할하기

• 이벤트를 모달 컴포넌트에서 설정하는게 아니라 콜백 형식으로 설정하면 되지 않을까..?

승준

• Pub-Sub 패턴을 사용했으면, 이후의 조금 더 큰 프로젝트를 하기에 앞서 좀 더 유지보수를 유연하게 만들 수 있는 방법을 익힐 수 있지 않았을까라고 생각했습니다.

은지

• 시간 내에 과제를 완성하지 못한 점이 아쉽다…

• 선택된 텍스트에 스타일을 적용하는 모달을 띄우는 과정에서 특정 텍스트를 선택할 때만 모달이 띄워지도록 하기 위해 getSelection 객체의 길이를 이용해 해결할 수 있었다.

팀 회고

5주간 팀 활동 간 피드백 내용

😛승준

• 늦게까지 다들 열심히 하고 서로 문제도 공유하고 모르는 부분을 질문하면 잘 얘기해주셔서 좋았습니다.

• 소심한 부분이 있어 결정을 지체하고 있을 때 팀원들이 용기를 많이 북돋아주었습니다.

• 반면 다들 지역이 많이 떨어져 있어서 멘토님과 오프라인 모임을 하지 못했던 것이 많이 아쉬웠습니다.

😎미현

• 늦은 시간까지 디스코드 채널이 불이 꺼지지 않아 같이 공부하는 팀원으로써 자극도 받고, 힘도 되었습니다.

• 온라인이라 어색했을 텐데, 서로 관계를 위해 노력했던 팀이었습니다:)

• 오프라인 때, 모두를 만나보지 못한 게 아쉽습니다. 😢(슬퍼융)

🤠건열

• 프로젝트를 진행할 때 모르는 부분에 있어 서로 서로 편하게 질문할 수 있는 분위기가 조성되어서 좋았습니다.

🥰은지

• 오프라인 모임을 갖지 못한 점이 아쉬웠습니다.

• 서로 모르는 부분을 스크럼 회의 때 의견을 나눌 수 있어 좋았습니다. 😝

🤩규란

• 잊고있던 것들을 누군가는 뒤에서 챙겨주는 가족같은 분위기… 👪