[개발바닥] 중간발표 회고

minkyung·2022년 7월 17일
7

중간발표 멘토링

뭐했다고 벌써 3주가 지난거야? 라는 기분으로만 맞이한 중간발표 …

개발바닥

우리 프로젝트는 사이드 프로젝트를 기획한 사람들이 같이 할 팀원들을 구하는 사이트! 가 주제인데 1차 MVP로는 회원가입, 로그인, 게시글 CRUD, 댓글 CRUD, 북마크 정도 까지만 정해둬서 진행하다보니까 팀 내에서도 “어? 근데 이 기능이 없으면 되나?” 싶은 지점들을 많이 마주쳤다.

그 중 하나가 “어? 근데 프로젝트에 참여하려면 신청만 하면되나? 기획자의 의사는?” 이었고 2차 MVP에 신청-수락 로직을 급하게 집어넣었다.

그게 내 담당이었고, 서버에서도 빠르게 그 부분을 끝내줘서 나도 중간발표에는 저 부분을 너무너무 보여줘야겠다 싶어서 될 때 까지 안 잤다 …

결국에는 내가 해냄 ~ 🤟🥹

그리고 우리 마이페이지에서는 1) 북마크, 2) 참여한 프로젝트 (신청해서 수락받은 프로젝트), 3) 신청한 프로젝트, 4) 내가 쓴 프로젝트로 나뉘어져있는데 북마크 상태를 각각 다르게 관리하고 있다.

뭐가 다르냐면 …

1) 북마크에서는 어차피 서버에서 현재 유저가 북마크한 게시글을 보내주고 있기 때문에 response body에 ‘bookmarkStatus’값이 없다. 프론트 쪽에서 상태값 = boolean으로 관리해야 함.

2) 참여한 프로젝트, 신청한 프로젝트 에서는 response body에 ‘bookmarkStatus’ 값을 주고 있다.

3) 내가 쓴 프로젝트는 내가 북마크 할 수 없다.

4) 마이페이지에서 게시글 리스트로 보고 있을 때도 나의 북마크 여부를 보여주고싶고, 북마크 / 북마크 해제도 시켜주고싶다! (북마크 아이콘이 있으면 당연히 되어야하니까!)

각각 상태에 따라 보여주는 것, 북마크 / 북마크 해제 시키는 것은 혼자서 어떻게든 했는데 ‘내 북마크’ 탭에서는 리액트 state로 관리하고 있으니까 누르자마자 bookmark Fill icon, 혹은 empty icon으로 바뀌는데 ‘참여한 프로젝트’, ‘신청한 프로젝트’에서는 또 서버에서 값을 가져와야 (새로고침해야) 아이콘이 바뀌는 것이었다.

거의 우는 목소리로 이런 점이 안됩니다 ~~ 했더니

팀원분이 리액트 쿼리 무효화를 쓰면 된다고 알려주셨다.

리액트 쿼리 무효화

보니까 GET요청으로 가져온 서버 데이터를 stale 상태로 바꿔주고, 리액트 쿼리가 스스로 데이터를 새로 불러오게 하는거였다.


(신난표정)

북마크 / 북마크 해제 하는 함수에 무효화를 달았더니 되어가지고 너무너무 좋고 하루종일 북마크 / 북마크 해제 클릭 했다.

여기서부터 진짜 중간발표 회고임 .. 진짜임

멘토 분이 전체적으로 도움이 될 말씀을 많이 해주셔가지고 우리 팀 피드백 아니어도 걍 적어놨다.

