Mount 프로젝트 회고

 

4개월 간의 프로젝트가 끝났다. 2월 14일 최종발표가 끝나고도 릴리즈 버전에 문제가 생겨 출시를 못하고 있었는데 드디어 플레이스토어에 등록 되었다. 출시 직후 백엔드 서버를 내려서 동작하지는 않는다(...)

 

많을 것을 배웠고 아쉬움도 남는 프로젝트였다.

느낀점

Github 이해도

Develop / Feature / Hotfix 등의 브랜치로 나누어 작업하는 것이 도움이 되었다. Feature/navigation에서 작업하다가 HomePresenter에 아이콘 추가하는 등 난잡하게 일하던 방식을 바꿀 수 있었다.

 

Issue 기능을 적극적으로 활용하고, Pull Request에 Template 을 만들어 작업했다. 카톡이 아닌 Github의 Issue 기능을 사용해서 문제가 발생한 상황과 코드를 바로 연결지어 확인할 수 있었고, Template에 맞게 풀리퀘를 올려 작업자들이 어떤 기능을 추가/수정했는지, 어떤 로직이 변화되었는지, 다른 코드를 작성할 때 참고할 점을 확인할 수 있었다. 

Typescript의 장점

TS로 진행한 프로젝트가 아니지만 TS의 필요성, 유용성을 깨달았다. 타입 추론 기능을 제공한다는 사실은 알고 있었으나, Mount 프로젝트를 진행하기 전까지는 그다지 필요하다고 생각하지 않았다. 그러나 Mount 앱의 화면 개수는 31개로, 3명의 초짜 프론트엔드 개발자끼리 진행하기에는 규모가 꽤 컸다. 초반에는 감당할 수 있는 수준이었으나, 구현한 화면의 개수가 늘어나고 부모-자식 컴포넌트의 깊이가 커질 수록 각 컴포넌트끼리 어떤 데이터가 오가는지 알아내기 힘들어졌다 (기획서에 상품을 추가하고 확인하려면 홈 화면 -> 상품 클릭 -> 수량 변경 화면 -> 기획서 선택 -> 기획서 화면의 과정을 거쳐야 했다). 매번 작업할 때마다 console.log 찍고 주석에 적어놓고 작업하는 것은 전혀 효율적이지 않았다.

 

이후 프로젝트에서 Typescript를 연습할 때 이전의 삽질의 경험 덕분인지 쉽게 적응할 수 있었고, 바로 Typescript의 장점을 깨달아버렸다. 

Redux 기초 지식

기존에 이론으로만 학습한 Redux 플로우(상태를 저장하는 Store에 변경하려는 정보를 담은 Action을 Dispatch를 통해 앱의 상태를 변경하는 Reducer 함수로 전달하는 일련의 과정)를 React-Redux를 통해 reducer와 action을 정의하고 각 컴포넌트에서 useSelector로 Store에 접근하거나 useDispatch로 상태를 변경하도록 구현해보았다.

에러 핸들링과 테스팅의 필요성

이때까지 개발 프로젝트를 진행하면서 테스팅을 적용하거나 에러 핸들링에 대해 적용해보지 않았었다. 내가 쓴 코드가 완벽하게 작동할 것이라는 안일한 생각과 테스트를 병행하면서 코드를 작성하는 것이 번거로웠기 때문이다. 하지만 릴리즈하는 과정에서 애플리케이션을 실행하고 로그인을 하면 에러 메시지도 없이 종료되는 심각한 문제가 발생했다. 꾸준히 예외 처리를 해두거나 테스트를 해보았다면 사전에 해결할 수도 있는 문제였다. 코드는 나 혼자 작성하는 것이 아니기 때문에 어떤 문제가 발생할 지 예상할 수 없으며, 에러가 발생하더라도 사용자에게 좋은 경험을 주기 위해 에러 처리를 고려하면서 구현하고 테스팅 적용하는 것이 중요하다는 것을 깨달았다.

 

진행과정

- 프로젝트 초기 설계

• folder structure : api, components, navigation, screen, store
• navigation : Auth, Main, Tab, Planner, ...
• Redux store : planners, search, users

- 화면 구현

• Home(Main, FoodDetail, RecDetail, Tutorial), Search, Favorite, MyPage, Plan, PlanEditor
• 상품 상세 화면(Detail)에서 기획서(Planner)로 상품 정보를 전달하는 로직 구현