최종 프로젝트 종료와 코드 리뷰 회고

최종 프로젝트 종료와 코드 리뷰 회고

18일 저녁 최종 프로젝트 발표가 끝나고 오늘 수료식만이 남게 되었습니다.4.5주라는 기간 동안 기획부터 디자이너와 디자인 협업, Supabase를 통한 백엔드 구현, React를 활용한 프론트엔드 구현까지 많은 일이 있었습니다. 이 글에서는 최종 프로젝트에서 있던 코드 리뷰를 통해 코드를 개선한 코드들에 대해 알아보겠습니다.

 

코드리뷰

코드리뷰란

코드리뷰는 코드 작성자가 아닌 팀원, 동료가 코드를 검토하고 피드백하는 행위를 말합니다. 코드리뷰는 버그를 발견하고, 코드의 품질을 높이는 데 도움을 줄 수 있습니다. 하나의 프로젝트 내에서 코드의 일관성을 유지하는 데 도움을 줄 수 있습니다. 

 

코드리뷰 필요성

현재 프론트엔드에는 eslint, prettier 등을 통해 코드의 일관성을 높이고, typescript과 같은 정적 타이핑 언어를 통해 조기에 버그를 발견하고 예방할 수 있습니다. 그럼에도 코드 리뷰를 하는 이유는 저런 도구를 통해 해결할 수 없는 다양한 장점이 있기 때문입니다. 코드의 기능과는 상관없는 예를 들면 유지보수성, 확장성과 같은 설계적 측면에 대해 살펴볼 수 있습니다. 비지니스 로직이 잘 동작하도록 짜여 졌는지, 이 코드가 우리 프로젝트의 요구사항을 잘 충족하는지에 대해 살펴볼 수 있습니다. 결론적으로 이러한 과정을 통해 팀원 간에 소통이 증가하고, 코드에 대한 팀 전체의 이해를 높이고 성장하는 계기가 될 수 있습니다.

 

코드 리뷰 예시

게시글 좋아요 api 함수 문제

문제: 기존에는 createLike 함수에 "현재 좋아요+1" 값을 서버에 업데이트를 하도록 넘겨주었다. 하지만 여러 사용자가 좋아요를 누르면 좋아요가 제대로 반영되지 않을 것 같다고 피드백이 생겼다.
해결: 서버에서 increment_like 함수를 만들어 서버에서 SET "like" = "like" + 1 를 하도록 하여 여러 사용자가 단 시간에 좋아요를 눌러도 버그 없이 카운트 되도록 코드를 변경했다.
느낀 점: 혼자 개발하고 테스트하여 여러 사용자에 대한 고려를 하지 못함

 

이메일 중복 체크 api에 과다한 데이터 호출 문제

문제: 이메일 중복 체크 위해 해당 이메일을 사용하는 사용자가 있는지 확인하는 api에 모든 사용자 정보를 요청하여 과다한 데이터를 요청받아 타 사용자에 대한 정보 유출과 성능 저하
해결: 체크할 이메일 값에 해당하는 사용자 데이터가 있는지만 count하여 숫자 값으로 반환 받음
느낀 점: 팀원이 api 호출과 supabase에 익숙하지 않았다. 다 같이 학습할 수 있는 기회가 되었다

 

라디오 버튼을 따로 사용하여 성별을 선택한 문제

문제: 회원가입 시 성별을 선택하는 부분에서 radio 버튼을 남성과 여성을 따로 사용하여 changehandler가 복잡해지는 부분 발생
해결: radio 버튼의 일반적인 사용법대로 input의 name을 'gender'로 통일하여 하나의 그룹으로 만들어 change 함수를 한 줄로 간소화
느낀 점: 코드가 너무 복잡하다면 때로는 잘못된 것이 아닌지 생각해보아야 한다

 

시군구 Select 컴포넌트이 key값 문제

문제: 시군구를 선택하는 select 컴포넌트에서 시군구 문자열 값이 '남구','중구'처럼 여러 도시에 같은 이름을 가진 구가 있어서 Key 값이 중복 될 수 있음
해결: 중복되는 Key 값이 없도록 시도와 시군구 값을 합쳐서 Key 값으로 지정
느낀 점: random 값은 아무 의미가 없기 때문에 좋지 않다고 생각한다. key값은 항상 유니크해야 한다. 

 

redux로 유저 데이터를 가져올 때 null 타입을 체크해야 하는 문제

문제: redux에서 user 값을 가져올 때 user값이 null일 수 있기 때문에 user 값을 사용할 때 매번 null을 체크하거나 !를 사용하여 타입을 강제해야 하는 문제가 발생
해결: 해당 컴포넌트는 user 값이 있는 로그인 상태에서만 렌더링 되기 때문에 props로 받아서 항상 user 값이 존재하도록 하여 "?." "!." 같은 타입 체크를 하지 않아도 되도록 변경. user 값을 확인하고 null일 경우 "return null"를 하여 조기에 컴포넌트가 끝나도록 하는 것도 고려해봤지만, hooks는 조건부로 실행되기 안되기 때문에 이렇게 해결하였다
느낀 점: 이 방식이 최선의 방식은 아니라고 생각한다. 일반 매번 타입 체크하는 것이 번거롭고 !를 사용해 타입을 강제하는 것은 잠재적으로 위험하다고 판단하여 코드를 변경하게 되었다

 

React-query  setQueriesData  함수 타입 문제

문제: react-query에서 optimistic updates를 할 때 setQueriesData 함수의 두 번째 인자의 any 타입 문제
해결: 기능을 구현했지만 정확히 어떤 타입을 해야 모르겠다는 팀원의 말에 따라 공식 문서를 열심히 찾아서 oldData: TQueryFnData | undefined 타입을 가진다는 것을 찾아 any 타입을 제거하였다.
느낀 점: 공식문서 가이드에는 없지만 잘 찾아보면 레퍼런스에서 타입을 찾을 수 있다.

 

supabase 데이터 타입이 제대로 잡히지 않는 문제

 

문제: Supabase에서 Join을 통해 리뷰를 받은 사람의 프로필 데이터를 가져올 때 데이터 타입을 제대로 가져오지 못하고 "{}[]"타입으로 잡혀 any가 사용되었다
해결: any 타입을 지우기 위해서 reviewed의 타입을 profiles 타입 또는 null 타입으로 지정하였다. 타입을 바로 변환할 수 없어 unknown으로 타입을 지정한 다음 다시 타입을 지정하였다. 
느낀 점: 다같이{}[] 타입으로 지정되는 이유에 대해 찾아 보았지만, 끝내 찾지 못했다. supabase의 공식 문서를 따라 직접 만들어 보았을 때도 이 현상과 비슷하게 타입을 제대로 찾지 못했다. 

 

코드의 일관성 유지

빠듯했던 일정과 기획의 변경으로 인한 코드의 더블 체크