2021년 10월, React에 대해 기반 지식을 다지고자 프로젝트를 시작하였다가 끈기있게 개발하지 못했었다. 그 후 2022년 9월 부트캠프를 마치고 부족한 부분들과 미구현했던 기능들을 추가하기로 마음 먹었다. 이에 타입스크립트와 웹팩 설정을 복습 겸 추가하여 다시 시작해본다. 이후 2022년 12월 doWork를 2차 기획까지 마친 후, 추가 기획을 하면서 고려한 결과 Next.js로 마이그레이션 하기로 결정하였다.
🤔 doWork의 시작, 어떤 걸 구현해 볼까?
프로젝트를 기획시, 어떤 주제를 해야 좋을까 고민이 많았다. 서비스나 기술적으로 생각해보기 위해 끊입없이 흥미를 일으킬 수 있는 주제로 시작하고 싶었기 때문이다. 그러다 문득 자주 쓰는 구글 캘린더에 눈이 갔고 해당 기능에 대해 궁금증을 시작으로 '내가 자주 쓰는 툴들을 구현해보면 좋지 않을까?' 라며 프로젝트를 구상하게 되었다. 이에 일정 관리와 디자인 툴을 웹 서비스로 개발해보기로 하였다.
😎 마이그레이션이란? 하는 이유?
현재의 운영환경에서 좀 더 낫다고 여겨지는 운영 환경으로 옮기는 과정이다. 마이그레이션을 결정한 이유는 SEO최적화가 필요한 부분이 크다. 맨 처음에 doWork를 React로 개발하면서 private한 면이 강해 SEO 최적화가 필요없을 것이라고 생각했다. 그러나 점차 기획을 하면서 doWork의 소개와 사용 설명에 대한 페이지가 필요함을 깨달았다. Next.js로 마이그레이션하는 것이 SEO 최적화도 할 수 있고 SSR과 CSR를 유동적으로 선택하여 개발할 수 있다. 이에 초기 기획들을 다듬어나가며 마이그레이션을 진행하려 한다.
🧷 Next.js의 장점
1. SEO 최적화
2. Webpack의 거의 모든 기능들이 있는 패키지가 있어 설정 및 빌드가 쉬움.
3. 자동 코드 분할로 성능 향상.
4. SSR, CSR 둘 다 구현 가능.
1. 기획 및 디자인 정리
처음 프로젝트를 시작했을 때, 구현해보고 싶던 일정 관리 웹을 만들어보자라는 생각으로 무턱대고 Figma로 UI작업을 해서 개발을 진행했었다. 하지만 점점 기획을 늘려나가다보니 디자인이 난잡해지면서 컴포넌트가 늘어감, 시간도 오래 걸림도 느꼈다. 이에 어느정도 기능 정의와 디자인 타입을 정해놓을 필요가 있다고 느꼈다. 이에 디자인 시스템과 BDD를 적용하여 정리하기로 했다.
color chip과 font style를 먼저 지정을 해놓았고 동글동글하고 부드러운 느낌으로 컨셉을 잡았다. 주로 면이 채워진 아이콘을 많이 이용하려 한다. BDD는 클릭과 키보드 입력에 따라 주로 정의되었고 이메일 회원과 구글 로그인 회원에 따라 달라지는 화면에 따라서 정리하였다. 지금 2차 기획 기능 구현을 마치고 리팩토링과 최적화를 진행하면서 BDD를 확인하며 고쳐나갈 것이다.
🧷 doWork BDD
🧷 doWork Design System
2. 나만의 규칙 만들기
이전의 나( === 팀플을 겪기 전의 나)는 경험을 토대로 개발하는 순간순간 패턴을 만들었다. 하지만 현재 3개의 팀플로 설계, 이슈 관리, 라이브러리 선택 등의 중요성을 느꼈고 이를 프로젝트 중간에라도 적용을 위해 나만의 규칙을 세워 지켜나갈 것이다.
- Folder Structure
- Next.js로 개발을 하다보니 몇 개의 지켜야할 아키텍처가 있었다. 이를 토대로 lib, database 폴더를 추가하여 적용해보고자 한다.
- Git convention
- gitmoji로 commit 명시성 및 의미성 부여
- Project 관리
- Github MileStone & Issue : Github로 git을 관리하고 있는 만큼 현재 이슈들에 대해 한 번에 볼 수 있도록 정리하려 한다.
- BDD 방식으로 문서 작성하여 테스트 : 사용자 행동 방식에 대해 세부적으로 나누어 정의할 필요가 있다.
🧐 기억하자, 해결한 점 & 배운점!
왔썹 프로젝트 전부터 조금씩 개발하면서 작성했던 부분이라 느낀 점의 갭차이가 크고 왔다갔다하는 느낌이 있다. 하지만 내가 개발하면서 기억에 남는 부분, 배운 점들을 열심히 기록하는 저장소이므로 이를 감안하고 작성해본다.
1. 타입 지정
개발하면서 내가 변수를 지정하는 것이니 타입스크립트 적용이 쉬울 것이라고 생각했다. 하지만 이는 오산이였다. 아래 코드는 타입스크립트 적용 후에 나타난 첫 오류이다.
Property 'value' does not exist on type 'EventTarget & Element'.ts(2339)
// input의 onChange const onChange = (e) => { setState(e.target.value) }
이는 eventTarget에 value 프로퍼티가 존재하지 않아서 나는 오류이다. Why???? React에서는 한번도 오류가 나지 않던 코드가 왜 나는 것일까? 그 이유는 어쩌면 내가 당연하게 생각했던 것이 당연한 것이 아니였기 때문이다. 타입스크립트는 값으로 올 수 있는 모든 타입들을 추론하여 오류를 체크한다. 코드의 시점 상으로 event는 당연히 target인 input요소를 가리키고 있겠지만 아직 요소가 html안에 존재하지 않다면 null 타입이 추론되기 때문에 오류가 나타난다. 따라서 이와 같이 개발자가 확신할 수 있는 부분은아래와 같이 타입단언을 통해 지정을 해주어야 한다.
const onChange = (e: ChangeEvent) => {
setState((e.target as HTMLInputElement).value)
}2. 타임라인 구현
하루가 아닌 이틀 이상의 타임라인 구현. 쉽지가 않다. 일단 데이터를 어떻게 가공하고 어떤 식으로 마크업해줘야 하는지 감이 잡히지 않았다. 그래서 다시 처음으로 돌아가 내가 어떻게 문제를 해결하는 것이 좋을지 고민해보았다.
뷰를 그리기 위해 map 메서드를 이용하여 그려야 되니 가공한 데이터 배열이 필요하다. 그런데 이 가공한 데이터를 날짜별로 할 것이냐, 주 단위로 할 것이냐를 결정해야했다. 1 번째 방안의 경우 일자마다 배열을 생성하다 보니 아래 그림처럼 2 번째 주마다 배열을 생성하는 것보다 많은 배열로 데이터를 들고 있어야 한다. top 위치를 조정하기 위해 현재 같은 top값을 가진 일정이 있는지 확인을 해야한다. 이 때 2번째 방안은 해당 주의 배열만 체크를 하면 되지만 1번째 방안은 모든 일짜를 체크해야되는 경우가 생긴다. 따라서 적은 배열을 체크하여 복잡도가 줄 것이라 예상되는 2번째 방안을 선택했습니다.
각 주마다 일정이 갖고 있어야할 데이터는 나의 좋은 레퍼런스인 구글 캘린더를 개발자 코드로 분석했다. 아이템들이 각각 인라인 스타일로 width와 left, top값을 넣어 주고 있었다. 이를 착안하여 start, end값을 통해 left와 width값을 계산하였다. 그 결과 아래 화면처럼 구현할 수 있었다.
일단 top은 인덱스 순서대로 표시된다. 이는 11월 2째주의 9일 타임라인같이 일정들이 겹치는 부분이 없는데도 2번째 순서에 위치해 있게 되었다. 이 문제에 대해서는 현재 다른 기능과 같이 고민하며 해결해나가고 있다. top값에 대한 문제를 일단 해결! 일단이라고 한 이유는 더 좋은 방법이 있나 고민되기 때문이다. 현재 아래처럼 배열을 돌면서 해당 top값을 standard에서 제거 후 standard 첫번째 요소가 top값으로 지정되게 만들었다. 이는 2차 기획이 마무리되면 리팩토링을 거치며 생각해봐야겠다.
const standard = [0, 1, 2, 3, 4];
timeTable
.find((_, i) => i === startArrIdx)
.forEach(t => {
if ((t.start <= start && start <= t.end) || (t.start <= end && end <= t.end))
standard.splice(standard.indexOf(t.top), 1);
});3. Skeleton UI
이전에 실제 웹 서비스를 이용하면서 스켈레톤 UI를 구현해보고 싶다고 생각했다. 미리 레이아웃을 보여주니 로딩이미지보다 훨씬 빠르게 사이트에 접속하는 느낌을 받았었다. 또한 개인적으로 스켈레톤 UI로 사이트가 눈에 익숙해져 실제 로딩된 사이트가 친숙했었다. 이런 점에 개발하면서 적용을 해보고 싶었고 이번 프로젝트에서 적용을 하게 되었다. 실제로 데이터가 로딩되고 있을 때 사용자에게 미리보기와 같은 UI가 스켈레톤 UI이다. 스켈레톤을 사용하면 덜 기다린다는 느낌을 주고 lighthouse 성능을 높일 수 있다고 한다. 무엇보다 가장 큰 이점인 Layout Shift가 있다. 이런 점들을 기억하여 사용자들이 서비스에 머무르고 유연하게 이용할 수 있는 UI를 제공할 것이다.
🤔 앞으로를 위해 더 노력할 점
1. 가독성 좋은 코드를 위해 끊임없이 고민하기
이전에 pair programming을 하면서 가독성이 좋은 클린코드를 지향해야한다고 생각했고 이를 실천하고자 했다. 하지만 이전 프로젝트들에 비해 변수들과 조건들이 많이 엮여 있는 코드를 만나게 되니 클린 코드를 작성하는 것이 정말 어렵구나를 느꼈다. 하나를 건들면 다른 것도 영향을 받는 경우가 있으니 어떤식으로 코드를 구현해야 가독성과 효율성이라는 두마리의 토끼를 다 잡을 수 있을지 고민이 많이 된다. 하지만 이건 고민과 경험을 많이 해봐야 나아질 수 있는 부분이라는 생각도 많이든다. 그러므로 틈틈히 복습을 하며 클린 코드를 지향하며 책을 읽는 듯한 편한 코드를 위해 다시 한 번 힘내보자!
2. 최적화 작업
앞으로 구현하고 싶은 기술들이 더 있기에 점차 doWork의 규모가 커질 것이다. 이렇게 되면 퍼포먼스와 용량에 대해 고민을 많이 해봐야하는 때인 것 같다. 아직 내가 최적화에 대해 알고 있는 것들은 이미지나 SEO, 혹은 memo, useMemo, useCallback을 사용하는 것 뿐이다. 하지만 3차 기획 전에 이런 부분을 적용시키고 틈틈히 어떤 식으로 최적화를 해나가야되는 지를 공부해야겠다.
