[프로젝트 리팩터링] 국민은행 액티브 시니어 온보딩 페이지

🏁 00. 챌린지 결과

감사하게도 저희팀이 일등을 하였습니다. 1등을 해서 가장 좋았던 점은 제 코드에 대해서 현업 개발자의 코멘트를 받을 수 있다는 점이었습니다.
우려했던 만큼, 아쉬운 부분이 많이 있었다는 평을 받았습니다. 이부분을 그대로 둘 수 없었고, 개선하고자 리팩터링을 하게 되었습니다.

⚙️ 01. 현업 개발자의 코멘트

• 현업 개발자의 코멘트에는 총 세가지의 문제점이 적혀있었습니다.
• 이를 기반으로 왜 이 부분이 문제가 되는지 공부해보며 리팩터링하게 되었습니다.

1. 우선적으로 Img를 public폴더가 아닌 src 폴더에 구성한 것이 아쉬움
2. pages 폴더 내에 components 폴더를 따로 두어 정리한 것이 아쉬움
3. style이 한 페이지에 합쳐져 있는 것이 아쉬움

⚙️ 02. 리팩터링

2-1) img를 public폴더가 아닌 src폴더에 구성한 것이 아쉬움

• 기존에 src 폴더에서도 쓸 수 있다는 편안함으로 이미지를 src 폴더에 저장하였습니다.

• 이미지를 저장할 수 있는 큰 방법은 총 2가지 입니다.

  1. public 폴더에 저장 -> 상대경로로 잡기
  2. src 폴더에 저장 -> import 를 이용하기

• public 폴더에 저장할 때의 특징

  - webpack에 의해 관리되지 않음.

  (minify되지 않고, content hash가 포함되지 않는다)
  - public 폴더에 접근하기 위해서는 PUBLIC_URL 환경변수 사용 필요
  - 경로가 잘못 되었거나 파일이 없을 경우 컴파일단계에서 에러가 발생하지 않고, 404 에러가 발생
  - CRA 문서에서 다음과 같은 경우에만 public 폴더에서 관리하는 것이 유용하고, 이외에는 src 폴더 관리를 추천
  => 여기서 의문 public폴더에 저장하는 것의 장점이 많지 않은데 왜 그런 방식을 추천했는지 의문이 들었습니다.

• src 폴더에 저장할 때의 특징

  • 파일을 찾지 못하는 경우, 컴파일 단계에서 에러를 잡을 수 있음
  • import할 경우 참조할 수 있는 경로(path) 문자열을 출력
  • content hash가 파일명에 포함되기 때문에 브라우저가 오래된 버전(파일 수정 전)의 파일을 캐싱하고 있는 경우를 고려하지 않아도 됨 (파일이 변경되었을 때만 hash값이 변경됨)
  • 서버 요청 횟수를 줄이기 위해 10,000 bytes 이하의 이미지는 path대신 data URL을 반환
    (bmp, gif, jpg, jpeg, png 파일에만 적용, SVG 파일 제외)
    이 때, 파일 크기 기준(10,000 byte)은 IMAGE_INLINE_SIZE_LIMIT 환경변수로 설정을 변경 가능

• 상대적으로 Public보다 src에 이미지를 저장하는 것은 이점이 적은듯 하였습니다.

• 이 부분에 대해 다른 현직자 분에게 조언을 구했고, 아마 현업에서는 Public에 저장을 많이하고 관습적인 부분이 아닐까라고 답변해 주셨습니다.

• 저는 현업에서 협업을 잘하는 개발자를 꿈꾸기 때문에, 퍼블릭에 옮기는 작업을 진행해보았습니다.

  • 가장 먼저 했던 작업이 public에 옮기고, import를 지우고, src명을 변경하는 것이었습니다.

src='img/img.png'

• 잘 작동되는 듯 싶더니, 처음에 파일을 불러올 때 첫 페이지를 읽어오지 못했습니다.
  • 이 부분은 아래와 같이 public 경로를 지정해주는 것으로 해결할 수 있었습니다.

const App = () => {
   return (   
       <img src={process.env.PUBLIC_URL + '/myImagePath.jpg'} /> 
   ); 
};  
export default App;

2-2) pages 폴더 내에 components 폴더를 따로 두어 정리한 것이 아쉬움

• 과거 코멘토에서 리액트의 파일들을 관리할 때, Pages를 분리하고 components 파일을 만들어주고, pages 별로 components를 분리해주는 것이 좋다고 이야기해주셨습니다.
• Pages 파일에서 components 하위파일을 만드는 것이라 판단하여, 제작하였습니다.
• 그러나 이 부분은 나의 오해로 인한 결과였고, 이러한 파일로 인해 협업할 때 문제가 생겨날 수 있다는 코멘트를 받게 되었습니다.
• pages내에 components를 분리하는 것이 아닌, components 내에 pages 별로 분리하는 것이 필요했습니다.
• 그래서 전반적으로 수정을 진행하였습니다.

2-3) style이 한 페이지에 합쳐져 있는 것이 아쉬움

• styled 컴포넌트를 사용하여 프로젝트를 진행하였습니다.
• 코멘트는 스타일의 내용이 길기 때문에, 나눠야할 필요성에 대해 이야기해주셨고, 저는 차라리 페이지를 더 쪼개서 styled 컴포넌트의 장점을 살려보자라는 생각을 하게되었습니다.
• 그래서 기존에 다음 이미지로 넘어가는 페이지들 중 Intuition 페이지와 Accessibility 페이지를 페이지넘어가기 전과 후로 나누어 컴포넌트를 분리 하였습니다.

📓 03. 마무리하며

이번 리팩터링은 리액트의 효율적인 구조에 대해서 다시 한번 생각해 볼 수 있는 시간이었습니다. 이미지 파일에 대한 이해와 컴포넌트 폴더 정리, 분할되어야 하는 component까지 직접 경험하지 않았다면 이해하기 어려웠을 것이라 생각합니다. 다음에는 깨달은 것들을 바탕으로 더욱 깔끔한 코드를 만들고 싶습니다.

참고자료

https://itchallenger.tistory.com/683
https://bokjiho.medium.com/react-%EB%A6%AC%EC%95%A1%ED%8A%B8%EC%97%90%EC%84%9C-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EA%B2%BD%EB%A1%9C-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0-public-src-%EB%94%94%EB%A0%89%ED%86%A0%EB%A6%AC-%EC%B0%A8%EC%9D%B4-fddb4f455c2a