Search
8️⃣

코드 수정 및 복잡도 개선(내부 모듈)

내부 모듈에 메서드를 리팩토링을 시작한 이유 현 프로젝트는 라이브러리 또는 모듈을 만드는 작업이다. 그만큼 사용자들이 많이 사용하고, 개선점을 알려줘야 모듈이 발전할 수 있다. 이 때문에 이슈가 발생하면 쉽게 수정하고, 쉽게 변경할 수 있어야 한다. 그래서 내부 모듈에 대한 메서드를 리팩토링 했다.
- 개선 시 사용한 도구
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