[첫 직장, 첫 프로젝트 싸이클에서 고민했던 것]
원티드 12월 챌린지 사전 과제를 위한 아주 짧은 요약글은
이쪽
원티드 12월 챌린지 사전 과제 | Built with Notion
비즈니스 로직이 들어간 첫 프로덕트에서 마주한 것들
cheddar-appeal-ee8.notion.site
1. 내가 바랬던 것들의 문제점
내 첫 직장은 스타트업이었다.
지금은 사업이 어려워져서 퇴사한 상태이지만, 취업 당시에 해당 회사를 선택했던 두 가지 큰 이유는
1) 자체 서비스를 가지고 있고, 이미 각 스토어에서 서비스를 하고 있다.
2) 내가 프론트엔드를 처음부터 끝까지 맡아서 팀과 진행해볼 수 있다.
였다.
12월 챌린지에는 짧게 정리했지만 정말 많은 고민과 많은 문제를 마주 했었다.
1)에서 이야기한 서비스는, 입사 당시엔 내가 실물로 본 첫 프로덕트 레벨의 코드였다고 생각했고 수준이 정말 높다고 생각했다.
1개월 쯔음 지났을때 이전 담당자의 코드 구조에 익숙해졌을 즈음엔 그 안에 해결하지 못한 문제들이 조금 많다는 것을 깨달았다.
그 당시에 내가 정의했던 문제들은 다음과 같다.
1. 개발 당시에 요구했던 사항들이 문서화 되어있지 않고, 피그마에 흩뿌려져 있다.
-> 이로 인해 코드에서 시간에 쫒겼다는 느낌을 받았다.
2. 코드에 주석이 달려있지 않다.
-> 1번과 맞물려서 코드의 전반적인 흐름을 따라가는 것이 조금 힘들었다.
3. 코드 & 디렉토리 구조 컨벤션이 없다.
-> 1, 2번과 맞물려서 내가 코드를 추가, 변경할때 흐름을 일관적으로 유지하기 힘들었다.
4. 여기부터는.. 기능적이거나 구조적인 문제라 생략!
A1. 그래서 나는?
내가 결정하고, 지키고자 유지했던 것들은 다음과 같다.
1. 코드를 작성하기 전에, 전체적인 흐름을 설계하자.
-> 예외처리나, 세부 사항에 대한 구현 전에 큰 틀을 그리자.
2. 리액트를 사용하니까, 리액트 답게 코드를 구성해보자.
-> 모임에서 사용했던 구조를 조금 변화시켜서
Screen(Page) -> Viewer(Renderer) | State | API | Function | Custom hook | Interface(type) 로 나누기로 했다.
Page: url endpoint와 매칭되는 상위 컴포넌트
Viewer: data를 받아서, JSX를 리턴하는 컴포넌트
State:
서버 사이드(출처가 backend인 데이터를 위한 상태 ex, user) = react-query(tanstack-query)
클라이언트 사이드(출처가 frontend인 상태 or storage에 write | read 해서 전역으로 써야하는 상태 ex, modal open) = jotai
지역 상태(page에서 사용되고, 소멸되는 상태 ex, userInput, isValid)
API: baseurl - url endpoint를 위한 전역 인스턴스, token을 관리할 인터셉터 = axios
Function: 데이터를 받아, 데이터를 조작하고, 조작된 데이터를 리턴하는 함수
Custom hook: 외부 라이브러리나 react hook과 function을 이용하여 한번 더 추상화한 컴포넌트, page에서 호출해서 사용
Interface(Type): 서버에서 받은 data object나 컴포넌트 프로퍼티로 전달될 오브젝트를 정의한 것
이유?
1) 가장 근본적으로 UI | Control logic 분리 -> Data 구조를 위한 구조체를 분리하고 싶다(MVC) -> View를 위한 Logic이 필요하다. -> MVVM을 하기엔 프로젝트 규모가 그정도는 아니다.
2) 리액트는 Flux패턴이다.
3) 사람이 유지보수하기 편하게 코드를 구성하자.
고민?
1) 컴포넌트 깊이가 깊어지는 것과, 코드의 line이 늘어나는 것 중 어떤 것이 더 가독성에 좋지 못한가?
2) 내가 정한 구조가 타당한가? 리액트스러운가?
3) 3주의 시간을 들여 완전하게 재설계하는 것과 3시간의 임시 방편 중 어떤 것이 옳은 선택인가?
4) 리팩토링을 위한 시간을 확보할 수 있는가?
5) 객관적으로 가독성이 높다는 것은 어떤 것인가?
3. 복잡한 HOC에는 flow, case, return, parameter에 대한 주석을 달자.
[남아있는 것들에 대한 이야기]
1. 원티드 12월 챌린지 - 비즈니스 로직 1주차
1-1)에서 제공한 것
-> 실제로 초반 부에 리액트를 또는 자바스크립트를 배우면서 할 수 있는 대표적인 실수들
(컴포넌트 크게만들어서 의존성 높이기, 컴포넌트 분리하면서 깊이 늘리기 등)을 사례로 공유하면서,
컴포넌트를 분리할때 최소한의 기준인 [데이터 - 액션 - 계산]으로 분리하는 방법과 이유에 대해서 배운다.
순수함수, 사이드 이펙트, 클로저, 옵저버 패턴, 리덕스 이야기는 덤이다.
(덤인데, 꽤나 근본적이고 직관적이게 설명돼있다.)
1-1)에서 느낀 것
내가 일을 하며 코드를 나눌때 가장 고민했던 포인트 중의 하나의 대한 답이 되었다.
개인적으로 분기문에서 함수를 열면
1) 함수 호출 -> 종료 과정에서 인스턴스 생성
1-1) 1로 인한 깊이 증가(다른 파일을 들여다봐야함) - 인간 문제
1-2) 함수 재실행 시 인스턴스 재생성에 대한 비용(히든 클래스, 인라인 캐싱, 단순히 함수 열고 닫는 비용 등) - 기계 문제
이라는 이유들때문에 별로 선호하지 않았는데,
A1) 재사용성이 증가할 수 있다.(테스트 쉬워짐, 내 기준 3회 이상 중복되면 common으로 승격)
A1-1) 이름을 잘 지으면 오히려 명확하게 읽힐 수도 있고, 줄 수 늘어나는게 해석하기 더 어려워 진다.
A1-2) 요즘 엔진 성능 좋고, 리액트나 넥스트 또는 JS라이브러리에 따라 다르겠지만 단순 계산(크지 않다는 전제) 크게 성능적 영향을 끼칠 것 같지 않다.
[넥스트 '앱라우터'의 경우]
- RCC선언된 쪽에서 호출하여 bundle에 포함되어버림 = 최대한 적게 들어낼 수 있게 경계를 나누자
- RCC가 아니라면 번들 제외당해서 서버에서 직렬화해서 날라올 것 = 이미 분리할 수 있는 만큼 분리 된 것인지 재확인
등 프레임워크와 결합하여 사용할 경우를 깊게 생각 해보게 되는 계기가 됐고,
액션(외부에 부수효과) - 계산(인풋 -> 아웃풋의 순수함수)라는 경계선이 그어진 것 같아 만족스러웠다.
1-2)에서 제공한 것
-> 프론트엔드 야근의 원인과 비즈니스 로직에 대한 정의, 개발자로서 성장을 위해 지녀야할 마음가짐
비즈니스 로직과 UI로직의 구분 기준, 마지막으로 둘을 격리하는 방법에 대해 집중한다.
예시를 통해 실재하게 만들 어떤 개념을 추상화하고, 이게 어렵다면 먼저 캡슐화를 통해 모호한 추상적 형태를 구체적인 형태로
가공해 나가는 과정을 공유한다.
단일책임원칙, 컴파운드 컴포넌트 패턴, 추상화.캡슐화|모듈화, 응집도, MVC패턴, 어댑터패턴은 덤이다.
1-2)에서 느낀 것
-> 나는 그동안 추출과 추상화를 혼합해서 개념화해놓았다는 반성을 했다.
내가 작성한 것이니 누구보다 잘 이해를 할 수 있다. 시간이 없다 등의 반성으로 그냥 단순 추출 작업을
추상화라고 합리화한 것은 아닌지 돌아보는 시간을 가질 수 있어 좋았다.
42서울에서, 그리고 '널널한 개발자'님의 강의로 CPP를 학습하며 했던 고민들을 다시 한 번 돌아보는 계기가 됐고,
특히 어댑터 패턴 같은 경우는 나도 모르게 그렇게 쓰고 있다는 것이 기뻤다.
아래는 강의 이후의 한 질문 글에 단 내 답변이다.
그리 대단한 내용은 아니지만, 조금의 도움이라도 됐으면 좋겠다는 생각에서 최대한 풀어쓰려고 해보았는데
다행히 도움이 되었다는 답변이 달려서 굉장히 기분이 좋았다.
2. 원티드 12월 챌린지 - 비즈니스 로직 2주차
2-1)에서 제공한 것
->개발자로서 툴벨트(남들은 아마도 툴박스라고 말하는)것을 만드는 것의 중요성과
대체되거나 사장되거나, 간과하는 기술들이 필요해질 수 있는 순간들을 예시로 도구를 선정하는 기준에 대해서 고민한다.
그리고 solid에 대해, 객체지향에 대해 고민하며 이전 강의에서 배운 개념과 solid의 원칙들을 연결한다.
마지막으로 실제 코드에 적용하는 예시를 통해 그동안 알게 모르게 사용하고 있었던 것들의 존재를 인지하는 시간이다.
그리고 이것은 모두 좋은 구조를 설계하기 위함이다.
SOLID.SRP|OCP|LSP|ISP|DIP, IOC, renderprops는 덤이다.
2-1)에서 느낀 것
-> 꽤 예전부터, 클래스를 배워왔고 스스로 개념화하려고 노력했지만, 사실 객체 지향에 대해서 완전하게 이해하고 있지
못 한 것 같다. 특히 '솔리드'는 계속 보아도 머릿속으로 잘 들어오지 않는 개념이었다.
강의를 보고도 100%이해했다고 하기는 어렵고, 그동안 내가 학습하면서 알게 모르게 습득했던 것과 연결되는 기분이 들어서 조금 신기했다. 분명 경험을 통해 더 마주해보면, 더 매력적인 개발자가 될 수 있을 것 같았다.
Radix나 shadcn, headless ui는 매력적이었다.
2-2)에서 제공한 것
-> 좋은 개발자가 되기 위해서 가져야할 마음가짐, 특히 리액트를 벗어나서 사고하는 방식과 필요성에 대하여 이야기한다.
조금 더 자세하게는, 내가 만들어야할 Product 혹은 Service의 본질(Core)를 분리해내고 React의 본질적인 역할, 그러니까 View로서의 분리해내는 것의 의의에 대해 공부한다.
그리고 이전 세 수업에서 가지고 왔던 개념들과 앞선 개념들을 연결하며 가능성에 대하여 고민한다.
2-2)에서 느낀 것
-> 좋은 구조라는 것에 대해 인지하지 못했던 영역의 가능성을 엿본 느낌이다.
'class는 리액트에서 거의 사용하지 않는 방식이기때문에 낡은 기술'이라는 느낌과
'Type이나 Interface를 Typescript로 강제하면서 결국은 객체의 어떤 형태인 class로 돌아가는 것인가'라는 고민의 답안을 재정의할 수 있었다.
결국 중요한 것은 개발자의 의도이고, 이런 저런 도구(Tool)를 적재적소에 활용하는 것이 개발자의 역할이라는 생각을 했다.
내가 이전에 했던 고민들과 경험들이 완전히 잘못되거나 옳지 못한 것이 아니었다는 것에 대해 안도감을 느끼고,
돌아보았을때 굉장히 귀중한 자산이 될 것이라는 느낌을 받았다.
[마치며]
우선 아직 경력 4개월 언저리의 초짜 개발자가 쓰기에는 조금 무거운 주제일 수 있겠지만, 정말 많은 것을 생각해 볼 수 있는 6개월이었다고 생각한다.
회사가 재정이 어려워지면서 5일전에 갑자기 퇴사를 통보받는다던지, 그동안 이슈를 정리하고 보고했던 노션이 터진다던지 하는 일들이나 12월까지 오면서 있었던 개인적인 일들은 조금 힘들었지만
2년, 3년 뒤의 내가 바라봤을때 분명 의미 있는 시간이었다고 생각할 수 있도록 노력해야한다.
중요한 것은 팬시하고 멋진 기술이 아니라 그 기술을 선택한 이유와 과정이라는 것을 잊지 말아야겠다.
마지막으로 좋은 강의를 제공해주신 원티드와 캡슐단 수장 오종택님 다시 한 번 감사드립니다.