이번 3부에서는 필자가 프로젝트에서 기억에 남는 코드와 더불어 좋았던 점과 아쉬웠던 점 그리고 간단한 총평으로 마무리 지어보고자 한다.
📝01. 기억에 남는 코드
필자는 주로 프로트 작업을 많이 한 결과 크게 두 가지 코드가 가장 기억에 남는다.
01) 이미지 hover 기능 구현
01.안일함.
첫번째는 바로 이미지 호버 기능이다. 이 기능은 결국 호버가 되면서 그에따라 메인 이미지, 디테일 이미지 1,2가 따라 나오는 식이다.
필자는 처음에는 생각보다 이 기능이 어렵지는 않을 것이라는 안일한 생각을 가졌다. 해당 기능은 두 가지로 접근해서 풀 수 있을 것이라는 생각을 했다.
- 컴포넌트 단에서 onMouseover의 함수를 지정해서 그에 따라 프롭스를 통해 해당 이미지 src url이 계속 바뀌는 형식.
- 컴포넌트에 이미지를 총 3개를 만들어서 겹치게 한 뒤에 css로 호버를 통해 이미지 전환을 하는 것.
둘 중에 어느 것이 더 좋다기보다는 더 필자가 쉽게 구현할 수 있는 방식으로 선택을 하기로 했다. 그래서 일단, 1번보다는 2번을 선택하기로했다.
1번은 이미지가 움직일 때마다 마우스의 위치를 파악하는 조건을 거는 함수를 짜 줘야만 했기에 아직 공부가 덜되어 그건 포기하기로 했다. 그리고 바로 2번 방식으로 접근했다.
02. 접근 방법
01. 랜더링 부분 변경
먼저, 맵을 돌리는 랜더링 부분에 프롭스를 다음과 같이 src만 있던 것에서 넣어줬다. 새롭게 카드 컴포넌트 2번처럼 src1, src2, src3이라는 프롭스를 줬다.
그리고는 일단, 화면의 레이아웃을 맞춰주기 위해서 css로 조정을 계속 하면서 일단 겹치는 데까지는 성공했다.
하지만, 이제부터 시작이었다. 문제는 호버였다. 호버를 적용한 것 같은데 계속 제대로 작동하지 않는 듯 보였다. 그래서 몇 시간을 고민했지만, 결국 안 풀렸고, 이를 팀원들에게 고민을 털어놓자, 민기님이 바로 이 부분을 1시간 정도 후에 구현했다고 화면 공유로 원리를 보여주셨다.
03. 다름을 발견하다.
그가 설명한 부분을 보면서 그때 딱 직감했다.
아! 내가 구조가 잘 못 되었구나...!
1) 컴포넌트의 구조적인 문제.
먼저, 컴포넌트의 구조적인 문제가 있었다. 필자는 이미지 3개를 각각 하나의 div로 묶었었다.
그런데 민기님은 그걸 아래 그림처럼 묶지 않았다.
민기님의 방식
이유를 확인해 보니, 이해가 갔다. 저렇게 컨테이너로 묶으면서 구분을 해줘야만 했다. 이 이미지 컨테이너들이 각각 영역을 3등분으로 가지면서 호버 영역을 정해줘서 그에 따라 호버되는 것들이 변경되는 것이다.
거기서 또 머리를 한 대 얻어 맞았고, 구조를 바꾸고 호버를 시도했다. 하지만 한 시간쯤 지났을 까 여전히 되지 않았고, 다시 팀원들에게 문의를 했다.
2) z-index의 문제
그러자 같이 풀어보자고 해서 화면 공유를 시작했다.
일단, 호버는 먹히지만, 이미지 변경이 잘 되지 않는 것. 호버에 따라 다른 이미지들이 보여야만 하는데... 그렇지 못 했다.
문제를 살펴보다가 때 마침. z-index가 동일해서 그런게 아닐까라는 의문이 들었다.
아래 그림처럼 호버 시에 각 이미지의 z-index가 9999로 동일했다.
그래서 아래와 같이 z-index의 값을 변경했다.
결국 호버 시에 역순으로 하나 씩 z-index의 값을 줄여가는 식으로 해야만 해당 컨테이너 영역에서 호버 시에 다른 이미지에 영향을 받지 않을 수 있었다.
결론적으로 필자 역시 <Z-index 와 포지션의 관계성?>포스팅을 한 주제라서 z-index에 대해서 잘 안다고 생각했지만, 오산이었다.
03. 정리
이렇게 우여곡절 끝에 탄생하며 모두 함께 만든 코드라서 의미가 있고, 필자의 다 안다고 생각하는 안일함이 얼마나 잘못된 생각인 지를 보여주는 좋은 경험이었다.
02) 제품 컬러에 따른 제품 리스트 메인 상품 이미지 변경 기능.
01. 안일함
이 문제 역시 너무 안일하게 생각한 것이 화근이었다. 필자는 단순히 그냥 온 클릭하면 바뀌는 것이 가능할 줄 알았고, 또 미숙하게도 프롭스가 자식 컴포넌트 간에 잘 전달이 될 줄 알았다. 하지만 결론적으로 그렇지 못 했고, 문제에 직면하고 만다.
02. 문제의 인식.
01) 단순한 접근론
필자는 아래와 같이 그냥 src를 detail에 인덱스만 주면 바로 구현된다고 생각했다.
그런데,
그렇게 쉽게 될리가 당연히 없었다. 결국 하다 하다 안 되어서 옆에 있던 태영님께 조언을 구했다. 그러자 그는 보자마자 이건 당연히 안 된다고 단언했다.
그의 단언에
아! 내가 또 뭔가를 잘못 알 고 있구나...
라는 생각이 들었고. 그래서 필자는 다시 곰곰이 생각해 봤다. 다시 생각해 보니 안 되는 것이 당연했다. 인덱스가 맵으로 돌면 결국 0과1만 들어가는 것이 아니기에, 우리가 현재 넣은 데이터만으로는 불가한 계산이었다. 혹여 데이터가 무한대로 있다면 모를까 말이다...
02. 문제의 해결
01) 새로운 스테이트
그래서 결국 해당 서브 이미지를 클릭할 때 함수로 뭔가를 조절해 줘야만 한다고 생각이 들었다. 그 이전에 부모 컴포넌트를 통해 자식에게 전달할 수 있는 방법을 생각해야 했다. 그게 바로 아래와 같은 스테이트 할당이었다.
넘버로 설정을 한 뒤에, 뒤에서 후술하겠지만, 저렇게 초기 값으로 배열을 넣어줬다.
03) 온클릭 함수 생성
그리고 다시 서브 이미지가 있는 컴포넌트 카드 2번에서 온클릭 시 에 발생할 조건 함수를 넣어줬다.
이 함수를 하나씩 뜯어보자면, 초기값은 넘버를 그대로 복사해서 받는 새로운 arr 배열을 만든다. 이후에 arr[index]의 값을 0과 1로 설정해서 detail 뒤에 붙을 값을 설정해 준다. 그것을 다시 함수인 셋 넘버에 넣어주면, 이제 끝난다.
그런데 여기서 아까 의문이 안 풀렸다. 유즈 스테이트의 초기값! 그건 왜 다 죄다 영으로 해 놓고 저렇게 한 걸까? 그건 사실 영이 되든 뭐가 되든 상관은 없다. 그 보다 갯수가 중요하다. 즉, 데이터가 들어온 만큼 해당 갯수가 필요하다.
저기 src1의 구조를 다시 보자.
src1={product.detail[number[index]].image[0].imageUrl} 이렇게 되어있다. 즉, detail의 영번째와 1번째가 들어와야 하는데, 그게 상품별로 전부 같다면 구별이 안 가지 않겠는가? 즉, 그래서 넘버가 인덱스가 돌면서 detail[0[0~20....]] 이런식으로 맵이 돈다고 보면된다. 그래서 구분을 해주기 위한 용도다.
이렇게 하면 리스트에서 해당 상품의 색상 서브 이미지를 클릭하면 그게 바로 메인에서 보여진다.
03. 또 다시 문제의 발생.
구현이 잘되고 있던 차에, 갑자기 리스트 페이지에 또 뭔가 문제가 생겼다. 팀원들의 데이터가 추가되고 난 뒤에 벌어진 일이라...
필자는 직감했다. 이건 백프로 맵이 안도는 문제라고...
그래서 혹시 싶어, 아래 그림처럼 바꿔 봤다.
바로 유즈 스테이트의 초기값 변경. 그랬더니 다시 정상 작동을 하더라... 결국 아까 설명했듯이 저게 갯수가 적어지면 또 문제가 발생한다. 그래서 추후에는 저걸 변수화 시켜서 갯수에 맞게 자동화 시킬 수 있는 방법도 고민해 봐야겠다.
04. 느낀점.
결론적으로 이번 기능 역시 필자의 안일함에서 온 문제를 해결하는 과정에서 끝나고 나서도 기억에 남는 코드였다. 또한, 이후에 발생한 문제를 통해 추가적인 더 좋은 코드를 짜기 위한 생각도 할 수 있었다.
물론 이 2가지 코드 외에도 더 기억에 남는 것들도 많다. 그 부분은 현재 필자의 블로그에서 추가 확인이 되니 시간되시면 확인해 보시길 바란다 ^^
05. Update
당시에는 구현에 급급해서 코드를 리펙토링할 시간이 거의 없었다. 그러나 현재 리펙토링을 하면서 얼마나 코드를 지저분하게 + 비효율적으로 적었는 지, 알 수 있었다. 그래서 이 부분은 따로 리펙토링 포스팅을 참고해 주면 좋겠다.
2. 👍 😂 프로젝트 상에서 잘한 점& 아쉬운 점.
👍01. 잘한 점.
사실 프로젝트를 진행하면서 첫 프로젝트이다보니 잘한 점보다는 아쉬운 점이 더 큰 것이 사실이다. 하지만, 그럼에도 불구하고 나 자신과 팀원들의 칭찬도 일정 정도 필요하기에... 적어보겠다.
👨👩👨👨01) 매일 정해진 시간 꾸준한 미팅.
사실 프로젝트를 하기 전에는 미팅에 대해서 큰 생각이 없었다. 하지만, 프로젝트를 진행하면서 논의를 하지 않으면 안되는 상황이 많았다. 그래서 우리 팀은 매일 아침 10시에 줌을 통해 미팅을 가졌다. 이를 통해 기존에 계획된 사항의 수행 여부의 점검은 물론 개개인의 어려움까지 잘 들을 수 있었다. 또한, 향후 일정 계획에 대해서도 잘 계획을 할 수 있었다. 필자 개인적으로도 항상 주도적으로 미팅 습관을 팀원들이 가질 수 있도록 계속 유도했던 것 같아 이 부분에 대한 노력대비 결과물이 잘 나온 것 같아 뿌듯하다.
⏰02) 마감기한의 준수
사실 어떤 일이든 마찬가지이겠지만, 개발자에게는 마감 기한의 준수가 그 어떤것보다도 중요하다고 들었다. 그 이유는 개발이 진행되어야만, 이후 마케팅, 홍보등의 추가적인 사업 계획이 수립되고 진행되기 때문이다. 따라서 이번 프로젝트 중에 우리 팀은 마감 기한까지 꾸준히 계속 잘 해온 덕분에 큰 이슈 없이 잘 마무리 된 것 같다.
🫂 03) 챙김의 미덕
일전에도 말한 것처럼 필자는 팀원들에 비해 아직 코딩을 공부한 시간이나 경험적인 측면에서 부족한 것들이 많다. 그렇지만, 그럼에도 불구하고 팀원들이 함께 할 수 있도록 챙김의 미덕을 최대한 발휘했다고 생각한다. 혹여나 팀원들이 조금 지치거나 아니면 문제가 있는 경우에 최대한 같이 확인하고, 풀어보는 쪽으로 많이 유도를 한 것 같다. 그래서 그런지 우리 팀은 융화가 잘 된 것 같아 이번 프로젝트도 잘 마무리 되었다.
😂02. 아쉬운 점.
01) 🚂 너무 달리기만 하려고 한 급행열차.
사실 이 부분이 우리 팀원들 모두가 공감하는 부분이다. 물론 앞서 말한 일정관리나 그런 부분에서는 좋은 장점이었다. 하지만, 다시 생각해 보니 양날의 검이었다. 왜냐면 우리는 프로젝트 중간에 한 번의 코드 리뷰도 없이 그냥 바로 승인하고 머지하고 풀받고 이런 식으로 프로젝트의 속도에만 치중했다. 그러다 보니, 후술하겠지만, 서로의 코드를 알 길이 없었다. 그래서 다음 프로젝트에서는 꼭 코드 리뷰를 하는 시간을 가질 계획이다.
02) 😷 잘 된 것 같지만 단절된 소통
두 번째 역시 첫 번째와 이어지는 이야기다. 결국 잘되는 것 같아 보이는 소통 속에서도 문제점이 있기 마련이듯. 우리 팀은 리스트 페이지인 필자와 태영님, 그리고 디테일 페이지인 하늘, 민기님 이렇게 프론트와 백간의 소통은 잘 되었다. 하지만, 각 페이지 간의 소통은 전혀 되지 않았다. 그러다보니 서로 나중에 해당 페이지 코드 담당자가 아니라면 코드를 알기 힘들었고, 수정하는 것 역시 힘든 작업이 되었다. 그래서 만약 처음부터 너무 분업만 하지말고 함께 했다면 어땠을 까 하는 아쉬움이 크다.
03) 🤓기능에 대한 욕심
이건 개인적인 욕심 부분이다. 원래 필자는 리스트 페이지에 무한스크롤을 추가하려고 했다. 하지만, 적용하지 못했다. 이유는 처음보는 기능인데 잘 알지도 못하면서 무작정 덤벼드는 무모함 때문이었다. 유아이를 제대로 완성하지도 않은 채, 무한스크롤만 거의 한 3일을 붙잡고 있었다. 그래서 만약 그 시간을 다른 기능을 먼저 구현하는데 썼다면, 오히려 심적 여유를 가지고 구현할 수 있었지 않을까 싶다. 다음 프로젝트때에도 분명 이런 상황이 벌어질 것이다. 그때는 적용할 수 있는 부분부터 먼저 접근해서 완료하고, 남은 시간에 연습을 하면서 도전해 봐야겠다.
🔚03.총평
협업이라는 것이 내가 생각하던 것과는 많이 다르구나라는 것을 새삼 다시 느낄 수 있었던 좋은 경험이었다. 비록 아직 부족한 부분이 많지만, 필자의 생각에는 기술적인 배움도 물론 있었지만, 그 보다 중요한 사람들과의 관계 속에서 코딩 이전에 생각해야 할 부분에 대해 더 많이 배운 시간이었다. 앞으로 남은 프로젝트. 그리고 더 나아가 현업에 뛰어들어서도 이때 느끼고 배운 것들을 꼭 가슴 깊이 새겨야겠다. 끝으로 여태 도움을 계속 준 우리 위얼네버댓 팀원들과 멘토분들께 감사를 표한다.
아마 다음 프로젝트에는 더 많이 성장한 미래의 필자를 생각하며 오늘은 이만 키보드에서 손을 떼겠다~ 그럼 이만~ ☺️