4조

  • 유저가 에러를 발생시킬 수 있는 행동 막기
  • 유효성 검사 - 사용자가 진짜로 잘못 입력했을 때 경고 띄우기 (디바운싱: 유저의 움직임이 멈췄을 때 체크하는 것)
  • 타입스크립트 꼭 배워야함 (JSDoc으로 언어 바꿔보기)
  • 사이트 내부에서 쓰는 이미지는 자체적으로 asset 폴더에서 관리하는 것보다 S3를 통해서 쓰는게 더 빠르게 랜딩되는 경우도 있고, 용량 면에서도 효율적일 것.
  • API 찌를 때마다 (API 요청하는 걸 찌른다고 표현하셨음 .. 진짜 신기 .. 실무에서는 그런가) 쿠키세팅하지말고 axios 인터셉트 설정하기 (인스턴스 말씀하시는건지 헷갈림) 개발자가 중복된 행동, 중복된 코드를 짜고 있을 때는 뭐가 잘못되어가고 있다고 느껴야함.

5조

  • redux 폴더 만들지말고 store라고 만들어서 그 안에 리덕스던, 리코일이던 넣기.
  • shared > axios 폴더로 이용하고 있던데, 그러지말고 api는 api 폴더 따로 만들어서 관리하기
  • 보편적인 api는 util 폴더에 넣고(로대시(?), 어레이 관리, 오브젝트 관리 등 언어 단에서 행동을 쉽게 만드는 애들) , 로직이 종속되어 있는 밸리데이션 같은 것들은 helper 폴더에 넣고 관리하기.
  • 모든 컴포넌트 안에서 모든 로직을 넣으면 컴포넌트 재사용성 떨어짐. 두군데서만 사용되어도 컴포넌트화 하는 곳도 있음.
  • (5조의 트러블 슈팅 관련) 해당 사례는 서버에 요청을 하는게 맞는 것 같음. 근데 프론트라고 해서 서버에 대해서 아무것도 몰라도 된다. 다 서버에 맡기면 된다는 아니고 웹 프로덕트가 제대로 굴러가기 위해서는 서로 대화해야함.
  • 라이브러리 쓰는거 좋은데 때로는 직접 만들어보는 것도 성장 기회임. 자동완성 라이브러리 들어가서 API 긁어보고 연구하고 왜 그런지 내부로직 생각해보기. 자동완성 같은 경우는 util 폴더에 넣으면 됨. 추상화의 레벨 높여보기 (개발자 역량에 중요한 요소)

6조

  • 라이브러리 없는 상황에서 같은 퍼포먼스를 보여줄 수 있느냐 생각해보기
  • UX 관련 피드백 (프로덕트에 중요한 유저 행동을 이끌어내는 UI는 플로팅 같은걸로 띄워놓거나 행동과 결과 사이를 오토 스크롤 같은걸로 자연스럽게 이어주기)

7조 (우리조)

  • 라이브러리 중복적인 것, 서로가 서로의 대체제인데 이게 왜 한번에 있는지 모르겠음. 안쓰는거 지워라
  • 린트 설정 안되어있는 것 같음. 서로 vscode 세팅 같이하고 프리티어 같은거 써라 (vscode 세팅 같이했고 .. 프리티어 쓰고있었음 근데 그렇게 안보이는것같아서 그냥 조용히 알겠다고 함)
  • 프론트엔드 성능체크 라이트하우스로 하겠다고 쓰여있는데 성능을 높이는 방법 중에 제일 중요한건 웹 바이탈 관리하는거임? 웹 바이탈은? 웹팩 설정에서부터 결정되고 엄청 중요함. 지금은 6주라는 프로젝트 기간 안에서 프로덕트 완성하기 위해 그걸 CRA한테 맡겨서 그 안에서 팀이 움직인거고 실무에서는 웹팩 설정 당연히 직접 함. 웹팩 설정 직접 해보는거 정말 추천.
  • PWA는 런타임에서 이용되는게 아님. 컴포넌트 안에 import해서 사용하는 것들은 런타임에서 이용되어야하는 것들인데 PWA는 build할 때만 필요한 애들이어서 dev dependency로 빼줘야함.
  • 클린 코드로 리팩토링할거라고 써놨던데 스타일 관련 생각하기 전에 컴포넌트에서는 순수하게 뷰만 관리하고, 비즈니스 로직 분리하기 (4조에서 얘기했던 것처럼) 내가 쓴 코드를 남이 봐도 알아보고, 이어서 쓸 수 있게 만드는게 필요함

