개인 포트폴리오 프로젝트 후기
목차
1. 프로젝트 소개
2. 잘한점과 아쉬운점 후기.
1. 프로젝트 소개
- 포트폴리오 사이트.
배포 : http://portfolio0124.s3-website.ap-northeast-2.amazonaws.com
Git : github.com/Goddemi/portfolio
사용한 기술
기술 : React, Typescript
상태관리 : React-Query
Css : Styled-components
테스트 : Jest, react-testing-library cypress
배포 : Aws-S3
1) 메인페이지
React Router의 Outlet을 이용해 레이아웃을 구성하였다.
좌측의 nav부분, 위의 현재 경로를 나타내는 header를 제외한 나머지 부분에 본문이 들어가고 페이지 이동에 따라 같이 변화할 수 있게 구성했다.
현재의 경로 값이 필요한 컴포넌트가 경로를 알려주는 header밖에 없을 것으로 생각해서 기존에는 location.pathname을 가져오는 로직을 header안에만 구성하였었다.
하지만 메인 페이지 본문에 들어갈 내용의 조건 값을 위해 path값이 필요했고 상위 레이아웃 컴포넌트에서 프롭스로 전달해주는 방식을 선택해야 했다.
주소값이 '/' 기본 메인페이지일 경우 Greeting 컴포넌트가 들어갈 수 있게 지정하였다.
2) About페이지
4개의 덩어리가 비슷한 형식을 가지고 있다고 생각하여 매핑할 수 있게 별도의 컴포넌트를 만들어 두고,
한 덩어리 컴포넌트 안의 한 줄 한 줄 또한 매핑될 수 있게 데이터를 만들어서 구성했다. 정말 짧은 코드로 만들어 낼 수 있었다.
데이터 안의 링크들은 클릭시에 다른 사이트로 이동할 수 있게 <a>코드를 통해 구현했다.
+ 정말 사소하지만... 화면상 보여지고 있는 두번째 My_five_Keywords 파트 UI의 경우 다른 세 가지 덩어리와 다른 배열 형식이다. 아래와 같이 코드에 예외사항을 주어서 조금은 오버해서 배열로 만들어 보았다.
3) Project 페이지
useQuery로 목데이터를 요청하는 로직을 구성했다.
요청시 키 값을 지정하여 동일 키 값 요청에 대하여 효율성을 높였고 데이터가 변화될 것을 대비하여 stale Time을 지정해주었다.
그리고 로딩, error 각 상태별로 UI표기를 통해 핸들링을 하였다.
받아온 데이터들을 매핑하였고 매핑된 각 데이터들은 캐러셀로 구성하여 편리하게 프로젝트별로 내용을 확인할 수 있게 하였다.
프로젝트별 이미지들은 한번 더 캐러셀을 중첩해서 다른 이미지들을 쉽게 확인할 수 있게 하였다. react-slick 라이브러리를 이용했다.
페이지 아래의 인덱스 숫자는 매핑할 때 쓰인 index 값을 이용했다.
컴포넌트 매핑에 미쳐있을 때라 그림 우측의 설명 부분도 각각의 프로젝트별로 코드가 비슷하게 생겼길래,
데이터를 배열로 만들어서 매핑 해버릴까 생각했었다.
그 안의 내용들이 이미 매핑되고 있는 상태였기 때문에 그랬다가는 너무 복잡해 질 것 같아서 참았다.
4) Skills 페이지
페이지가 마운트 될 때 fetch가 일어나도록 useEffect를 사용하였다.
loading시에 데이터를 보내서 렌더링 에러가 나지 않도록 로딩 상태에 대한 UI를 구성하였다.
이미지 데이터를 배열안의 오브젝트값으로 만들어서 매핑하였다.
진짜 한참 매핑에 미쳐있던 때라서 모든 데이터를 배열로 만들어서 매핑하려 했던 것 같다.
이 때 생겼던 문제가 css 지정이었다. 각 스티커 엘리먼트를 받아온 뒤에 개별적으로 style요소를 추가해 줘서 스티커별 위치를 지정 했어야 했는데 그것마저도 줄이고 싶어서 css 값 자체를 오브젝트 데이터에 넣어서 가져왔다.
위의코드를 보면 통신을 통해 가져온 목 데이터 안에 이미지 위치에 대한 css값이 들어 있어서 그것을 style 속성안에다가 넣어주고 있다ㅋㅋㅋㅋ..
잘한점
지금 와서야 당연하고 별건가 싶지만 서도, 당시에는 개인적으로 최초의 클린코드를 신경쓴 코드를 만들었었다.
오픈 소스들을 뒤적거리면서 잘 하는 사람들이 파일 어떻게 구성하고, 구조를 어떻게 짰는지 참고하면서 내 코드들을 다듬어갔다.
과하게 조금은 억지로 매핑한 것도 없지 않지만, 그래도 과하게 해봄으로서 코드 가독성이 가지는 장점에 대해 명확하게 느낄 수 있었다.
조금 시간이 지난 뒤에 후기를 위해 다시 코드를 봤는데도 이해가 쉽다. (내 코드여서 그런가..?)
아쉬운 점
기록하지 못했던 것이다. 정말 후회가 크게 남는다. 별 어려운 기능은 없지만 혼자 힘으로 하는 최초의 개인 프로젝트였고 만드는 중에 정말 수십가지 문제들이 터져 나왔는데 일일이 기록하지 않았었다. 큼지막한 문제들은 따로 정리해서 블로그에 글을 올렸지만, 예를들어 CORS 에러나 비동기 통신으로 인한 렌더링 문제. 대부분의 것들은 그 때 그 때 해결하고 그대로 넘어갔다. 기록이 없으니 어떤 과정을 겪었는지 보는 사람 입장에서 확인이 어려울 것이 사실이다.. 프로젝트를 진행하는 목적에 대해 조금 더 생각해보고 기록 했어야 했다.
후기
이번 개인 프로젝트는 배웠던 것들을 스스로 적용해 보며 내 것으로 만드는 시간이었다. 그 동안 이것 저것 배운 것들은 많은데 머릿속에서 정리가 되지 않은 느낌이었다. 이전의 팀 프로젝트들이 워낙 급박하게 진행되었기도 했고, 스스로 정리할 시간이 부족했기 때문이다.
처음에는 특별한 뭔가를 만들어 보려다가 아이디어에 과하게 시간을 쏟는 나를 발견하고 간단한 포트폴리오를 만들기로 결정했다.
'이렇게 쓰는 거다.' 라고 해서 코드를 그렇게 작성하고 넘어갔는데 이해는 하지 못했던 것들을 차분히 공부하면서 작성할 수 있어서 좋았다. 특히 통신 부분에서 async-await을 사용할 때, 쓰임새를 외우고 복붙해서 사용하곤 했는데 비동기에 대해 공부하면서 조금 더 자신을 가질 수 있게 되었다.
그 동안 가독성을 신경 쓰지 않은 것은 아니나, 시간에 쫓겨서 크게 신경쓰지는 못했었다. 이번에는 코드를 기능별로 나누고, 컴포넌트 별로 제대로 나누어서 나름 만족스럽게 코드들을 분리하여 작성할 수 있어서 좋았다.
이번 프로젝트의 하이라이트는 테스트 코드의 적용이었다. 나름 열심히 공부해서 적용해 보았지만, 제대로 의미를 이해하고 사용하지는 못한 것 같아 아쉽다. 왜 테스트가 필요한지에 대해 이해하는 것이 가장 문제였다. 특히나 이번 프로젝트는 단순한 기능들로만 구성되어 있어서 UI구현과 같은 부분에 있어서 그런 생각이 많이 들었던 것 같다. 그래도 연습해 볼 수 있어서 좋았고, 다음에는 제대로 쓸 수 있을 것 같다. TDD에 대해서 더 공부해 볼 생각이다.