javascript

Builder를 위한 Path parser 구현 후기

하리하링웹 2024. 1. 9. 21:12

최근 회사에서 특정 파일 경로를 입력받아, 그 경로와 관련된 파일들의 경로를 의존성에 따라 배열로 반환하는 코드를 개발하는 Job을 받았다. 

 

이 과정에서 Input 값으로 2가지의 정보를 받을 수 있었는데 이는 아래와 같다.

1. 파일 경로

2. parse 옵션(isProduction, isForce)

 

 그리고 회사 repo의 각 project안에는 project의 의존성 관계를 인터페이스화하여 알려주는 .json파일이 platform 별로 @개 만큼 있는 구조였으며 이를 옵션, 의존성, project의 구조별로 잘 조합하여 효과적으로 그리고 문제가 없도록 파싱하는것이 가장 중요한 목표였다.

 

처음에는 경로를 받아 절차지향형 방식으로 개발을 진행하였다. 어찌저찌 문제없이 돌아가도록 완성은 시켰지만 앞으로의 유지보수 가능성이 매우 낮다고 판단되었으며 다시 만들기로 결심하게 되었다.

 

 회사의 repo 구조는 하나의 큰 monorepo 안에서 여러개의 프로젝트들이 있는 구조이며 각각의 project안에는 플랫폼이 있어 여러개의 구조가 존재할 수 있었다 또한 각 프로젝트의 구조 역시 다르게 되어있었다.

 또한 앞으로 프로젝트가 추가되거나 안의 파일 구조가 변경될 가능성도 있으며 옵션에 따른 파싱 방법 역시 다르게 해줘야했었다. 따라서 이를 기존의 방식으로 개발하고자 했을때에 너무 많은 예외사항 코드가 필요하였으며 앞으로 더욱 많아질것이 뻔했기 때문에 기존 코드는 사용할 수 없다는 판단이 내려졌다.

 

어떻게 해야할지 고민하고 있는 와중에 객체지향의 오해와 진실이라는 책을 추천받아 이를 읽고 이것을 기반으로 다시 코드를 작성하였다.

 

주말중에 책의 내용을 따라 구조를 간단하게 구상하였으며 출근하자마자 이를 코드로 옮기게 되었다.

 

먼저 내부의 핵심 로직을 크게 2개로 나누어 각각에게 책임을 부여해주었다.

 

createTargetBuilder라는 함수는 단순하게 경로를 받아 compile에 필요한 target 정보를 반환 해주는 책임을 가지고 있으며

compileTarget은 단순하게 빌드에 필요한 target 정보를 받아 빌드에 필요한 파일 경로 리스트를 반환해주는 책임을 가지고 있다.

 

이렇게 크게 2가지로 나눈 뒤 각각의 함수 내부에서 사용할 객체를 추상화 해주었다. 

 

각각의 객체에서 공통적으로 필요한 부분, "예를들면 compileTarget 함수가 사용하는 객체는 마지막에 반드시 경로가 유효한지를 체크해줘야 한다." 와 같은 공통 method를 정의하였으며 이렇게 크게 2개의 추상화 객체가 나오게 되었다.

 

이후는 간단했다. 각 프로젝트별로 객체를 만들어 주기만 하면 그만이였다.

 

물론 사이사이에 path를 핸들링하는 유틸리티 class등을 만들어 주고 파일 시스템 관련 유틸도 만들었지만 이런건 단순히 유틸일 뿐이였다.

 

각 프로젝트별 객체는 문제가 생기더라도 해당 객체에서만 문제가 발생했기에 수정이 매우 쉬웠으며 복잡한 로직이라도 하나의 책임에 대한 목표를 가지고 개발을 하였기에 문제없이 개발할 수 있었다. 또한 앞으로 새 프로젝트가 추가되더라도 해당 프로젝트에 맞는 객체를 만들면 그만이였다.

 

여기에 앞으로 git 기반으로 파일의 변경점을 찾아 알아서 실행시켜주는 로직, error를 관리해주는 로직 등 여러가지 로직이 추가될텐데 이 역시도 책임을 기반으로 만들어논 main 안에 각각의 책임을 가지고 동작하도록 추가만 해주면 그만이였다.

 

물론 어디까지나 알파단계에도 못미치는 초기 단계이며 builder라는 큰 목표에 있어 path를 parse 해주는 모듈은 아주 작은 부분이지만 어느정도 유의미한 성과를 거둘수 있었으며 기반을 잘 잡으려고 시간을 많이 들였기에 앞으로 위에서 언급한 몇가지의 기능이 추가되더라도 무리없이 추가할 수 있을 것 같다는 생각을 하였다.

 

최근 프론트엔드를 많이 내려놓으면서 아키텍쳐에 관심이 많은데 아무리 객체지향, 절차지향, 선언형 등 여러가지의 패턴이 있더라도 이는 결국 개념적인 부분일 뿐 결국 현재 상황에 맞는 방식을 선택해서 개발하는게 정말 중요한 것 같다는 생각이 들었다.

 

코드가 있어야할 위치에 잘 있으며 알아보기 쉽고 확장하기 쉬운 구조로 되어있는 코드가 결국 좋은 아키텍쳐가 아닐까 라는 생각을 하며 앞으로 이러한 방향으로 더욱 공부를 열심히 좋은 코드를 만들어내는 개발자가 되기위해 더욱 열심히 할것이다.