7월 말 ~ 9월 말 동안 했던 프로젝트가 일단 막을 내렸다. 처음, 중간, 끝 모두 고난의 여정이었지만 어찌저찌 잘 매듭지어서 다행이다.
개발배경
난 뭘 하기 전에 늘 적어놓는다. 내 휘발성 메모리 덕분에 그리고 계속해서 습관으로 쌓아올리려 했던 노력덕분에 계획하는 게 버릇이 됐다.
이 습관을 갖게 된 계기는 사소했다. 내 삶을 바람직하게 살고 싶었다. 바람직한 삶? 나한테 바람직한 삶은 하루하루 성장하는 삶이었고, 그렇게 살기 위해 계획하는 습관을 들였다.
또, 내가 원하는 모습으로 바뀔 수 있다고 나한테 그리고 남들한테 증명해보고 싶었다. (이유는 떠오르지 않는다. 아마 불안감이 만연한 시기에 나를 바꿈으로써 얻은 자신감으로 내게 주어진 문제를 돌파하고 싶었던게 아닐까 싶다.)
습관을 들이기 위해 했던 것중 하나가 다이어리 쓰기였다. 다이어리에 계획짜서 거기에 맞게 충실한 하루를 보내는가 싶었더니...
사람은 처음부터 잘 하는 것이 있고, 그렇지 않은 것이 있지않은가? 다이어리를 쓰는 것과 계획을 세우는 것은 내게 있어서 후자와 같았다. 어떤 목적을 가지고 살고 싶은 건지, 어떤 목표를 설정할 건지 등등 결국 헤매다가 감정배출용 일기장으로 썼었다.
18년도때 썼던 다이어리, 표지가 달로 그려져있어서 이뻤었다.
19년도때 썼던 다이어리..가 아니라 weekly planner, 프로젝트를 만드는데 이것의 영향을 조금 받았었다.
흥청망청 쓰다가 내 마음의 강렬한 동기(18년도 여름부터 회사를 다녔었는데, 부사장님한테 자극을 엄청 많이 받았었다.)가 누적되어, 지금의 습관으로 발현됐다.
아무튼 이렇게 종이에 적고, 적은 것을 토대로 실천하는 횟수가 늘어나자, 펜을 쓰는 건 그만두고 엑셀로 쓰기 시작했다.
구글드라이브에 스프레드시트로 작성한 모습 (내용은 가렸다.)
weekly로 따로 분리를 해서 주별 계획을 세웠다.
월말이 올 수록 시트지의 내용이 길어지고, 한달이 지날 때마다 시트지의 개수가 계속 늘어나서 넘기기 귀찮았다.
그래서 고민하다가 결국 웹서비스의 형태로 만들기로 했다.
목적
이 프로젝트의 목적은 두 가지다.
- 이 문제를 해결해서 편한 삶을 사는 것
- 리액트를 익혔으니 적용해보는 시간
기술스택
Front
- Electron
- React
- Redux
- material-ui
Back
- Express
- Sequelize
- mySQL
일렉트론은 데스크탑에서 실행시키고 싶어서 선택했고, 마테리얼은 디자인에 너무 많은 시간을 쏟게 하고 싶지 않아서 선택했다.
백엔드는 장고와 express를 두고 고민 했었다.
가장 최근까지 썼던 것은 3~5월달에 대학선배를 도와주는데 썼던 장고다.
하지만, 언어를 통일 시키고 싶어서 express를 선택했고, ORM으로 sequelize를 사용하기로 했다.
Context API와 Redux를 두고 고민했었는데, context api로 코딩하게 되면 결국에 redux의 꼴이 될 거 같아 redux를 쓰기로 했다.
사실 redux를 선택한 이유는 중앙저장소 기능 말고도 middleware의 영향도 좀 컸다. (redux-saga가 진짜 편했다!)
어떻게 만들건지
- 각각의 영역(알고리즘 공부, 프론트, 백, aws공부 등)으로 나누고 이것을 한 눈으로 볼 수 있었으면 좋겠음
- 오늘 할 일과 그 월이 있었으면 좋겠음
이 두개를 바탕으로 디자인과 기능을 구현했다.
그리고 이런 결과물이 나왔다.
아쉽거나 어려웠던 것
UI 구성에 관해
처음 UI 스케치 한 거랑 최종 결과물의 디자인이 다르다. UI를 만들면서 많이 한 생각이 지금 이 컴포넌트가 다른 애들과 (UI가) 어색하진 않겠지? 였다. 겉모습만 신경쓰다보니 애니메이션은 신경을 쓰지 못했다.
리덕스 객체 책임 분담
리덕스에 있는 객체 값을 조회해서, 그 값을 토대로 컴포넌트 내부의 값을 바꾸는 형태로 코딩했다.
이런 형식으로 코딩할 때 주의할 건, 하나의 객체에 많은 책임을 물리지 않았는가가 된다.
OOP에서도 SOLID의 S가 단일 책임 원칙일정도로 1객체1책임을 지향하는데, 안타깝게도 이 프로젝트에서는 제대로 지켜지지 않았다.
더군다나 내부의 값이 바뀌면 리렌더링이 되는 리액트의 특성상, 하나의 객체가 바뀌었을 때, 수 많은 컴포넌트가 리렌더링 된다고 생각하니 아찔하다.
프로젝트 할 때는 인지하고 있었지만 구현하는 것에만 정신이 팔려 스스로 기술부채를 쌓아가고 있었다.
GIF상에서 토픽이나 태스크 만들 때, 달력을 제외한 거의 모든 컴포넌트가 리렌더링 된다. 해결책은 노트에 작성해놨으니 리팩토링을 열심히 하면 된다.
달력
material-ui picker가 있었는데 뭔가 맘에 안 들어서 내가 만들었다.
moment를 이용해 날짜 조작과 연산을 했었다.
만들어서 사용해보니 엉성한 부분도 있고, 불편한 부분도 있다.
이거 만들면서 클린코드 마려웠었다..
의도가 드러나지 않은 코드가 많아서 이건 진짜 두고두고 리팩토링해야겠다고 다짐했었다.
프론트와 백 사이의 고민
API의 형태를 정의하고, 인풋과 리턴 데이터를 정하는 거에서 고민이 많았다.
프론트에서 원하는 데이터와 백에서 뱉는 데이터가 달라서 데이터 포맷을 여러번 수정 한 적도 있다.
개선, 만들고 싶은 것
github기능 이용
원래는 나 혼자 하는 프로젝트라 따로 어딘가에 적어두면서 했는데, 이슈, PR, 액션, 프로젝트 탭을 활용해서 나중에 하게 될 협업에도 대비하고 싶다.
달력
사용자의 입장에서 라이브러리의 형태로 만들어보고싶다.
로깅
로깅하는게 없다. Sentry같은 걸 써서라도 로깅을 집어 넣고싶다.
리덕스 책임분리
메모장 기능
엑셀에 주저리 주저리 적어놓은게 있는데, 여기서도 주저리 주저리 적고싶다.
타이머
내가 얼마만큼 특정 토픽에 몰두했는지 알고싶다.
앞으로 할 것과 느낀점
- 프론트엔드에서 테스팅하는 법을 익혀, 이 프로젝트에 녹여보고 싶다. 좀 더 견고한 프로그램을 만들고 싶다.
- UI는 가져다 써서 리액트 상에서의 Responsible한 디자인은 직접 만들어 본적이 없다. 다음엔 직접 만들어서 적용해 보고 싶다.
- 역시 내 힘으로 문제를 해결하는 건 재밌다. 과정은 재미없지만 끝이 재밌다!
다음 프로젝트?
- 각종 테스트를 익혀 새 프로젝트에 적용
- React로 만드는 반응형 사이트
