프로그래머스 데브코스 - 노션 클로닝 회고

 

🔔 서론

프로그래머스 데브코스 5주차에 첫 번째 개인 프로젝트 노션 클로닝을 진행했다. 그동안 배웠던 JS 지식들을 기반으로 하여 Vanilla Javascript로만 구현하는 과제였는데, 상당히 난이도가 있었고 개발에 관해 많은 생각을 할 수 있는 과제였다.

이번 포스팅은 노션 클로닝 프로젝트를 진행한 것을 KPT 방식으로 회고글을 작성해보려 한다.

🤔 KPT 회고란?

KPT는 Keep Problem Try 세 단계로 나누어 각 단계에 따른 회고를 하는 것이다.

• Keep: 현재 만족한 부분, 계속 이어갔으면 하는 부분
• Problem: 문제점, 개선이 필요하다고 느끼는 부분
• Try: Problem에 대한 해결책

---

🔔 프로젝트 소개

 

📃 요구사항

- 기본 요구사항은 모두 구현하였으나, 보너스 요구사항중 Rich한 에디터 만들기만 구현을 시도했다.

 

📃 컴포넌트 구조

┌─── src
│    ├─── components
│    │    ├─── App.js
│    │    ├─── editor
│    │    │    ├─── DocumentEditPage.js
│    │    │    └─── Editor.js
│    │    ├─── sidebar
│    │    │    ├─── CreateDocumentList.js
│    │    │    ├─── DocumentList.js
│    │    │    ├─── SideNavbar.js
│    │    │    └─── SidebarHeader.js
│    │    └─── linkbutton
│    │         └─── LinkButton.js
│    ├─── api
│    │    └─── api.js
│    ├─── images
│    │    └─── profile.jpg
│    ├─── route
│    │    └─── router.js
│    ├─── style
│    │    └─── style.css
│    └─── main.js
└─── index.html

 

📃 최종 페이지

---

🔔 KPT

[1] Keep

1-1. 컴포넌트 설계의 중요성

처음에는 무작정 기능을 추가해가면서 현재 컴포넌트에 필요가 없다고 느껴지면 새로운 컴포넌트로 분리해보자 라는 생각을 가지고 구현을 했다가, 프로젝트를 엎고 처음부터 다시 시작하기를 세 번 정도 반복했다. 사소하게라도 좋으니 일단은 어떤 컴포넌트가 필요하고, 어떤 기능들로 나누어져 있는지 구조를 먼저 설계를 하고 그에 따라 구현하는 것의 중요성을 배우게 되었다.

 

1-2. 데이터의 흐름 파악

컴포넌트를 설계해보면 자연스럽게 API에서 불러오는 데이터의 흐름이 어떻게 컴포넌트에게 전달되는지 쉽게 파악할 수 있었다. 필요하지 않은 데이터까지 전달하는 것은 아닌지, 적절한 컴포넌트에서 데이터를 불러오고 넘겨주고 있는지 등등.. 물론 완벽하게 숙지했다고는 할 수 없지만, 이 전의 아무 생각 없이 구현했던 과거와는 다르게 이런 이슈들에 대해 고민을 해 보고 시행착오를 겪고 피드백을 통해 성장할 수 있었다는 것에 많은 것을 배웠다.

 

1-3. 낮은 의존성, 높은 응집도

컴포넌트간의 낮은 의존성과 높은 응집도는 이번 노션 프로젝트 뿐만 아니라 그동안 진행 해왔던 모든 JS과제들을 수행하면서 피드백 받고 고민하고 연습해왔던 "데브코스 JS 커리큘럼을 관통하는 주제가 아닐까" 싶을 정도로 중요하다고 여겨지는 개념이다. 사실 이것에 대한 피드백을 듣기 전 까지만해도 전혀 고려해본적이 없기 때문에 데브코스 교육을 듣기 전과 듣고 난 후의 나의 JS 성장은 기하급수적으로 늘지 않았을까 라는 생각이 들정도였다. (아닐 수도 있지만..) 비록 JS 강의가 끝난 지금도 컴포넌트간 의존성이 낮고 응집도가 높은 코드를 자연스럽게 구현하지는 못할지언정 분명히 JS 첫 과제의 상태와 현재의 코드를 비교하면 해당 부분을 고려하여 많은 생각과 시도를 한 흔적이 보이기에 이번 JS 커리큘럼은 나에게 정말 뜻 깊은 시간이었다.

 