8조

  • UX : 버튼이나 선택하는 곳에서 커서가 포인터로 안바뀜. 기본적으로 보여야하는 부분에서는 보여야 함.
  • 인라인이랑 CSS 같이 이용하고 있던데 styled components 사용할거면 그거 하나로만 사용하기
  • async & await 잘 사용하기
  • DocumentQuerySelector를 사용하고 있던데 리액트는 가상 DOM을 사용하는 프레임워크임. 근데 해당 함수는 직접 진짜 DOM을 만지는 함수고 레퍼런스를 따서 가상 DOM에 접근하는 방식으로 바꿔야함 (무슨말인지 X)
  • array 관리를 mutable 하게 할건지, immutable하게 할건지, 둘의 차이는? (모름.. 이 때 너무 졸려서 답변을 제대로 못알아들음 따로 알아보기)

9조

  • 리덕스는 플럭스 패턴 구조 위에서 움직임
    (이 때부터 졸려서 정신 놓음)

멘토링 후 느낀 점

리팩토링할 게 너무 많아서 이제 다시 시작하는 기분이 들었다.

API 빼내기

안그래도 중간 발표 전에 리팩토링을 한번 해야할 것 같아서 api 빼는 방식을 이전 기수 habit monster를 훔쳐보고 그걸 따라서 해보고 있었는데 그냥 가랑이만 찢어지고 따라해보지도 못하고 중간발표에 들어갔다. 근데 이걸 이제는 피할 수 없다는거죠?

TypeScript

(언젠가는 필수적으로) 배워야 하겠지? 라고 생각만 하고 있었던 건데 지금 자바스크립트 언어도 내 손발처럼 자유롭게, 100% 활용하지 못하고 있는 상황에서 6주 프로젝트 안에서 언어를 바꿔 프로덕트를 구현하는게 불가능하고, 너무 이른 때 같아서 사용을 하지 않는 방향으로 온건데 마이그레이션을 해서라도 타입스크립트를 써봐라! 라고 말씀하셔서 엄청 흔들리는 중. 근데 지금 기능도 안된게 많은데 소는 누가 키워…

리팩토링과 기능구현

22일날 실제 사용자 배포여서 그 때까지는 사실 사용자에게 보여질 기능구현부터 먼저하고 배포한 후에 리팩토링 하면안되나? 하는 악마의 마음이 스멀스멀 올라왔는데 팀원분이 리팩토링 먼저 하자고 먼저 말씀해주셔서 알겠습니다! 했다.

“어? 이 기능 없어도되나?”

데자뷰 인가요? 아니요 이번에는 “어? 신청자를 프로젝트 팀원으로 수락했는데 그 순간부터 신청자 정보(근데 이제부터는 내 팀원인..)를 어디에서도 볼 수 없어도 되나?” 입니다.

그렇더라구요. 푸핫~

프론트쪽이랑은 이 대화를 했는데 백 쪽이랑은 아직 안해서 빨리 얘기를 꺼내서 빨리 구현을 해놔야할 것 같습니다.

아무튼 다시 시작임 ~
근데 이제 22일날 배포여서 발등에 불이 떨어진 ~

profile
프론트엔드 개발자

9개의 댓글

comment-user-thumbnail
2022년 7월 17일

사실 이 긴 글 중에 본체는 중간발표 진짜 회고인걸로... ㅎㅎ. 알차게 보고 갑니다~

1개의 답글
comment-user-thumbnail
2022년 7월 17일

정말 잘 정리된 글입니다.

1개의 답글
comment-user-thumbnail
2022년 7월 18일

우와 대단해요!!!

1개의 답글

너무 멋진 글이에요 !!!!

1개의 답글
comment-user-thumbnail
2022년 7월 24일

잘 보고가용

답글 달기