기초 프로젝트를 마치며

비교적 짧은 기간 동안 진행된 코드잇 기초 프로젝트를 마쳤다👍

이번 프로젝트는 프로젝트 주제도 정해져있는 것들 중에 선택하는 것이었고, 또 기본적으로 API들도 모두 제공되어 정말 지금까지 공부한 기초적인 내용을 써먹어보는 구성으로 진행했다.

물론 간단한 프로젝트였고, 앞으로 해나갈 공부나 프로젝트들에 비하면 작은 걸음이지만 나름 느낀걸 작성해보고자 한다😁

어떤 프로젝트?

1. 프로젝트의 목적

이번에 우리팀이 진행한 프로젝트는 온라인 롤링페이퍼 서비스를 구현하는 것을 목표로 진행했다.

주제는 한정적이었고, 함께 진행하는 팀은 많았기 때문에 여러 팀과 주제가 겹치지도 했고 이미 선정한 주제를 가지고 진행하는 것이라 한계가 정해져있는 프로젝트라고 볼 수 있었지만, 주어진 시간과 한정된 자원을 이용해서 기본적인 요구사항 이외에도 최대한 여러가지 기능을 구현해보고자 했다.

2. 구현 기능

진행한 프로젝트의 기본적인 요구사항은 접속했을 때 처음 보여질 메인 페이지, 모든 페이지의 위쪽에 보여지는 header, 롤링페이퍼를 받는 수신자들의 카드 목록이 나열된 list 페이지, 카드 클릭 시 보여지는 post/{id} 페이지와 수신자 및 메세지를 생성하는 post, post/message 페이지로 나누어졌다.

원하는 페이지를 각각의 팀원이 맡았고, 그 중 나는 post/{id} 페이지를 담당하게 됐다.

 

내가 맡았던 post/{id} 페이지의 경우, 기본적으로 id별로 주소를 구성하여 페이지를 만들고, 작성한 메세지들을 나열하여 렌더링하는 형식이었다.
또한 카드를 클릭 시 모달창을 이용한 확대 기능과 post/message 페이지로 갈 수 있는 +카드 버튼까지가 기본 요구사항이었다.

꾸준히 리액트를 공부해왔고, 비슷한 개인 미션을 주마다 진행해왔기 때문에 기본적인 요구사항의 구현에 그렇게 큰 부담은 없었다.
때문에 요구사항을 빠르게 마무리하게 된다면, 기본적인 것들을 제외하고도 다른 기능을 더 개발해보고 싶은 마음이 컸던 듯 하다.

그래서 기본 요구사항에는 없던 post/{id} 페이지의 검색 기능과, 모달창 사용 영역의 확대라는 나만의 작업을 추가로 진행해보았다.

3. 기술 스택

우리팀이 사용한 언어는 자바스크립트, 그중에서도 자바스크립트의 프레임워크인 리액트였다.
이는 우리가 쭉 공부하던 것이기도 했지만, 무엇보다 주어진 각각의 페이지의 용도가 다르고, 그에 따라 다양한 컴포넌트 제작 및 분리를 통한 편의성과 기술의 활용을 경험해 보고 싶었던 점도 컸다.

 

또한 기존에 사용하던 CSS가 아닌, 전처리기인 SCSS를 사용하여 조금 더 차별화를 두고자 했다.
SCSS는 기존의 CSS와 유사한 면이 많지만, CSS와 다르게 중괄호를 겹쳐 사용 가능하고, Mixin이나 변수, 우리가 자주 사용하는 조건문이나 반복문 등의 문법도 적용 가능해서 러닝커브가 낮으면서도 새로운 시도를 해보기 알맞다고 판단했다.

 

또한 빌드는 vite로 진행했으며, ESLint와 Prettier같은 포매터 등과 라이브러리들을 활용하여 효율적이면서도 빠르게 작업을 진행할 수 있었다.

 

그리고 협업을 위한 노션과 디스코드, 깃허브 이슈 및 프로젝트 관리 기능을 적극적으로 활용하여 원활한 소통이 진행되도록 하여 프로젝트 진행에 대한 개개인의 부담을 최소화할 수 있었다.

이런 것들이 전부 모여 성공적으로 프로젝트를 마칠 수 있었다고 생각한다.

 

팀 회고

회고는 KPT 작성으로 진행해보고자 한다.

K

• 소통이 즉각적으로 이뤄졌으며 또한 원활했다.
• 서로 모르는 부분에 있어서 다들 적극적으로 나서 도움을 주려고 노력했다.
• 추가적인 아이디어를 적극적으로 도입했다.
• 맡은 일에 적극적으로 임하고 기한을 잘 지키냈다.
• 모르는 부분에 있어서 부끄러워하지 않고 잘 물어보고 얻은 답들을 코드에 녹여냈다.

