오픈빌더 리펙토링

리펙토링을 시작하게 된 이유

리펙토링은 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업이다. 개발을 하다보면 자주 함수나 클래스를 리펙토링 하게 되는 데, 이번에는 프로젝트 전체를 리펙토링 하려고 한다.

코드들이 수정하기 용이하지 않고, 오픈소스의 변경이 용이하지 않는 날이 오게되면 프로젝트는 갈아 엎어야 되는 지경이 온다. 오픈빌더 코드가 몇년이 지나도 수정이 용이하고 오픈소스의 버전업과 마이그레이션이 용이한 구조를 구성해서 롱런하는 프로젝트로 만드는 게 목표이다.

리펙토링 과정

첫번째는 미사용 코드를 삭제하는 것이다. 미사용 코드의 종류는 아래와 같은 코드들이 있었다.

• 코드를 주석 처리해서 사용하지 않는 코드
• IDE에서 Unused method/field/specifier로 표시해주는 코드

이런 미사용코드들이 생기는 이유는 나중에 사용하려고 하거나 스펙아웃된 코드들이 잔류한 코드이다. LOC를 측정해보니 10%정도(38241 => 34022)가 미사용코드였다.

두번째는 외부라이브러리에 결합도가 강한코드들을 정리했다. 많은 파일들에 의존성이 생기면 나중에 수정하기 힘들뿐더러 중복코드 발생되기 때문이다. 해결방법은 외부라이브러리의 진입점을 서비스를 통해하도록했다.

예를들어 MatSnackBar은 this.snackBar.open(Component, null, {duration: 3000})과 같은 형태를 가진다. 여기서 두번째와 세번째 인자는 모든 파일에 동일한 옵션으로 사용하고 있다. 인자순서, 옵션형태, 옵션값의 변경이 필요하면 무수히 많은 파일들(현재 58개 파일에서 사용중)을 수정하려면 쉽게 수정이 불가능할것이다.

세번째는 역할이 2개이상 정의된 파일들을 정리한다. 여기서 말하는 역할은 Class와 Interface로 정의된 사용자형을 이야기한다. 사용자형이 한 파일에 2개이상 정의되었다는 것은 응집도이 낮다는 이야기다.

네번째는 라인의 길이가 긴 메소드를 정리한다. 긴 메소드는 일반적으로 행위가 두개 이상이 정의될 가능성이 크다. 아래와 같이 정리했다.

• 수동루프 -> 함수(map, filter, reduce)

다섯번째는 단방향 데이터 흐름을 만드는 것이다. 현재는 컴포넌트에 상태/뮤테이션/액션들의 모두 정의되어 있고, 서비스는 API 서버와 통신하는 역할만 한다. 컴포넌트는 뷰를 담당하기 때문에 변경이 자주일어나고 뷰의 액션과 데이터를 전달하는 역할만해도 충분하다고 생각한다.

그래서 서비스에 상태/뮤테이션/액션들을 정의하고 컴포넌트는 서비스에 상태/액션을 요청하는 것으로 수정한다.