카테고리 없음

엘리스 2차 프로젝트 2주차 KPT회고

S_sunny 2022. 12. 27. 05:18

엘리스 SW Engineer 트랙 - 2차 프로젝트

2022.12.12 ~ 2022.12.30 (3주)

2주차 회고

 

본격적인 구현작업에 들어갔다

 

2주차에는 본격적으로 구현을 시작했다. 홈화면 구현하는 중 나타나는 자잘한 CSS오류들 때문에 속도가 생각보다 더뎌 나 스스로 많이 답답했는데 어느정도 테일윈드에 익숙해지고 나서는 그나마 진도를 나갈 수 있었다. 다들 각자 담당한 부분 구현에 점점 속도가 붙으면서 매일 스크럼마다 달라진 페이지를 공유하기도 했다. 홈 외에 다른 페이지구현도 하게 되었는데 목데이터로 연결할때는 잘 되던것이 api주소로 연결을 하니 불러와지지 않아서 잠시 애를 먹었다. 다행히 다른 팀원의 도움을 받아 수정을 했고 기본적인 호출 함수와 hook 사용을 잘못하고있었다는 사실을 알게 되었다. 내가 맡은 페이지에 나타나는 수많은 오류들을 보며 아직 더 많이 배워야겠다고 생각했다. 

▶ KEEP(다음 번에도 이어갈 부분)

  1. 프론트 서버간 통신에 대한 활발한 소통(기능에 대한 논의 후 필요한 데이터 시각화하여 요청함)
  2. 폴더구조에 대해 고민하고 공통적으로 사용하는 이미지, 컴포넌트에 대한 관리를 함께 논의함.
  3. 쿠키 관리, 스토리지관리, api요청 등 공통사용 함수를 따로 만들어 관리함.

 

▶ Problem(진행하면서 문제가 되었던 부분)

  1. 기능단위 구현이 아니라 페이지 안에서 부분부분 구현을 하다보니 push 타이밍을 놓침 ( push빈도가 뜸해지면서 다른 팀원이 나의 진행상황을 알 수 없었다) -> 구현할 작은 기능을 정해놓고 집중도있게 작업할 필요성을 느낌 
  2. 해결되지 않는 CSS에 몰두하느라 빠르게 진도를 나가지 못함 -> 우선순위 정해놓고 작업하기
  3. 공통사용함수가 있었지만 적극적으로 사용하지 못함 -> 존재에 대한 사실을 뒤늦게 알게 되어 추후 한번 더 수정하게 됨.
  4. 정렬하기 옵션버튼을 다른페이지에서도 사용할 수 있도록 만들려 했으나 고려해야할 부분이 많아 중단함 -> 공통 컴포넌트화에 대한 이해가 더 필요하다
  5. 페이지네이션 라이브러리를 사용하려 했으나 적용하는 방법을 이해하는데 시간이 오래걸림 -> 페이지네이션 구현에 대한 이해와 라이브러리 속성에 대한 확인이 필요했다.
  6. api 요청에 대한 오류 -> api uri가 계속 바뀌는 이슈도 있었지만 우선 useEffect 사용에 대한 이해와 api 요청 방법 대해 개념 정립이 확실하게 되지 않았던 부분이 컸다.

 

▶ Try(다음 진행에서 새롭게 시도해 볼 부분)

  1. React folder structure 2022 효율적인 작업을 위한 폴더 구조 알아보기
  2. 공통사용함수를 일단 적용시키기만 했는데 코드를 다시 확인하면서 어떻게 구현된것인지 알아둘것
  3. MSW를 사용하여 구현하는 방법도 나의 페이지에 적용시켜보기
  4. 기능구현이 완료된 후 공통컴포넌트 재도전

2주차에 무슨 일들이 있었나?

 

- 생각보다 지체되었던 홈화면 구현

