내부 모듈에 메서드를 리팩토링을 시작한 이유
현 프로젝트는 라이브러리 또는 모듈을 만드는 작업이다. 그만큼 사용자들이 많이 사용하고, 개선점을 알려줘야 모듈이 발전할 수 있다. 이 때문에 이슈가 발생하면 쉽게 수정하고, 쉽게 변경할 수 있어야 한다.
그래서 내부 모듈에 대한 메서드를 리팩토링 했다.
- 개선 시 사용한 도구
SonarLint - 코드 정적 분석 도구
Code Metrics - 코드 순환 복잡성 GUI 툴
- 개선 기준
재사용 및 비슷한 성격의 메서드는 호출 순서를 일반화
스트림 파이프라인 활용
10을 초과하는 메서드 항목 리팩토링 - (기준은 명확하지 않음 하지만 10~15 사이는 양호)
- 개선 내용
ExcelCell 부분 삭제 → CellUtils로 변경
기존 Cell 단위의 작업을 위하여 ExcelCell이라는 클래스를 래핑해서 사용했다.
하지만 이 부분이 메서드를 복잡하게 만들고 수정이 어렵게 한다.
그래서 이 부분을 Util Class로 변경하고, 스프레드시트 구조를 만들어주는 메서드에서 호출해서 사용하도록 변경
제어흐름이 명확하지 않았던 부분을 스트림 파이프라인을 이용하여 구조 개선
개선 전 복잡도가 높았던 부분은 공개되는 메서드 중 1~3까지, 내부에서 호출해서 사용하는 메서드는 4가 있었다.
개선 전 클래스 복잡도 22
개선 이후 클래스 복잡도 11
1. public <T> List<T> sheetToModel(Class<T> clazz) - 매핑
개선 전 복잡도 11
2. public <T> void modelToSheet(List<T> list) - 매핑
개선 전 복잡도 13
3. public void multiModelToSheet(Predicate<String> excludedHeader, List<?>... multiModelArray) - 매핑
개선 전 복잡도 19
4. private List<ColumnFrame> findHeaderIndex(List<ColumnFrame> columnFrames) - 특정 헤더 찾기
개선 전 복잡도 19
추가 내용
code 수정 ClassModelRegistrator
code 수정 ClassModel