pre_onboarding_첫 번째 과제

첫 번째 과제를 마치고

과제를 마치고 프리온보딩의 메인 노션페이지를 보게되었다. 거기에는 다음과 같은 글귀가 적혀있었는데 '첫 번째 과제에서 나는 학생이었을까 개발자였을까?'를 다시 생각해 볼 수 있는 계기가 되었다.

이와 관련해 나에게 던진 세부적 질문은 이렇다.

• 생산성을 고려하였는가?
  간단한 프로젝트에서 redux 등 전역상태관리가 필요할까 싶지만 현재의 과제보다는 앞으로 있을 업무를 진행하는 마인드셋으로 임하고 있다.
  이렇게 생산성을 기준으로 생각하여 본 과제에서도 다음과 같은 폴더 구조를 설계하였다.
  

  모든 파일이 component 폴더에 위치하거나, 첫 번째 계산기와 두 번째 계산기만 폴더 분리를 해도 무방이없을 정도의 규모였지만, 대규모 프로젝트라고 가정하였다. 지금 당장은 폴더 구조 관리나 전역 상태 관리, 재사용 가능한 컴포넌트등은 오히려 비효율적인 시도일 수 있을 것이다. 하지만 회사 업무를 한다고 가정한다면, 위와 같은 것은 프로젝트의 규모 상 생산성을 끌어내는데 필수적일 것이다.
  그래서 위와 같은 폴더 구조로 프로젝트를 관리하였다. input이나 button 등 자주 사용하는 기능을 UI폴더에 모아두었으며(다음 프로젝트에서는 layout으로 변경예정), 페이지 경로는 routes 경로에서 관리하는 방식으로 하였다. 이는 다음 프로젝트에서는 pages로 변경할 것이다. store에서는 전역상태관리가 이루어진나. index.js파일이 하나의 store로 export된다.

  
  

• 새로운 기술을 적용하려고 하였는가?

  약간의 성능차이, 효율차이가 있더라도 개발자라면 관심을 갖고 기술의 진보를 좆는 것이 좋다고 생각한다. 그런 의미에서 이 번 과제에서는 최근에 공부한 react-redux와 @reduxjs.toolkit의 이용과 전역상태관리의 적용을 시도하였다.
  처음에는 팀원들이 redux사용 경험이 없어 redux를 이용한단면 코드관리에 어려움이 있을 수 있으므로 일반적인 props 전달 방식으로 진행을 하였다. 하지만 기능이 추가되고, 폴더 구조가 생기면서 불필요한 props의 전달이 느껴졌다. 소규모 프로젝트인데도 말이다. 그래서 팀원에게 우선 react-redux의 장점과 구조를 설명한 뒤 현 과제에서 사용을 제안했다.
  결국 간단한 사용법 설명 뒤 전역 상태 관리를 하게되었고, 이전 보다 유지보수가 용이한 깔끔한 코드관리를 할 수있게 되었다.

아쉬웠던 점

• 버전관리의 어려움
  git... 아주 무서운 녀석이다. 팀 프로젝트가 있는 곳에 이 녀석 욕이 나오지 않는 경우는 없을 것이다. 우리팀도 첫 번째 과제이다보니 버전관리 중 발생한 오류가 많았다.
  git branch관리가 미흡했던 것 같다. 우리는 모든 것이 병합되는 main branch를 중심으로 firstCalc, secondCalc를 하위 브랜치로 생성하였다. 처음에는 branch관리가 순조롭게 진행되었다. firstCalc의 내용은 해당 브랜치에만, secondCalc의 내용 역시 해당 브랜치에만 들어가 있어 각 브랜치는 서로 의존적이지 않다. 하지만 중간에 main 브랜치로 merge하면서 문제가 발생하였다.
  최종 완성이 아닐 경우 main에서 merge 이후 다시 작업하고자 하는 branch로 checkout하며 버전관리가 이루어졌어야했지만 그 사실을 망각 한 채, 모든 것을 main에서 관리하였다.
  한 번 그렇게 되니, 다른 하위 브랜치와 main 코드의 차이는 많아져만 갔고, 결국 어쩔 수 없이 main 브랜치로만 진행해야하는 상황이 되어버렸다.

main에서 다른 브랜치를 merge한 이후 다시 작업하고자 하는 브랜치로 checkout 하는 것, commit할 때 더 꼼꼼히 확인해봐야겠다는 것을 깨달았다.