[칭찬일기 개발기 #1] 기술 스펙 선택

남들과 비교하다보면 끊임없이 작아질 수 밖에 없는데 그러다보면 나를 사랑하기보다 남의 모습을 가진 나를 사랑하고 싶어하게 되는 것 같다.

나 자신을 칭찬하며 나를 돌아보다보면 좀 더 나를 아낄 수 있지 않을까하는 생각에서 시작된 프로젝트..

---

기술 스펙 선정 기준은 안해본 것을 해보는게 첫번째고

두번째는 부가적인 작업들을 최소화 하는 것이다..!

Framework

expo

선택지는 Flutter, React-Native, Expo 이렇게 3개로 두고 고민했다.

일단 Flutter vs RN에서는 React를 시작한지가 오래되지 않아서 새로운 언어보다 react를 좀 더 파보고 싶었다.

Flutter는 다음 프로젝트에 꼭 해보는걸로...

그리고 RN vs Expo.

지금 회사에서는 React Native 생으로 개발을 진행하고 있다. expo가 편하긴 하지만

Expo에 종속된 라이브러리들을 써야되고 커스터마이징이 불편한걸로 알고 있어서 RN으로 진행했다.
(카카오 로그인 등 직접 플러그인 개발하거나 수정할 일들이 좀 있었다)

하지만 이번 사이드 프로젝트에는 그렇게 복잡하거나 국내 플랫폼 로그인 같은 것은 사용하지 않을 것이기 때문에 Expo로 정했다.

그리고 expo는 뭐가 좋니 안좋니 하는 것들 듣는것보다 직접 경험해보는게 낫다고 생각했다.

State Management

Redux

써봤던 상태관리 툴은 Context API, Zustand 두가지 뿐이었다.

Redux가 레거시도 많고 복잡해서 경량화 되고 있다고는 하지만 새로운 상태관리 툴에 비해서 복잡해 보이긴 한다.

하지만 경험해보지도 않고 판단하는건 위험(?)하다 생각했고,

제일 널리 쓰이고 있는 녀석을 해보지 않는것도 좀 아니라고 생각해서 요녀석으로 결정했다.

Architecture Design Pattern

MVVM

지금 프로젝트에서도 나름 역할들을 구분하며 작업을 하고 있지만,

비즈니스 로직들과 뷰가 혼재되어있어 코드가 길어지고 테스트 코드를 작성하는데도 걸림돌이 되어서

MVVM 구조를 토대로 조금씩 수정해나가려고 했다.

하지만 하는 일도 바쁜데 시행착오를 겪어가며 구조를 수정하는 것도 애매해서 미루고 있는데...

이 프로젝트로 그 시행착오를 줄여보고자한다.

Software Development Methodology

TDD

TDD는 이전부터 계속 해보고 싶었던 주제였다.

회사에서는 새로운 기능을 만들거나 개선 작업이 끊임없이 이어져서 차마 시도해볼 생각을 못했다.

빠르게 바뀌는 서비스에도 맞는 방법론인가 싶기도 했고, 실제로 부정적인 여론들이 많이 보였다.

하지만 그들도 제대로 TDD를 해보고 해보는 소리는 아닐 것이라는 생각도 들었다.

이번 프로젝트를 통해서 제대로 경험해보고 회사의 서비스에도 적용할 수 있으면 해보는게 베스트!

Server

firebase

프론트에 집중하는 프로젝트라 굳이 서버에 공수를 들일 필요가 없었고

서버리스로 작업할것이기에 firestore로 데이터만 저장하려한다.