다사다난 했던 첫 회사의 3주

 

3주째 다니는 회사인데 코드를 보며 느낀점을 적고 뭘 배웠는지 회고해보자. 역시 사회생활은 쉽지않다. ㅋ 

고민하고 정리하고 싶은 부분은 아래의 주제다.

 

1. SRP 원칙과 리액트 컴포넌트

2. 일정압박 속에서 무엇을 포기할 것인가?

3. 의존성에 관한 이야기

4. 복잡한 문제를 풀어가는 나만의 전략 

 

SRP 원칙과 리액트 컴포넌트

다행이 첫 입사한 회사에 10년차 시니어 외주 개발자분이 있었다. 그래서 코드를 파악할 시간이 주어져서 참 다행이었던 것 같다. 현 프로젝트는 아토믹패턴을 사용하고 page단위로 context-api를 통해 상태를 관리 중이다. 기술이 뭐가 됐든 나는 이 구조가 좀 이해가 안됐던 부분이 있다. 좀 정리를 해보면

[ 문제가 된다고 생각하는 부분 ]

- atomic 패턴을 사용했는데 molecues부터는 interface가 적어 재사용이 쉽지않다. 

- 컴포넌트는 많은데 페이지 단위에서 context-api를 이용하기 때문에 코드의 결합도가 높다.

 

 위 2가지 부분은 애자일방식으로 변화가 잦은 스타트업에서 변화에 취약한 코드를 만들었다. calendar 유지보수를 맡았을 때 놀랐던 점은 컴포넌트의 인터페이스는 없는데 전역 데이터를 사용해서 caledar ui를 만들어서 사용중에 있었고 이 calendar 컴포넌트를 다른 곳에서 사용중에 있었다... (유지보수 사이드이펙트는 감당가능?) 

 

[ 일단은 이렇게 하는 중 ]

 개인적으로 일을 많이 하는거를 좋아하지 않는다. 언제든 유지보수 가능하고 직관적으로 코드가 읽히는게 좋아서 컴포넌트든 뭐든간에 특별한 상황이 아니라면 독립적인 모듈단위로 쪼개서 관리하기 위해서 util함수들을 리팩토링하고 리액트 컴포넌트들도 interface를 두며 의존성을 덜어내고 있다. 하지만 5년간 쌓인 컴파운드 패턴의 코드들을 고작 신입인 내가 처리할 수 있을지 솔직히 모르겠다. 

 

일정압박 속에서 무엇을 포기할 것인가?

validation이 진행됐던 페이지를 유지보수하기 위해 들어갔다. 역시나 모든 상태는 전역으로 관리되고 있었고 손바뀜이 자주 일어나서 전역상태와 지역상태가 엮여있어 개별 ui를 객체로서 생각하면서 개발을 들어갈 수 없었다. 그리고 실력이 부족해서인지 라이브러리들도 커스터밍이 안돼 결국엔 다 뜯어내고 다시만들었다.

 전에 있던 분들은 절대 나보다 못한분이 아니었을 것이다. 아마 시간이 부족했을 거라고 생각한다. data를 다루는 부분을 전역상태로 만들어놓고 control 하는 부분을 한 페이지에서 정의해버리고 ui에 적용만 하는게 더 빠르다고 판단한 것 아닐까? 아니면 실력이 좋아서 ui들을 묶어서 하나로 볼 수 있는 경력자들만에 세계가 있을 수도있겠다 생각이 들었다. (청크단위가 큰 사람들?) 여튼 고민해보자 내 수준에서 뭘 포기하면 안될지를 그리고 뭘 포기할지를

 

1. 독립적인 함수, 컴포넌트는 포기못하겠다. 

2. 리액트 쿼리의 mutation을 안 쓰고 클릭할때마다 fetch하는 거는 못보겠다.

3. 섣부른 추상화는 지양한다. 

4. 아름다운 코드는 포기한다.

 

=> 한 마디로 변화가 쉬운 프로그램을 만들 생각이다. (묶여있을 수록 푸는게 일이다. ㅜㅜ)

 

일단 내수준에서 할 수 있는 점은 interface의 개념모델을 만들어서 조금씩 독립적인 컴포넌트를 만들어갈 생각이다. 크게 컴포넌트의 interface는 [data, 핸들러, 상태]를 갖고 있어야한다고 생각해 넣어줄 생각이다. 

또, util 함수의 재사용성을 높일 생각이다. 가령, url parameter로 isoDate타입의 날짜정보를 받는 경우를 생각해보면 아래처럼... 

// 요거에서
function makeDate(date: string): CompanyDate {}

// 요런방식으로
function convertIsoDateToYearMonthWeek(isoDate: string): YearMonthWeek {}

 

나는 개인적으로 아래의 함수가 여기저기 사용할 수 있다고 생각한다. 물론 못생기긴했지만 알빠노? ㅋ 
함수이름, 파라미터, return(함수시그니처)만 봐도 이해할 수 있는 함수를 만들면 좋은거 아닌가? 내가 왜 함수 속까지 봐야하지?;;

 

프로젝트의 성격과 의존성

이 회사는 손바뀜이 자주 일어난다는 문제점이 있다. 분명 경영상에 문제가 있었기 때문일 것이다. 회사의 불안정성등으로 멘탈이 흔들릴 수 있겠지만 그건 별개의 문제고 프로그래머로서 이런 상황에서 최적의 대응방법이 뭘지 고민해봤다. 

1. 합리적인 일정산정 (정말정말 중요한 것 같다)

2. 여유를 잃지 않아야한다. (코딩 속도도 떨어지고 건강도 나빠진다)

3. 규칙적으로 운동하기 및 회사 의존도 낮추기

회사가 바뀌어 날 책임져줄 수 있지만 코드이력을 볼 때 아마 쉽지않은 이야기일 것 같다. 물론 그렇게 믿고 싶지만 확률상 너무 낮다... 지금 있는 팀원분들과 열심히 코딩하고 현실에서 최선을 다해서 코딩하돼 의존성이 높아지는 것은 막아야 한다.

 

복잡한 문제를 풀어가기 위해 세웠던 전략 및 회고

결국 알고리즘을 푸는 것과 비슷했던 것 같다. 문제상황에 필요한 input과 output data를 먼저 산정하고 그 과정에서 필요한 도메인 지식이 뭔지를 먼저 대충이라도 파악하고 상태관리를 보고 삽질이 일어날 부분을 대충 예상한 뒤 일단 시작했다. 

 

안될 때는 공책에다 flow의 분기점에서 테스트 했던 것들을 손으로 적어가며 불안감에 휩싸여 똑같은 짓을 반복하며 시간을 낭비하는 것을 방지해보려고 노력했다. (하지만 역시나 현실을 개판이다.)

디버깅을 잘하기 위해 git extension도 이용하고, 팀원에게 질문하고 (특히 천사같은 백엔드분), browser extension등 많은 툴을 이용하지만 본질적으로 내 논리력을 향상시키는게 더 중요하다고 생각들었다. 아직 부족하니 디버깅 과정에서 복잡한 수학문제를 풀때 수식을 쓰듯 공책에 정리해가며 덤벼야 겠다.