Admin 프로젝트 재구축 회고

 

7월달에 어드민 개선하기 글을 쓰고나서 이제야 어드민 프로젝트 재구축을 완료하였습니다. 중간에 다른 업무와 병행하느라 예상했던 것보다 좀 더 걸렸네요. 많은 문제가 있던 어드민을 완료하고 이제 QA 진행에 들어갔습니다. 기존에 제기 되었던 문제(Recompiling 시간, 타입추론, 버그 양산 코드 제거, API 문제 등)들은 당연히 다 해결되었습니다. 항상 어드민 작업을 맡게 되면 그리 규모가 크지도 않은 프로젝트의 Recompiling 시간 때문에 한숨을 쉬었던 기억이 많았는데 되게 뿌듯하면서도 문제가 생기지 않을까 염려되기도 하네요.

 

오늘은 어드민 프로젝트를 다시 작업하면서 느꼈던 많은 부분들 중 제 스스로의 피드백과 함께 회고글을 작성해볼까 합니다.

- 사용기술

• React, React-router-dom, Typescript, Javascript
• Client State Library - recoil
• Sever State Library - react-query
• Bundling - Webpack5
• HTTP - Axios
• CSS Library - Emoition, scss
• UI Component Library - Prime React

 

리액트는 보일러플레이트가 아닌 webpack으로 환경설정을 구성하였고 위와 같은 기술환경으로 작업을 진행하였습니다. UI Library는 MUI가 아닌 Prime react를 사용하였는데 기존 문제점에 MUI가 있었기도 했고 레이아웃은 저희가 만들고 그 안에 필요한 부분들에 대해서 UI Library에서 제공해주는 기능을 사용하자라는 의미에서 새로운 UI 라이브러리로 선택하여 작업을 하였습니다.

- 회고

되게 여러가지를 느꼈습니다. 제가 회사에 입사 후 일정 기간동안 작업을 진행했을 땐 코드는 크게 변경하지 않아도 or 크게 변경할 필요를 느끼지 못했던 잘 돌아갔던 코드들이였습니다. 사실 완성됐던 코드에서 기능을 추가하거나 약간의 변경사항이 있던 코드들이였죠. 이게 반복되다보면 거기에 머물게 되고 생각의 전환이 잘 되지 않더라고요. 설계가 잘못됐다면 뒤집어 엎어서 하는 과감함도 필요하고 어떠한 코드를 보고 의문점을 가지게 되면 이걸 왜 이렇게 했을까? 하면서 깊게 생각도 해보고 해봐야 하는데 그냥 잘 되는 코드니까 굳이 지금 안건드려도 되겠지? 라고 생각해서 넘어간게 많았던 제 자신이 생각나더라고요.

 

그랬기에 이번에 완전히 처음부터 진행한 어드민 프로젝트의 작업 시간이 더 귀하게 느껴졌던 것 같습니다. 한 프로젝트를 처음부터 빌드업 해 가면서 여러가지 환경 설정(webpack, 폴더구조, 타입 등)의 대해 고민하고 깨닫게 되었습니다. 

 

그런 반면 당연히 제 단점과 약점도 많이 깨닫게 되었습니다. 제가 앞으로 어떤 고민을 해야 하고 어느 부분을 좀 더 보완해야 하는지 생각할 수 있는 시간이기도 했습니다. 재구축을 하면서 되게 많은 부분을 느꼈는데 제가 생각한 부분들의 대해 먼저 얘기를 하고 같이 작업한 프론트 동료분의 생각이 듣고 싶어 티타임을 요청했었습니다. 

 

1. 컴포넌트를 더 잘개 쪼개보자

저는 코딩할 때 가독성을 되게 중요시 여기는 편인데, 바쁘게 작업을 하고나니 컴포넌트를 좀 더 분리하여 코드 라인 수나 가독성을 좀 더 좋게 할 수 있는 부분들이 많이 보이더라고요. 실제 작업할 당시 일단 기능을 되게 하고 나중에 하자라는 생각으로 코딩을 하고나면 결국 나중에 우선순위가 후순위로 계속 밀리게 되는 상황이 발생했습니다. 컴포넌트를 더 잘게 쪼개야겠다라는 생각이 들 때 바로 시도하자!

2. JS, TS의 대해서 좀 더 깊게 공부하자

