[import-visualizer] 10. 개발 회고

최종 배포 주소는 아래와 같다.

import-visualizer - npm (npmjs.com)

import-visualizer

HBSPS/import-visualizer: A library that allows you to visualize the hierarchy of imports in esm. (github.com)

GitHub - HBSPS/import-visualizer: A library that allows you to visualize the hierarchy of imports in esm.

회고

이 프로젝트는 단순히 AST를 활용할 수 있는 방법이 어떤 것이 있을까에 대한 고민으로 시작했다.

 

또한, 프로젝트를 진행하면서 IDE을 계속해서 탐색해야 하는 번거로움을 덜고 프로젝트 구조를 한 눈에 볼 수 있다면 개발하는 과정에서 더 생산성이 높아질 것이라 생각해서 시작하게 되었다.

 

이 과정에서 어떤 자료구조를 택하고 왜 그렇게 택했는지, 어떤 어려움이 있었고 어떻게 해결할 수 있었는지에 관한 내용들을 글로 남길 수 있었다.

 

이 라이브러리를 만들면서 NodeJS의 path 모듈과 fs 모듈을 자주 사용해볼 수 있었다.

 

이를 통해 경로에 관해서 어떤 문제가 발생할 수 있으며 각 모듈의 메소드는 어떤 것이 있는지 알 수 있었다.

 

또한, 잘못된 판단으로 프로젝트의 진행이 더뎌졌던 것 같다.

 

스택 오버플로우를 생각은 했지만 혹시나 하는 마음에 그냥 진행했던것이 결국 돌아와서 마지막에 수정을 했어야 했다.

 

다른 방법을 사용했더라면 미리 피할 수 있지 않았을까 하는 아쉬움이 있다.

 

이 프로젝트를 하면서 타입 스크립트의 중요성과 테스트 코드의 중요성을 다시 한 번 느꼈다.

 

불편한 과정 없고 빠른 속도로 개발을 하고자 JS를 사용했었지만 결국 어떤 함수에 상대경로가 들어가고 어떤 함수에 절대경로가 들어가는지 스스로 기억하고 있기 어려웠다.

 

만약 TS를 미리 사용했더라면 타입 별칭을 미리 적용해 더 빠르게 개발할 수 있었을 것 같은 아쉬움이 남는다.

 

테스트 코드 또한 리팩토링 과정에 도입을 했다.

 

리팩토링을 하며 발생할 수 있는 잠재적 오류에 대응하기 위함이었다.

 

테스트 코드를 통해 리팩토링을 수월하게 할 수 있었다.

 

한 가지 아쉬움이 남는다면 테스트 코드를 작성 시기가 조금 늦은 감이 없잖아 있다.

 

함수를 하나 만들고 바로 테스트 코드를 작성했다면 더 빠른 주기로 리팩토링을 할 수 있었을 것 같다.

 

중간에 테스트 코드를 작성하긴 했지만 함수가 해야 할 일을 테스트 코드로 미리 작성해두고 이에 맞춰서 함수를 작성하거나 수정한 경우도 있었기에 TDD도 어느정도 경험해본 것 같다.

 

리팩토링 과정에서 (상대경로 방식에서 절대경로 방식으로 바꾸는 과정) 미리 절대경로 방식의 테스트 코드를 작성해두고 이 테스트가 통과되지 않는 부분을 찾아 수정할 수 있었다.

 

이 과정을 통해 왜 우리가 TS와 테스트코드를 작성하는지 다시 한 번 깨닫게 되었다.

 

물론 귀찮은 작업이 될 수 있고 반복적인 작업이라 지루할 수 있다고 생각한다.

 

그렇지만 이것들을 미루게 된다면 결국 나중에는 더 귀찮고 지루한 일을 경험할 수 있음을 알게 되었다.

 

이 라이브러리에는 아직 지원되지 않는 기능들이 있다.

 

우선, 모노레포와 같이 다수의 tsconfig들이 존재하는 등의 방식에는 사용할 수 없다.

 

기회가 된다면 (사용자가 많아지고 이 프로젝트에 대한 책임이 점점더 커지게 된다면 + 시간이 있다면) 꼭 그 기능을 업데이트 해보고 싶다.

 

AST를 연습하기 위한 프로젝트였지만 배보다 배꼽이 더 커져 path와 fs를 더 많이 사용한 것 같다.

 

경로를 다루는 것은 쉬운듯 어렵다는 것을 깨닫게 되었다.