비즈니스 로직이 들어간 첫 프로덕트에서 마주한 것들

Configuration

• Flow Chart → 프로덕트 디자인이 있었음에도, 큰 청사진을 잡는 것은 쉽지 않았다. 생각보다 디자인은 널널하고, 불친절하고, 플로우를 확인하기 쉽지 않았다. 내가 생각했던 것 보다 디자이너가 해줘야할 일들이 많았고, 내가 생각했던 것 보다 기획이 해줘야할 일들이 많았다. 처음에 그린 설계와 마지막 완성본은 굉장히 달랐다.
• ESLint, tsconfig, viteConfig → config파일들이 많은 것은 알고 있었지만, 가장 충격적이면서도 어쩌면 당연했던 것은 내가 생각했던 것보다 세세하게 의존관계, 예약어, 경로 설정을 해줘야했다는 것이다. 첫 날에 프로젝트를 생성하면서 내가 생각보다 더 많은 것들을 모를 수 있겠구나 생각했었다.
• .env → 매우 몇번을 강조해도 지나치지 않게 중요한 부분이다. 업로드 방지는 기본이고, API 또는 ClientKey를 잘 확인해야한다. 그럴 경우가 매우 적 긴 하지만, 네이티브와 함께 Web URL로 서버를 접근하는 웹뷰 방식은 특히 더 그렇다. 잘못하면, 실제 프로덕트에서 유저가 Dev Server의 자료를 볼 수 있다. 금요일 저녁 6시에, ‘이거 어떡해요, 도와주세요’라는 동료분의 톡은 살면서 받아본 것 중에 손에 꼽는 느낌이었다.

Library, Solution

• 리소스 → 열어보면 같은 비슷하거나 같은 기능을 하는 무료 | 유료 라이브러리가 있다. 유료의 비용 부과 시점도 다르고 이에따라 유지비용도 확확 차이가 난다. 생각보다 많이 차이난다.

문서화가 잘 돼있어야한다. stackoverflow, YouTube, google에서 내가 원하는 접근, 형태, 로직을 찾는 것은 생각보다 쉽지 않았다. ex) Library의 객체가 반환하는 object와 실제의 object의 프로퍼티가 다르다던지, 만들어진 그래프 object에 style을 새로 입힌다던지 등등

• customize → 위의 마지막 예제처럼, 그래프를 그리는 라이브러리를 가져와서 사용했는데 당연히 내 실력부족이겠지만, 달력을 만드는 라이브러리의 색을 회사 고유 색으로 입히거나, 그래프의 축 값들을 원하는 데이터로 변경하는데 디자인을 변경해야한다거나, Object ID값을 확인해서 DOM Element 생성 | 변경을 방지한다거나 하는 일들을 하는 메서드를 만들 때 문서에 관련 정보가 없다면 실제 코드를 열어서 따라가면서 추가해야한다.

Component

• 가독성 → 대원칙 - 친구의 조언에 따라 3회 이상 같은 기능을 하는 코드가 있다면 분리하자. 그러다보면, 고민하게 된다. 같은 동작을 하는 하위 Component인데 받는 인자나 실제로 반환해야하는 Data가 다르다면? 이 말부터가 이상하지만 실제로 꽤 많은 비슷한 고민을 겪었다.

이를 해결하기 위해 로직 | UI | Type을 나누었는데, 로직 안에서 다른 컴포넌트의 function을 부르는게 맞나? 아니면 function을 중복되더라도 새롭게 파는 것이 맞나? → 정답은 이미 잘 알고 있는 분들이 많으시겠지만 공용으로 분리해야한다. 문제는 이제 모듈을 보는 시점과 상태관리가 더해진다는 건데.. 이것은 아래에 상태관리에 더 적어야겠다.

의존을 줄이다보면 깊이가 깊어지게 되고, 깊이가 깊어지면 가독성이 떨어진다. 지금도 늘 고민하는 주제다. 어디까지 분리돼있어야 좋은 코드일까?