JS, TS의 대해서는 공부해도 계속해서 공부할 게 생기는 것 같습니다. 책을 읽다가 최근 루즈해졌는데 다시 마음을 다잡게 되는 계기가 된 것 같습니다. JS의 배열을 다루는 연습을 좀 더하고 TS 타입을 정의할 때 전역적으로 사용할 수 있는 부분들이나 제네릭을 이용하여 좀 더 유동적으로 타입을 정의할 수 있게 한번 더 생각하고 공부해야겠다라는 생각을 했습니다. 

 

- React-query refetch를 props로 넘길 때

// commonType
export type RefetchFunction<T> = <TPageData>(
  options?: (RefetchOptions & RefetchQueryFilters<TPageData>) | undefined
) => Promise<QueryObserverResult<T, unknown>>;

// Usage
interface Props {
  refetch: RefetchFunction<TestResponse>;
}

- Error

// commonType
type Errors = {
  errors: {
    code: string;
    defaultMessage: string;
    objectName: string;
  }[];
};

export type CustomError = AxiosError<Errors>;

// usage
const handleOnClick = async () => {
  try {
    await testApi(id)
    } catch (error) {
      toast.error(getErrorMessage(error as CustomError));
    }
 };

3. 어떠한 요구사항인지 정확히 파악하고 내가 해결하려고 하는 방법에 대해 다시 한번 생각해보자 !

예를 들어, A의 기능을 만드려고 할 때 막혀버릴 때 어느 순간 생각이 갇혀버려서 그 방법이 맞다고만 생각하고 그 안에서만 그 문제를 해결하려고 하는 경향이 있더라고요. 이럴 때 동료에게 질문을 하고나면 스스로 아 이건 충분히 해결했을만한 문제인데 물어봤던 것들이 좀 있었습니다. 퇴근할 때 왜 질문을 했을까?란 고민을 되게 많이 하는데 하다가 잘 안될 땐 잠시 멈추고 그림을 그려보던가, 요구사항의 대해 글로 작성해가면서 Step별로 해결해 나가는 연습도 해보려고 합니다. 실제 피드백도 그렇게 해주셨고, 좀 더 폭넓게 바라보는 시각을 가지고 생각의 전환을 해야겠다란 생각을 했습니다.

4. 너무 편리하게(단순하게)만 생각하려고 한다.

개인적으로 이 부분이 가장 많이 생각하고 중요한 부분 같습니다. 이전에 했던 방식 이렇게 했었으니까 또 이렇게 해야지..가 아니라 이전엔 이렇게 해봤는데 이 부분엔 어떠한 개선점이 있을까?를 생각하는 것도 중요하다고 생각합니다. 당장 2번에 react-query나 Error를 예시를 들 수 있을 것 같습니다. 생각을 안하는 건 아니지만 너무 단순하게만, 편리하게만 코딩을 하려는 습관은 나중에 누군가가 저로 인해 발생된 문제를 떠안을수도 있고, 상위 컴포넌트에서부터 잘못되어 뒤집어 엎는 경우도 발생될 수 있구요. 당연히 경험이 없어서 일 수도 있지만 이런 습관은 미리 길러두는게 좋으니까요!

 

제가 이 부분을 되게 진지하게 얘기했었는데 저보다 좀 더 경험이 많으신 프론트 동료분께서 그러시더라고요. 사실 우리 회사 프론트 업무는 난이도가 크게 있는 편이 아니다라고..어렵지 않게 해결할 수 있는 부분이 많다라고 얘기하면서 전 회사에서 겪었던 요구사항이나 문제들의 대해 공유해 주셨는데 확실히 느껴지더라고요. 사실 저도 첫 회사지만 1년정도 다니다보니 그렇게 느낀적이 종종 있었는데 이렇게 또 얘기를 나눠보니 느낌이 많이 달랐습니다. 

 

복잡하고 생각을 많이 해야하는 요구사항을 받았을 때, 내가 그걸 해결할 수 있는 능력은 되는가?는 또 별개의 얘기긴 하지만 회사의 업무로 무조건 끝내야 하는 업무를 받았을 때 내가 끌어낼 수 있는 역량은 어디까지인가? 스스로 어디까지 해결할 수 있는가? 그걸 위해 어떤 준비를 할건가?를 많이 생각하게 하는 대화였습니다.

 

이 어드민 재구축 기간이 기존 개발했던 시간보다 많은 것을 느끼게 하고 생각하게 해주는 시간이였던 것 같아 스스로를 많이 되돌아보게 됐던 것 같습니다.