🤔 자사 솔루션 코드 리팩토링

시작하며

리팩토링을 하게 된 이유

처음 자사 솔루션 웹의 기획은 자체 개발한 API를 어떤식으로 사용하는지에 대한 예시 페이지였다. 때문에 확장성을 고려하지 않은 상태로 개발을 시작했는데, 웹 서비스를 상품화 하게 되면서 규모가 커지게 되었다. 그 와중에 급하게 들어오는 기능들이 많아 계속 덧붙이고 덧붙이고 하다보니 코드가 너무 지저분해졌고... 그러다 이대로 둘 수는 없다! 하고 대대적인 개편에 들어갔다.

문제점

• 공통된 코드가 반복되어 사용되고 있다.
• 스크립트를 사용하는 페이지에서 여러개의 js 파일을 개별적으로 불러오고 있다.
• 파일과 함수, 변수명이 직관적이지 않다.
• 데이터를 input으로 관리하고 있어 추가 수정이 번거롭다.
• 동적으로 추가되는 dom의 관리가 비효율적으로 이루어지고 있다.

어떤 부분을 개선했는가.

1. 스크립트 class화

가장 먼저 이 중구난방한 코드들을 묶어서 관리할 필요가 있다고 생각되어, 동일한 기능끼리 (예. 텍스트/워터마크/서명) 그룹화하여 class화를 시켰다.

동일한 기능이 여러곳에서 조금씩 다르게 사용되고 있어, 동일한 부분은 묶고 다른 부분은 옵션값을 주어 제어할 수 있도록 개선했다.

App.js에서 전체 Class를 관리할 수 있도록 하였고, 그 안에서 옵션에 따라 각각의 기능들을 담고있는 Class를 호출하도록 하였다. 각 기능의 데이터 입출력 관리는 Vo에서 하고 있다.

2. 모듈화

1번의 연장선으로, script 태그를 사용하여 불러오던 js 파일들을 모듈화하여 import 방식으로 불러올 수 있도록 했다. 또한 기능들의 사용 여부를 옵션화 하여, 사용하는 기능들만 import 될 수 있도록 하였다.

3. 데이터 저장 방식 변경

기존에는 input hidden으로 데이터를 관리하고 있었는데, 데이터를 추가할 때마다 input을 추가해야 했고, 순서를 바꾸거나 중간 데이터가 삭제될 경우 관련된 input을 모두 수정해야했다.

그래서 object를 사용하여 데이터를 관리할 수 있도록 변경하였고, Vo 파일에서 데이터 입출력을 관리할 수 있도록 개선하였다.

back단으로 데이터를 보낼때는 ajax로 object 형태로 전송하게끔 하였다.

4. ES6 도입

ES6를 도입한 가장 큰 이유는 템플릿 리터럴이다. 동적으로 추가되는 dom이 많아 관리가 불편했는데 템플릿 리터럴을 사용하여 변수등을 사용하는데에 용이해졌고, 소스도 한층 깔끔해졌다.

const/let, Arrow functions등 ES6에 추가된 문법들을 최대한 활용할 수 있도록 하였다.

5. UI 개선

옵션화 시킨 기능들을 용이하게 적용할 수 있도록 UI를 옵션에 따라 블록처럼 조립하여 사용할 수 있도록 변경했다.

마치며

느낀점

항상 마감에 쫓기며 작업을 하다보니 제대로 된 리팩토링을 해본적이 없었는데, 수정할 부분이 엄청 많았고 기대했던 것 보다 훨씬 많이 개선 된 것 같아 만족스러웠다.

Class 구조를 처음부터 설계하여 사용해본 것은 처음이었는데, 직접 사용해보니 그동안 막막하게 생각했던 class라는 개념이 조금씩 자리잡힌 것 같다.

리팩토링 이후

front 리팩토링을 얼추 마무리하고 있었는데 기획이 변경되면서 back단까지 그러니까 지금까지 개발했던 것들을 싹 다 갈아 엎어야 되게 생겼다... (이게 무슨 날벼락이오😯)

눈물나지만... 슬프지만... 지금까지 리팩토링 하면서 배운것들은 사라지지 않을테니 처음부터 다시하면 지금보다 더 좋은 코드가 나올 수 있겠지? 🥲

개발은 엎고 또 엎고 또 다시하고의 연속인 것 같다. 최근 읽은 책에서 엎고 수정하고 또 수정하다가 최초의 것이 없어져야 완성이라는 글을 본 것 같은데 그게 맞는 것 같다. 아좌아좌개발자..!

여담

늘 글로 정리해봐야지 하고 생각만 하다가, 막상 쓰려고 하면 막막해져서 몇자 쓰고 포기해 버렸었는데 깊게 고민하지 않고 생각나는데로 쭉 써내려가니까 쓰면서 정리도 되고 생각보다 재밌는 것 같다. 앞으로도 종종 써볼 수 있도록 해봐야지!