P

• 팀원 모두 협업이 처음이라 협업을 위한 다양한 규칙들에 적응하는데 시간이 걸렸다,
• 세세한 코드 리뷰가 진행되지는 못했다.
• 커밋 컨벤션이나 폴더 구조, 파일명에 대한 규칙들을 완벽히 적용시키지는 못했다.
• 협업을 위한 전략이나 방법론 등을 제대로 적용해보지 못했다.
• 첫 협업이라 구현과 소통에만 급급해서 전체적으로 제대로 기록하지 못했다.

T

• 앞으로의 협업 시에는 다른 팀원들의 코드에 더 관심을 가지고 적극적으로 리뷰해보고자 한다.
• 자잘한 것까진 아니어도 굵직한 이슈들은 기록해놓는 습관을 들였으면 좋겠다.
• 협업에 조금 더 익숙해질테니 조금 더 다양한 전략을 세워 진행하면 좋을 듯 하다.

 

개인 회고

K

• 정해진 코어 타임과 팀 스크럼에 적극적으로 참여하고 소통했다.
• 협업이니만큼 최대한 팀원에게 폐를 끼치지 않으려 노력했고 맡은 일에 성실히 임했다.
• 기본적인 요구사항들의 구현을 잘 마치고 리팩토링을 최대한 하기 위해 노력했다.

P

• 내 코드 보기에 급급해 다른 팀원들의 코드리뷰 때 제대로 답변해주지 못했다.
• 여러가지 부가적인 기능들에 대한 생각이 많아 정작 필수 요구사항 수행을 위해 구현한 코드의 완성도에는 크게 신경쓰지 못했다.
• 익숙한 코드 로직만 사용하고 새로운 것을 시도해보지 못했다.
• 그날그날 했던 일들의 기록을 제대로 하지 못했다.

T

• 새로운 도전(코드 로직, 전략, 컨벤션 등)을 무서워 하지 않고 계속해서 시도한다면 더욱 성장할 수 있을 듯하다.
• 나와 다른 사람들의 코드를 세세하게 리뷰한다면 나에게도 분명 도움이 된다는 사실을 인지하고 적극적으로 임한다.

 

트러블 슈팅

1. post:{id} 페이지의 추가적인 기능인 검색 로직의 오류

1. 문제
   🚫렌더링된 포스트 카드들의 검색 로직을 구현하고 싶은데, API에 따로 검색이 가능한 쿼리가 제공되지 않아서 로직을 고민하게 되었고 상태값을 하나 더 만들어 조건부 렌더링을 구현했다. 하지만 이 때문에 검색 로직의 편의성을 위한 다양한 시도(값이 사라지면 자동으로 모든 데이터 렌더링하기, 검색 시 값이 없다면 빈 배열 렌더링하기 등)들을 할 때 빈번한 충돌과 비효율적인 렌더링의 수 등의 문제가 있었다.
2. 원인
   ❗searchData라는 배열 상태값을 따로 만들어 searchData.length > 0이란 조건으로 기존 포스트 카드들을 모두 받아오는 상태값이던 messagesData와 searchData 둘 중 하나를 렌더링하는 방식으로 구현했기 때문에, 값이 없으면 무조건 기존 배열을 받아오게 되었다. 또한 검색 시 배열 안에 찾는 값이 존재하지 않을 경우 그냥 기존 전체 배열을 반환하게 되어 좋지 않다고 판단했다. 더불어 이 때문에 값을 입력할 때마다 렌더링이 계속 발생하여 비효율적인 방식이라고 판단하게 되었다.
3. 해결 및 느낀 점
   ✅이를 해결하기 위해서 searchData 상태값을 제거하고, messageData 하나만 렌더링하되, 조건문 로직을 작성한 함수를 따로 만들어 검색창에 값을 입력하고 엔터키를 누를 때마다 filter메서드로 비교하여 값을 넣고, RegEx를 이용하여 띄어쓰기나 대,소문자의 구분도 제거하여 편의성이 강화된 로직을 작성할 수 있었다.

더불어 처음 렌더링한 모든 배열을 저장하는 상태값을 따로 만들어 검색창이 비워질 때마다 messagesData에 넣어줌으로서 검색창에 틀린 값을 입력하는 경우와 값이 없을 경우의 렌더링의 차별화 또한 유도할 수 있었다.

 

 

