리팩토링을 하는 이유는 무엇일까?
요약
- 리팩토링은 왜 수행하나요?
리팩토링은 프로젝트에서 존재하는 코드 스멜을 식별하고 이를 개선하여 유지보수성을 향상시키는 작업입니다. 유지보수성을 향상함으로써 제품이나 시스템을 개선하거나 환경, 요구사항이 변화할 때 더 쉽게 대응할 수 있도록 만듭니다.
- 스멜은 무엇인가요?
스멜은 마틴 파울러의 “Refactoring” 저서에서 소개된 개념으로 리팩토링이 필요할 수 있는 부분을 의미합니다. 이렇게 유지보수성이 떨어지는 여러 상황들을 스멜로 패턴화하고 이에 맞는 리팩토링 방법을 소개함으로써 개발자들이 쉽게 리팩토링할 수 있습니다.
서론
프로젝트를 할 때 프로젝트 리팩토링을 한다는 말을 많이 들어보았을 것이다. 이전에는 리팩토링은 메서드 추출, 가독성 있는 변수명 등 만이 전부라고 생각하였으나 수업을 듣고 다양한 방법들을 알게 되어 이를 정리해보았다. 이번 포스트에서는 리팩토링을 하는 이유와 관련 개념에 대해 간단하게 정리할 예정이다.
리팩토링이란?
결론부터 말하자면 리팩토링은 품질 요구사항 중 유지보수성을 개선하기 위한 작업이다. 기능 요구사항의 변경은 리팩토링에서 수행하지 않기 때문에 기능을 변경하는 작업은 리팩토링의 수행 범위 밖이다. 이렇게 기능 요구사항이 변경되지 않기 때문에 리팩토링 이전과 이후 동일한 기능을 수행하는지 파악하기 위해 테스트 코드를 작성하는 것이다. 또한 성능, 버그 수정과 관련한 요소도 리팩토링의 주요 관심사는 아니다.
유지보수성(Maintainability)
유지보수하기 좋은 소프트웨어는 무엇일까? 이에 대한 의견은 조금씩 다를 수 있을 것이다. 이렇게 다른 의견으로 발생하는 혼란을 줄이기 위해 국제 표준화 기구(ISO)에서는 소프트웨어 품질에 대한 표준 지침을 만들었다. ISO/IEC 25010:2011에서 8가지 품질 특성을 정의했는데 이 중 유지보수성에 대한 정의는 다음과 같다.
ISO/IEC 25010에서 유지보수성
유지보수성은 제품이나 시스템을 개선하거나 환경, 요구사항의 변화에 수정할 수 있는 효율의 정도를 나타낸다. 이 특성은 다음과 같은 하위 특성으로 구성되어 있다.
특성 | 설명 |
---|---|
Modularity | 시스템, 컴퓨터 프로그램이 하나의 구성 요소에 대한 변경이 다른 구성 요소에 미치는 영향을 최소화하도록 개별 요소로 구성된 정도 |
Reusability | 구성 요소를 하나 이상의 시스템에서 에셋(asset)으로 사용하거나 다른 에셋을 만들 때 사용할 수 있는 정도 |
Analysability | 하나 이상 구성 요소를 변경하였을 때 제품이나 시스템에 대한 영향을 평가할 수 있는 정도, 제품의 결함 또는 고장 원인을 진단하거나 수정할 구성 요소를 식별할 수 있는 효율의 정도 |
Modifiability | 결함이 발생하거나 기존의 제품 품질을 저하시키지 않으면서 제품이나 시스템을 효과적이고 효율적으로 수정할 수 있는 정도 |
Testability | 시스템, 제품 또는 구성 요소에 대한 테스트 기준을 설정하고 테스트를 수행하여 해당 기준을 충족했는지 여부를 효과적이고 효율적으로 확인할 수 있는 정도 |
이러한 유지보수성에 대한 정의를 바탕으로 리팩토링의 목표를 짐작할 수 있다. 리팩토링은 기존 코드에서 모듈화, 재사용성, 분석성, 수정용이성, 테스트용이성을 중심으로 수정하여 제품을 개선하거나 요구사항이 변화할 때 더 쉽게 수정할 수 있도록 하는 작업이다.
베드 스멜(Bad Smell)
이제 리팩토링을 하는 이유에 대해서는 알았다. 그러면 어떠한 부분이 유지보수성이 떨어지는 코드인지 확인하고 리팩토링을 할 수 있을까? 마틴 파울러(Martin Fowler)의 Refactoring 저서에서 유지보수성이 떨어져 리팩토링이 필요한 대표적인 패턴들을 베드 스멜로 정의하였다. 아래는 베드 스멜을 카테고리로 분류한 표이다.
카테고리 | 설명 | 베드 스멜 예시 |
---|---|---|
Bloater | 효과적으로 동작할 수 없을 정도로 커진 경우 | Long Method, Large Class, Primitive Obsession, Long Parameter List, Data Clumps |
Object-Orientation Abusers | 객체 지향 개념이 잘못 적용된 경우 | Switch Statements, Temporary Field, Refused Bequest, Alternative Classes with Different Interfaces |
Change Preventers | 소프트웨어의 추가적인 개발, 변경을 방해하는 경우 | Divergent Change, Shotgun Surgery, Parallel Inheritance Hierachies |
Dispensables | 소스코드에서 제거해도 되는 불필요한 경우 | Lazy Class, Data Class, Duplicate Code, Dead Code, Speculative Generality |
Couplers | 클래스 간 과도한 결합을 유발하는 경우 | Feature Envy, Inappropriate Intimacy, Message Chains, Middle Man |
이러한 베드 스멜을 여러 리팩토링 방법을 적용하여 유지보수성을 향상시킬 수 있다.
결론
리팩토링은 베드 스멜을 식별하여 개선함으로써 유지보수성을 향상시키는 과정이라 할 수 있다. 이 때 유지보수성이 좋은 코드란 요구사항의 변경에 대응하기 쉽고 기능을 확장하기 용이한 코드로 볼 수 있다. 다음 포스트에서 여러 리팩토링 방법들을 소개할 예정이다.
Reference
2024 1학기 소프트웨어시스템설계 수업 자료
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010/57-maintainability