개발자
류준열

설계 리뷰

  • 덜 구현된 채로 완료처리되는 일감들
  • 불필요한 작업에 쏟는 시간
  • 자신이 작업하지 않은 부분에 대한 이해도 부족

이를 개선해보고자 설계 리뷰라는 것을 만들었다.

커밋메시지 주도개발, 뱅크샐러드의 테크스펙을 참고했다.

목적

  1. 할 일과 하지 않아도 되는 일을 명확히 함으로써 에너지를 흩뿌리지 않는 것.
  2. 서로 동일한 이해도를 갖는 것

목차

요약

3줄 내외로 정리한다.

유저는 관리자 권한이 필요한 페이지에 접근 할 수 없다.
url 등 비정상적인 방법으로 권한이 없는 페이지에 접근 시 강제 리다이렉트 시킨다.

배경

이 기능을 왜 만드는지, 어떤 문제를 해결하려 하는지, 이전에 어떤 시도가 있었는지.

일반 사용자가 url을 통해 관리자 페이지에 접근하는 사례 발생
일반 사용자의 관리자 접근을 제한하여 시스템 문제 발생을 예방

목표

유저는 ~~ 할 수 있다. 의 형태로 작성한다.

유저는 A,B,C,D 페이지에서 테이블 우측 상단 버튼들과 체크박스를 볼 수 없다.
유저는 사이드바에서 A하위의 수정,실행 버튼과 관리자 버튼을 볼 수 없다.
관리자는 유저가 보지 못하는 모든 것들을 볼 수 있다. (사이드바 하위의 관리자 버튼, A페이지 상단의 실행, 추가 버튼)

목표가 아닌 것

프로젝트에 연관되어 있으나 목표와 관련 없는 것을 작성한다.
이것도 붙히자, 저것도 붙히자 등 리뷰어의 폭주를 막기 위함

서버 컴포넌트에서의 api call과 미들웨어 사용을 고려하지 않음

계획

상세히 묘사한다. 결정하지 못한 상태라면 고려하고 있는 것들을 다 목록화 해서 작성한다.

  • AuthGuard.tsx에서 전역 state로 isSuperUser을 저장한다. (GET: /v1/user/me 의 response)
  • A, B C, D, 관리자 페이지에서 isSuperUser에 따라 특정 UI 노출 여부를 결정한다.
  • 일반 유저가 관리자 접근 권한이 필요한 페이지에 접근하면 AuthGuard.tsx 에서 뒤로가기 시킴
버그를 유발할 수 있는 부분

쿼리키를 통한 캐시관리 등 특히 조심해야 하는 사항들도 작성한다.

  • 로그인/비로그인 상태와 관리자/일반유저 간의 쿼리키가 겹치지 않도록 주의

이외 고려 사항들

고려했었으나 하지 않기로 결정된 사항들을 작성하여 논의가 끝난 주제가 다시 이야기되지 않도록 함.

  • 로그인 버튼 디자인은 디자이너 휴가 복귀 후 작업함
  • 관리자 전환 스위치 기능 → 추후 논의

커밋 메시지

가장 중요한 부분이다.

내가 어떤 코드를 쓸 지 커밋 메시지를 미리 작성하고 이 범위를 벗어난 작업은 하지 않는다. 꼭 필요한 추가 작업이 발견되면 할 일 목록에 추가한다.

첫 회사 CTO님의 커밋메시지 주도개발을 따라했다.

  • feat: PMA2-894 auth-guard.tsx에서 유저정보 조회 및 유저 정보를 갖고 있는 전역상태 추가
  • feat: PMA2-894 관리자를 위한 UI는 일반 유저에게 보여주지 않음.
  • feat: PMA2-894 일반 유저가 관리자 접근 권한이 필요한 페이지에 접근하면 강제 리다이렉트

작성자, 리뷰어 회고

  • 작성자 회고
    • 역시나 예측이 부족했다. queryProvider를 만들어야 함을 예측하지 못해서 첫번째 커밋의 변경이 예상보다 컸다.
    • 커밋메시지 작성시 선행작업들을 놓치지 않도록 gpt를 이용해보자
  • 리뷰어 회고
    • 쿼리키가 겹치는 상황때문에 잠재적 버그가 발생할 상황은 크게 없었던 것 같음.

노션 이미지 첨부

아래 이미지는 기존 설계리뷰를 회사 업무와 무관한 내용으로 일부 수정한 내용이다. 설계리뷰

회고

기존에는 잘 모르는 작업을 할 때 작업과 학습을 동시에 진행했다. 이번에는 커밋메시지 주도개발을 위해 잘 모르는 부분을 미리 공부해야했고, 간단한 기술검증이 필요하기도 했다. 작업을 시작하기까지 오래걸렸지만 작업을 시작하고 나서는 계획에 벗어나는 일을 하지 않음으로 생각과 노력의 비용을 줄일 수 있었다. 그럼에도 실제 작업할때 오차가 생겼다.

한편, 작은 작업의 경우 불필요하단 생각이 들었다. 일을 위한 일이 아닌가? 하는 생각도 들었다. 설계 리뷰를 작성하는 기준을 정해야 할 것 같다.

동료는 목표를 유저는 ~~ 할 수 있다.의 형식으로 적으면서 유저 입장에서 생각하게 되는 것, 해야 하는 일을 정의 하는 것이 좋았다고 했다.

회고는 잘 이뤄지지 않았다. 이유는 너무 바빠서. 나의 회고는 계속 작성했지만, 회고를 작성하는게 무의미한 문장들을 짜내는 것이 아닌가? 하는 의문을 스스로 떨치지 못해 동료의 회고를 요구하지 않았다.

나는 첫 회사에서 날 성장시켜줬던 사람들처럼 나도 동료의 성장에 기여하고 싶다. 그래서 신입 동료를 성장시키는 것도 내 업무의 일부라고 생각한다.