ㅤ프로젝트 소개ㅤ
개발 인원 및 기간
개발 기간 : 2020.08.03 - 2020.08.14
개발 인원 : FrontEnd : [ 이병수, 이지윤, 임현지 ] & BackEnd : [ 김동현, 손수정, 이민호 ]
적용 기술 (FrontEnd)
JavaScript(ES6)
React (CRA) Hooks
Styled Component
함수형 Component
구현 기능 (FrontEnd)
Login / Social Login / Search / Filter
Pagination / Like / Collection / Follow
Modal + Slide / Upload
ㅤ내가 구현한 부분ㅤ
Pages →
| Pages | Description |
|---|---|
| Topic Page | - Pagination & Intersection Observer |
| Following Page | - Authorization 사용자가 following 한 사용자의 사진을 Render |
재사용한 Components →
| Components | Description |
|---|---|
| Card | - 모든 페이지에 재사용 - 좋아요 ( Like ) & 컬렉션 ( Collection Component )을 포함 - 이미지를 업로드한 유저의 정보를 표시하는 UserCard Component 포함 - Intersection Observer 이용하여 BackgroundColor 먼저 load |
| Like | - Card & Modal Component에 재사용 |
| Collection Modal | - Card & Modal Component에 재사용 - 사진을 기존 Collection에 추가 & 삭제 가능 - 새로운 Collection 추가 가능 ( 여러 개의 Collection 사용 ) |
| UserCard | - Card Component에 재사용 - 유저 ID, 이름 및 업로드한 이미지 3개 표시 - 유저 ID 클릭 시 UserPage로 이동 - Following Button ( Click 시 유저의 팔로잉 목록에 추가 ) |
| CardList | - Card Component를 표시, Topic & Modal Component에 재사용 - Scroll Event와 Offset & Limit을 이용한 Pagination 구현 |
ㅤ기억하고 싶은 코드ㅤ
1. 벽돌쌓기
2. Pagination, Intersection Observer
ㅤReviewㅤ 3. 중복되는 fetch 함수 처리하기
✔︎ Scroll Event와 Offset & Limit을 이용한 Pagination
ㅤ2차 프로젝트에서 받은 Review 중 가장 기억에 남는 부분 :
처음 Page mount되었을 때, 그리고 Scroll이 document의 하단에 닿을 때마다 데이터가 추가로 fetch되는데, 배경색상과 이미지 데이터를 따로 불러오기 때문에, 같은 파일에서 유사한 코드를 네 번 쓰게 된다. 이 중복된 로직을 fetch 함수를 따로 생성해 호출하는 방식으로 변경했다. ( 종택님의 Review👍🏻 )
그래서 탄생한 fetchData 함수는 ➡️
api 주소, fetch할 데이터와 함수를 함께 전달받아 배열에 추가하는데,
부모 요소로부터 topic Data를 전달 받았을 때, 
그리고 Scroll이 document의 하단에 닿았을 때 handleScroll 함수가 호출되면 실행된다 
ㅤReviewㅤ 4. useEffect =/= CDM & CDU
처음 Hooks를 배우면서 useEffect를 CDM-CDU에 빗대어 학습했기 때문에, 나도 모르게 이건 CDM 기능, 저건 CDU 기능이라고 늘 구분해서 사용했던 것 같다. 그래서 같은 기능을 하는 fetch 함수임에도 불구하고 아래처럼 두 번 반복해 작성했는데, 정곡을 찌르는 리뷰를 받았다 💦
사실 useEffect는 Component가 Render될 때마다 특정 작업을 수행하도록 설정할 수 있는 Class형 component의 CDM, CDU, CWU를 합친 형태라고 볼 수 있다! 그러니까 어차피 같은 기능을 한다면 따로 나눠서 작성할 필요가 없는 것이다 😇
ㅤ프로젝트 후기ㅤ
시간적 한계 때문에 개선하지 못한 수많은 부족한 코드들이 머리를 떠나지 않는다. 분명 Hooks나 Styled Component 등 새로운 기술을 배우고 적용하고 적응하느라 시간이 걸릴 수 밖에 없었고 그럼에도 불구하고 구현한 기능면에서는 1차에 비해 많이 개선되었다. 그런데 왜 이렇게 내 코드가 마음에 들지 않는 건지 모르겠다. 시간 내에 할 수 있는 만큼 최선을 다 했으니 후회가 크지 않을 줄 알았는데 이건 저렇게 하는 게 나았을 텐데, 하는 미련이 많이 남았다.
특히 2주차까지 집착스럽게 매달렸던 CardList 구현에 아쉬움이 크다. 투자한 시간으로 따지면 거의 하루를 List 구현에만 온전히 쏟아부었는데 결국 내가 원하던 방식을 포기해야 했기 때문이다. 시간도 없었고, 내가 이걸 하느라 시간을 더 허비하면 팀원들과의 협업에 문제가 생길 수도 있었다. 이 부분에서 스트레스도 많이 받았다.
사실 2차를 시작하면서 나는 굉장히 희망적이었다. 일단 1차 프로젝트를 무사히 끝낸 기쁨과 새로운 팀원에 대한 만족감 때문에 뭐든 잘 될 것 같았다. 그런데 나만 잘 하면 되는 팀에서 개발하는 것도 쉽지는 않았다. 잘 풀리지 않는다고 딱히 원망할 누군가도 없고 그냥 내 실력을 탓해야 했다. 거의 모든 페이지에서 재사용할 컴포넌트를 내가 만들었기 때문에 이것저것 손 볼 일도 많았다. 절대적인 시간 투자가 유일한 정답 같았지만 해보니 그것도 아니었다. 내가 새벽 3시까지 개발을 한다고 해도 안 되는 건 안 됐다. 스스로 부족함을 많이 느꼈고 가끔 자괴감에 빠졌다.
그런데 감사하게도, 팀원들이 많이 도와주었다. 특히 백엔드 민호님은 기능 구현 때문에, 프론트엔드 현지님은 컴포넌트 적용 때문에 커뮤니케이션 할 일이 정말 많았다. 2주차에는 새벽까지 다같이 열코딩하며 문제를 해결했던 기억이 정말 선명하다. 그렇게 했는데도 발표 당일, 발표 직전까지 계속해서 코드를 수정했다. 그리고 아직도 내 부족한 실력에 속이 쓰리다.
나는 늘 속도가 쳐진다고 초조해 하지 않고, 다른 코드를 배우려 굉장히 노력하지만, 그게 생각보다 어렵다는 걸 2차 프로젝트에서 새삼 느꼈다. 저 사람은 이만큼이나 하는데 왜 나는 이것도 해결하지 못하지? 의미없이 나를 갉아먹는 버릇이라는 걸 알면서도 자주 그런 생각을 했다. 나는 내면도 코드도 좀 더 단단해질 필요가 있을 것 같다. 다음주부터 기업 협업에 투입된다. 향후 4주간의 프로젝트가 1-2차보다 더욱 성장할 수 있는 기회가 되길 바란다.