홈화면 구현을 맡고 피그마로 올려두었던 요소들을 하나씩 만들어보았다. 로컬로 앱을 실행해놓고 띄워진 페이지를 보면서 홈화면 구현을 하던 중 홈화면이 아닌 다른 페이지를 맡고 있는 사람들은 루트 경로가 아니니까 주소창에 경로를 직접 입력해서 들어가야 한다는걸 알게되었다. 각자의 페이지로 쉽게 이동할 수 있도록 홈화면에서 네비바 만이라도 라우터를 연결해서 빠르게 push해야 겠다는 생각이 들었다. 마음이 급해졌지만 예상치 못한 부분에서 시간이 지체되면서 마음만큼 빨리 구현해내지 못했다.

  • (남다른 사다리꼴 네비바.. 거기에 테일윈드를 얹은!?)
    직사각형이 아닌 사다리꼴을 CSS로 만들고 모서리를 굴려서 구현하는게 쉽지 않았다. 각도를 조절하고 border 수치를 바꿀때마다 생각과 다르게 바뀌어버리는 모양때문에 고생을 좀 했다. 게다가 그냥 CSS가 아닌 테일윈드 CSS라 구글링으로 찾은 내용을 다시 CSS클래스로 적용해야 했기 때문에 시간을 더 써버렸다.
  • (NavLink의 스타일 속성 깔끔하게 구현하기)
    현재 페이지에 대한 스타일이 들어간 네비바를 위해서 NavLink의 isActive속성을 사용했다. 나의 경우 기본으로 적용되어있던 스타일에 추가를 해야했는데 class 명으로 스타일을 주는 테일윈드를 쓰면서 적용하려니 코드가 너무나 길어졌다. 스타일이 변화되는 부분만 동적으로 추가하는 좀더 깔끔한 방법을 찾다가 결국 템플릿리터럴을 사용한 함수를 만들어서 적용했는데 그렇게 하기까지 시간을 너무 보내버렸다.
  • (드롭다운 메뉴 스타일 욕심)
    드롭다운 메뉴가 슬라이드식으로 나타나는 스타일을 구현하고싶었다. 드롭다운 라이브러리를 적용해보려다가 마음에 드는 스타일이 없어 커스터마이징을 하면서 시간이 길어졌는데 전체적으로 처음 프론트엔트를 맡았던 내 실력에 비해 욕심이 너무 컸다는 생각이 든다. 처음부터 CSS까지 완벽하게 만들어내려고 하기 보다 우선 기능 구현을 하고 세부적인 부분은 나중에 수정을 해나갔어야 했다.

 

- 잊을만하면 발견되는 background이미지 이슈

게임화면같은 웹페이지가 컨셉이였기 때문에 스크롤 없이 한화면에 보여지는 페이지 레이아웃을 구성하기로 했다.

배경이미지도 화면에 딱 맞도록 1920*1080으로 만들고 적용시켰는데 프로젝트를 진행하는 내내 새로 설정해야할 이슈들이 생겨났다. 페이지 확대/축소시 배경이 바둑판식 나열됨, 창 크기 조절 시 비율을 어떻게 설정할지, 어쩔수없이 스크롤이 생기는 페이지에서 배경을 어떻게 줄지 등등.. 때문에 absolute, width:100%, viewport, body margin, scrollbar등 여러 속성들을 수정해보면서 뷰 영역에 대해 알아갈 수 있었다.

 

- 두번째 구현페이지 담당

서버에서 데이버를 받아오고 리스트화 해서 보여주는 페이지를 담당하게 되었다. 홈에서 시간이 너무 지체되었던 경험을 바탕으로 이번에는 기능명세서에 우선순위로 정했던 부분을 위주로 Jira에서 계획을 세우고 진행했다. API가 완성될때까지 목데이터를 만들고 불러오면서 레이아웃을 짰는데 다음번엔 MSW를 사용해보는것도 좋겠다는 생각을 했다.

 

- 데이터 필터링 및 정렬 처리 위치

데이터 필터링과 정렬을 백과 프론트 중 어디에서 할지에 대한 고민이 있었다. 백에서는 당연히 백엔드에서 모두 데이터 가공후 요청에 맞게 보내줄 생각을 하고 있었고 나는 전체 데이터를 받아온 후 프론트에서 처리를 할 생각을 하고 있었다. 이전에 우리 프로젝트의 경우 지역별 필터링을 한 후에 정렬옵션별로 순서를 바꾸고 각 데이터들은 페이지네이션으로 나누어 보여주어야 했다. 프론트와 백 회의 후, 너무 많은 http요청을 줄이기 위해 전체 및 지역별 데이터만 서버에서 필터링하여 보내준 뒤 옵션별 정렬과 페이지네이션은 프론트에서 구현하기로 했다.

 

-게더타운 활용

팀원들이 모두 오프라인으로 자주 만날 수 없는 환경이라 2주차부터는 게더타운을 사용했는데 굉장히 효율이 올라갔다. 슬랙에 이미 있는 음성채팅과 화면공유 기능들과 중복된다고 생각해서 별 차이가 없을 것이라 생각했지만, 시각적으로 같은 공간에 모여있다보니 확실히 같이 작업을 하고 있다는 느낌이 들었다. 특히 도움요청이나 작은 논의거리가 있을때 바로 참여할 수 있어서 좋았다.  

 

- MySQL Workbench 사용

백에서 프론트팀원들에게도 MySQL Workbench 계정을 연결해주면서 사용법을 알려주었다. 1차 플젝때 몽고DB를 쓸 당시 썼던 Compass처럼 MySQL서버에 GUI환경으로 접속할 수 있는 프로그램이다. 프론트에서도 서버에 들어가있는 데이터를 확인할 수 있고 수정, 생성 삭제를 할 수 있어서 구현에 확인에 필요한 데이터를 바로 만들고 정상작동 여부를 체크할 수도 있었다. *DB를 임의로 수정할 경우 데이터가 꼬일수도 있어서 실제로는 조회만 하는 쪽으로 사용했다.