[2] Problem

2-1. 특정 Document Editor를 렌더링중인 화면을 새로고침할 시 좌측 사이드 바가 사라지는 문제

2-2. Document 수정 시 좌측 사이드바가 리렌더링 되어 펼쳐져 있던 하위 Document가 모두 숨김 처리되는 문제

2-3. 마크다운이 적용 되어 있던 Document 수정 시 마크다운이 해제되는 문제

2-4. 특정 Document 에디터를 렌더링 하던 중 해당 Document를 삭제할 시 에디터가 그대로 유지되는 문제

2-5. 여전히 부족한 컴포넌트간의 낮은 의존성, 높은 응집도

 

[3] Try

- 해결

특정 Document Editor를 렌더링중인 화면을 새로고침할 시 좌측 사이드 바가 사라지는 문제

• 기존의 Document Editor 페이지에서 새로고침을 하면 sidebar의 render 하는 코드가 존재하지 않아 사이드바가 렌더링되지 않는 문제가 있었다. 이를 해결하기 위해서 홈화면에서만 렌더링하던 사이드바를 항상 렌더링하게 수정해주었다.

 

특정 Document 에디터를 렌더링 하던 중 해당 Document를 삭제할 시 에디터가 그대로 유지되는 문제

• 특정 Document 에디터를 렌더링중인 페이지에서 해당 Document를 삭제할 시 url을 home(/)으로 돌려주어 해결하였다.

 

- 해결 중

Document 수정 시 좌측 사이드바가 리렌더링 되어 펼쳐져 있던 하위 Document가 모두 숨김 처리되는 문제

• 기존의 사이드바는 Document 추가, 삭제, 수정 에대한 행위를 취할 때마다 render함수가 실행되어 펼쳐져 있던 하위 Document가 모두 접힌 초기 상태의 모습으로 돌아가는 이슈가 있었는데 이를 해결하기 위해 부모 Document의 토글값을 로컬 스토리지에 저장하여 새로 고침을 하더라도 사이드바가 초기화 되지 않도록 수정을 진행중이다.

 

- 미해결

마크다운이 적용 되어 있던 Document 수정 시 마크다운이 해제되는 문제

• 아직 문제점이 무엇인지 모르겠다..

 

컴포넌트간의 의존성은 낮추고, 응집도 올리기

• 여전히 컴포넌트의 역할과는 상관없는 데이터 fetching이나 state, function들이 컴포넌트에 남아있고, 이들을 분리해서 의존성은 낮고, 응집도는 높게 수정이 필요하다.

 

---

💊 후기 및 느낀 점

전반적으로 쉽지만은 않았던 프로젝트라 스스로의 실력을 다시 한번 돌아볼 수 있던 프로젝트였던 한편, 데브코스 초반과는 다르게 그동안 받아왔던 피드백들을 어느정도 보완해 가면서 기존의 고쳐야했던 습관들을 조금씩 고친것이 눈에 보여 그래도 미약하게나마 성장은 하고있다는걸 깨닫게해주는 좋은 지표가 되는 시기였다고 생각한다.

이번 프로젝트를 하면서 가장 어려웠고 수 많은 고민을 한 키워드는 '컴포넌트간의 관심사 분리'였다. 사실 컴포넌트간의 관심사 분리를 어떻게 해요? 라고 물어본다면 바로 '어떠어떠한 것인데 무엇이 좋다고 생각한다' 라고 즉각적으로 대답할 자신은 없다. 그렇기 때문에 가장 많이 고민한 영역이 아닌가 싶다. 관심사의 기준이 기능일지, 데이터일지, 사용자 일지... 우리 팀 멘토님의 유행어를 빌리자면 "정답은 없다." 그래서 계속 고민하고, 부딪히고 경험하고 스스로 깨달아야 하기때문에 프로젝트를 하면서 가장 어렵다고 느낀 부분이었다.

더불어 로직에 대한 고민은 사실 크게 문제가 되지 않는다고 생각한다. 로직은 레퍼런스를 해도되는 것이기 때문에, 내가 어떤기능을 구현하지 못하는 것에 대한 고민보다는 어떻게해야 확장성을 좀 더 고려한 코드가 되고, 더 잘 읽히고, 잘 짜여진 코드인가 라는 고민을 하는게 중요하다고 느꼈다.