[ je 개발 일지 ] 121 - 122 일차, "내가 타입 스크립트 없이 개발하기 싫어진 이유"

---

[ 오늘의 TODO & DONE ]

1. 개인 공부) 자바 / 스프링 학습 
   - 강의 들으면서 미니 프로젝트 진행중
   https://github.com/Je-chan/spring-mini-project-dmaker 
2. 독서) 리팩터링 읽기
   - 4-1 자가 테스트 코드의 가치
   - 4-2 테스트할 샘플 코드
   - 4-3 첫 번째 테스트
   - 4-4 테스트 추가하기
   - 4-5 픽스처 수정하기
   - 4-6 경계 조건 검사하기
   - 4-7 끝나지 않은 여정
   - 5-1 리팩터링 설명 형식
   - 5-2 리팩터링 기법 선정 기준
3. 생활) 물 1L 이상 마시기
4. 생활) 최소 30분은 운동하기
   - 운동할 시간 있으면 스프링을 한 번 더 봐라 (급하다)

GitHub - Je-chan/spring-mini-project-dmaker

---

[ 오늘의 회고 ]

1. 타입 스크립트의 재미

  처음 실무에 투입해서 도메인을 만들 때 사수가 타입 스크립트로 만들 것을 권장했지만 나는 자바 스크립트로 하고 싶다고 방어전을 펼쳤었다. 그랬던 이유는 두 가지다. 첫 번째로, 내가 처음 실무로 만드는 도메인이고, 당장 기능 구현에 급급한데 아직 익숙하지 않은 Vue3 와 더 익숙하지 않은 Pinia 상태 관리만으로도 벅찼기 때문이다. 내가 타입 스크립트를 미리 공부한 것도 아니고 실무에 적용하면서 배우고 있는 건데 과연 내가 기한 안에 도메인을 만들 수 있을까 라는 걱정이 앞섰다. 두 번째로, 타입 스크립트로 하지 않았을 때에도 결국 기능 구현은 하기 때문이다. 타입 스크립트를 사용하면 굳이 마주하지 않아도 되는 에러들을 마주하는 느낌이 계속 들었다. 그리고, 알고 있는 건데 굳이 한 번 더 쓰는 느낌이 없지 않아 들었다. 당연히 이 함수에는 파라미터가 이렇게 들어 가야지 라는 생각을 하면서 작성을 하는데 그걸 굳이 하나하나 작성한다는 게 시간 아깝다고 생각했었다.

 

  그런데 이제는 완전 달라졌다. 오늘 다른 팀 프엔 개발자와 얘기하면서 느낀 거지만, 나는 이제 타입스크립트 없이는 못사는 몸이 되어버렸다...! 

 

  내가 이렇게 타입 스크립트에 열광적이게 된 이유는 세 가지 정도로 나눠볼 수 있을 것 같다(다른 사람들이 다 얘기하는 타입 스크립트에 대한 장점들은 당연히 느끼고 있지만 진부하니까 그런 것들은 좀 빼고 내가 직접 실무에 적용하면서 느낀 점을 위주로 뽑으면 세 가지가 된다.)

 

  첫 번째로, 데이터 흐름 파악이 쉬워졌다. 내가 타입을 지정하는 순서는 일단 API 명세서를 바탕으로 Response 로 받는 값과 내가 Params 로 넘겨야할 값들을 타입으로 먼저 지정한다. 솔직히, 여기서 타입을 적용하다 보면 앞으로 내가 이 데이터들을 어떻게 사용해야겠구나 감이 온다. 그리고 여기에서 추가적으로 내가 Store 에 저장할 타입(혹은 비즈니스 로직에서 사용할 타입), 컴포넌트에 넘겨줄 타입 들을 지정만 하면 지금 데이터가 어떻게 내 코드 내에서 흘러가는 지를 빠르게 캐치할 수 있다. 이렇게 되면 뭐가 좋으냐. 개인적으로는 함수형 프로그래밍으로 코드 짜기 편해졌다. 딱 필요한 만큼의 데이터만을 흐르게 하고, 전역 변수 사용 등을 막으면서 사이드 이펙트가 발생하지 않는 순수 함수들을 작성하는데 타입이 큰 역할을 해주었다.

 

  두 번째로, 내가 Params 로 뭘 넣어야 했더라 생각하지 않아도 된다.  이게 정말 생산성을 많이 높여주는 거 같다. 미리 Params 로 어떻게 받아야 하는지를 설정해주고 있기 때문에 나중에 내가 그 함수를 사용할 때, 그냥 마우스 갖다 대기만 하면 Parmas 뭘 써야 하는지, 어떤 타입의 것들만 들어가야 하는지를 보여준다. 그렇다 보니 굳이 컨트롤과 마우스 클릭을 사용해 가면서 내가 뭘 넣어야 했더라 타고 들어가지 않아도 된다. 그것만으로도 생산성이 극대화 되는 거 같다. 여기에 조금 더 진부한 말을 더 붙이자면, 타입들을 통해서 미리 에러들을 발생시켜 주니까 과거의 내가 현재 혹은 미래의 나에게 "제발 그러지마..." 라는 시그널을 보내주는 거 같다. 물론, 이 생산성이 타입을 작성하는 시간과 비교했을 때 얼만큼 효율적인지, 혹은 비효율적이지는 않은지 정확한 수치를 내기는 어렵다만은, 적어도 타입을 작성하는 시간 보다 비즈니스 로직을 짜는 시간이 더 길 것이고, 그 긴 시간 동안에 타입을 통해 도움을 받는 것 덕분에 덜 스트레스를 받는다면, 그것만으로도 굉장한 효율이라고 생각한다.

 

  마지막 세 번째로, 이거는 솔직히 타입 스크립트의 장점이라고 보기 어렵지만, 만약 여러분이 혹은 여러분의 회사가 Jet Brains 의 Webstorm 을 쓴다면... 타입 스크립트 안 쓰는 당신이 바보다. (...자세한 설명은 생략한다)

 

  이제와서 생각해보면, 사수가 정말 좋은 조언을 해준 것 같다. 그리고, 뭐든 코드를 작성하면서 빨리 배우는 거 같다. 처음에 타입 스크립트 공부할 때는 이게 뭔 소리야, 이게 왜 필요해 하면서 웬만하면 안 쓰려고 기피했었지만 지금에 와서는 타입 스크립트 없이는 개발하기 싫다고 말하는 정도까지 왔으니 할 말 다 한 거 같다. 

 

  ...실무 백엔드 코드를 만지고 익숙해지다 보면 나도 자바가 Node.js 보다 좋더라.. 라고 말할 수 있으려나... (그전에 자바 스프링에 정말로 익숙해질 수는 있는 걸까)