• 타입스크립트 → 이번 프로젝트에서 타입스크립트를 처음 제대로 써봤다. 그래서 인자 구분시에 지금에서야 <T>를 이용하겠지만, 이전엔 Key나 Flag를 사용해서 구분했다. stringliteral은 꽤 매력적이다. 브라우저 엔진이 좋아져서, 자바스크립트 형추론에 대한 비용이 아무리 적어졌다고 한들 형을 강제하는 것은 좋은 비용 감소라고 생각한다. 그렇지만, 나는 여전히 OOP를 잘 이해하지 못한다. 자바스크립트에서의 OOP는 더욱 그렇다. 그래서 Interface나 type을 만들어내는게 참 좋지만 늘 어렵다. 프로퍼티의 작명은 특히….더그렇다.

상태관리

• 시점 → 예를 들어보자, 사용자가 어떤 창에 들어와서 달력을 클릭해서 달력을 열고, 달력의 날짜를 변경했다. 그리고 확인을 눌렀다. 그 이후에 변경하고 싶어, 달력을 열었다. 이때 보여지는 날짜는 당연히 유저가 선택한 날짜다. 그 이후에 유저가 달력의 날짜를 변경했다가. 마음이 변해 취소버튼을 눌러 달력을 닫았다. 그럼 달력은 유저가 아까 열었던 날짜로 다시 돌아가야한다.

여기에 기획의 요구가 들어간다. ”최초 오픈에는 오늘로 보여졌으면 좋겠어요.” ”수정때는 지난 일정이면 무조건 최초의 일정일 시작부터 보여졌으면 좋겠어요.” ”그리고 이 일정에 따라 유동적인 그래프가 있으면 좋겠네요.” ”아, 그래프에 y축 값을 카테고리 별로 볼 수 있었으면 좋겠어요.” ”달력은 기간으로 선택할 수 있는게 있고, 일별로 선택할 수 있으면 좋겠어요”

그리고 나는 그 달력 안의 Period를 가져와 달력에도 그리고, 달력의 상위 컴포넌트에 Period에도 표기를 해줘야하고, 그래프도 그려야한다. 그리고 날짜 변경때마다 그래프는 변해야한다.

나는 어떻게 상태를 관리하고, 컴포넌트를 나누어야할까?

이처럼 로직과 상태관리 시점이 혼합되어 버리는 경우가 꽤 많았다. 특히 꼭 개별로 만들고나서…

중요했던 것은 데이터가 관측되는 시점과 변경되는 시점을 명확히 분리해주고, 가능성을 정리하는 것이었다. → ex: 달력이 열림 : data가 있? A : B. A라면 originData를 useMemo로 고정하고 내부에 변경되는 Data를 위한 상태를 따로 관리 → 취소 or 확인에따라 데이터 반환 B라면면 초기 값을 가지고 상태 관리 블라블라

• 개인적인 선호 - React Query → 이전 프로젝트에서의 상태관리 사용을 위해 redux와 reduxtoolkit을 공부했었는데, 리덕스에서 리덕스 툴킷으로 넘어가면서 신세계를 경험했던 것의 배 정도되는 충격을 React Query를 쓰면서 경험했다.

당연한 장단점이 있지만, 내가 제일 크게 공감한 장점은 다음과 같다.

장점

1. Slice를 만들지 않아도 된다.
2. Data의 중복, 유효성, 신선함을 쉽게 관리할 수 있다.
3. dataFetch → try-catch → wrapping → data → data edit로 이어지는 플로우가 간결해질 수 있다. 3-1. data fetching을 위한 try-catch 보일러 플레이트, 인스턴스 등을 안 만들어 줘도 된다!!!
4. 왜 data fetching과 HTTP Method, REST API를 위한 상태관리라고 말하는지 이해할 수 있다.

단점

1. Data의 흐름이 개별적이다.
2. slice가 없는 만큼 interface가 많아진다.

이 외의 것들..