멘토님의 조언을 통해서도 또다른 로직에 대해 고민할 수 있었다.
멘토님은 내가 해결하면서 사용한 방법과 비슷하게 하나의 상태값으로 messageData를 관리하되, 필터링된 데이터를 조건부로 삽입하여 보여지게 하게끔 하는 방법을 추천해주셨는데, 훨씬 더 깔끔하고 비용이 적은 코드라는 생각이 들었다.

 

이를 통해 항상 조건과 렌더링의 효율적인 방식에 대해 고민해야하고, 이를 어떻게 하면 조금 더 효과적으로 로직을 구성할 수 있는지 생각하는 것이 중요한 과정 중 하나라는 것을 느꼈다.

2. 렌더링한 포스트 카드들의 콘텐츠 요소의 줄바꿈 오류

1. 문제
   🚫기존에 작성해뒀던 포스트 카드의 콘텐츠를 불러오는 로직은 문제가 없다고 생각했는데, 카드의 너비보다 많은 양의 글자가 있는 문장을 작성할 경우에 강제적인 줄바꿈이 일어나게 되어 밑줄의 문장과 겹치는 문제가 발생했다.
2. 원인
   ❗ 기존의 코드는 에디터를 통해 API로 보냈던 문장에 엔터키를 입력할 경우 삽입되는
   이나 /n과 같은 태그 문법 때문에, filter와 split을 통해 이를 변환하여 줄바꿈시키는 로직을 적용하고 있었다.
   오히려 이 때문에 문장이 길어져서 줄바꿈이 일어나면 겹치는 현상이 발생했다.
3. 해결 및 느낀 점
   ✅기존의 코드는 css를 통해 빈 p태그의 높이를 설정하여 줄바꿈을 인위적으로 만드는 형식을 취하고 있었다.
   때문에 이를 변경하기 위해 콘텐츠 요소의 height를 fit-content로 설정하고 태그의 innerText의 길이가 0인 경우에만 높이를 기존에 사용하던 글자의 높이로 설정하도록 로직을 변경하여 문제를 해결할 수 있었다.

로직을 지속적으로 변경하며 항상 수많은 조건이 생길 경우를 대비하며 코드를 작성하고, 완성됐다고 생각하는 로직이라도 항상 테스트를 거쳐야 한다고 생각했다.

프로젝트를 통해 느낀 점

 

1. 나를 조금 더 믿고 부딪혀보자

프로젝트를 시작하기 직전까지도 솔직히 걱정을 꽤 했고, 내가 맡은 역할을 잘 수행할 수 있을지에 대한 걱정이 컸다.
프로젝트를 진행하면서 나름 어렵고 힘든 경우도 있었지만, 내가 걱정했던 만큼 힘든 느낌은 아니었다.
그간 내가 해왔던 공부를 믿고, 나를 조금 더 믿으면서 조금씩 내 실력보다 어려운 과제를 더 많이 맡아간다면, 나중에 이런 걱정없이 충분히 한 사람 몫은 잘 해낼 수 있지 않을까라는 생각이 들었다.

2. 다른 사람의 코드는 참고서다

협업을 하면서 제일 크게 와닿았던 것은 바로 다른 사람들의 코드를 리뷰할 때였다.
물론 다양한 시도를 해보았지만 혼자 작업할 때의 코드는 내 생각에 한정될 수 밖에 없고, 때문에 다양성이 조금은 결여되는 느낌이 있었다.
프로젝트를 진행하며 다른 사람의 코드에서 길을 찾을 때가 꽤 많았고, 덕분에 요구사항의 수행을 수월하게 진행하고 추가적인 기능 구현을 해낼 수 있었지 않았나 싶은 생각이 많이 든다.
물론 핑계지만 이번에 여유롭지 못해 세세하지 못했던 팀원들의 코드를 리뷰하는 것을 다음 프로젝트때 더 잘 해낼 수 있었으면 한다.

3. 뭐든지 실행해보자

위에서도 말했지만 또 말할만큼 절실히 느꼈던 것은, 모험을 하지 않은 것이었다.
물론 익숙한 코드 로직을 사용한다면 그만큼 안정적이고, 나에게 있어서 효율적인 작성이 가능하다.
하지만, 나에게 익숙한 것이 보편적으로 좋은 코드라는 보장이 없고, 이를 위해 여러가지 다양한 시도를 해보았다면 조금 더 나에게 뜻깊은 시간이 되었을 것이라는 아쉬움이 남는다.

 

---

 

프로젝트를 마치고 나름의 회고를 작성해보았다.
역시 회고는 그날그날 하루 마무리로 작성하는게 제일 나은 듯 하다.. 그래도 잘 끝마쳐서 뿌듯😁👍