리팩토링(Refactoring)

문제2) 리팩토링(Refactoring)에 대한 아래의 사항을 설명하시오.

 

가. 정의, 목적, 리팩토링 순서, 리팩토링 주요기법

나. 코드스멜(Code Smell) 의 정의와 특징

다. 코드스멜의 종류를 3개이상 기술하고 각각의 리팩토링 방법

 

답)

 

1. SW 내부로직의 재구조화 작업, 리팩토링의 정의 및 목적

가. 리팩토링의 정의

• 소프트웨어 모듈의 외부적 기능은 수정하지 않고 내부적인 구조, 관계등을 단순화하여 소프트웨어의 유지보수성을 향상시키는 기법

 

나. 리팩토링의 목적

소프트웨어 디자인 개선	설계 의도와 구현 코드의 일관성을 유지하여 설계 변경 용이
소프트웨어 이해도 향상	이해하기 쉬운 코드는 개발자의 작업시간 단축
오류발견 용이성 확보	소스 구조를 명확히 함으로써 버그 원인 쉽게 발견
전체 개발 생산성 유지	'좋은 디자인 유지→개발자 이해 향상→오류감소" 개발가속화

 

2. 리팩토링 순서, 리팩토링 주요기법

가. 리팩토링의 순서

 

나. 리팩토링 주요기법

구분	설명
Extract Method	그룹으로 함께 묶을 수 있는 코드 조작이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드를 추출
Replace Temp With Query	어떤 수식의 결과값을 저장하기 위해서 임시변수를 사용하고 있다면, 수식을 추출해서 메소드로 만들고, 인시변수를 참조하는 곳을 찾아 모두 메소드 호출로 교체
Move Method	메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면, 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드 생성
Extract Class	두 개의 클래스가 해야 할 일을 하나의 클래스가 하고 있는 경우 새로운 클래스를 만들어 관련 있는 필드와 메소드를 예전 클래스에서 새로운 클래스로 이동
Rename Method	메소드의 이름이 그 목적을 드러내지 못하고 있다면 메소드의 이름 변경
Pull Up Field	두 서비 클래스가 동일한 필드를 가지고 있다면, 해당 필드를 슈퍼 클래스로 이동
Pull Up Method	동일한 기능을 하는 매소드를 여러 서브클래스에서 가지고 있다면 이 슈퍼클래스로 이동
Encapsulation Field	Public 필드가 있는 경우에는, 그 필드를 Private 으로 하고 접근자 제공
Inline Temp	간단한 수식의 결과값을 가지고 임시변수가 있고, 그 임시변수가 다른 리팩토링을 하는데 방해가 된다면, 이 임시변수를 참조하는 부분을 모두 원래의 수식으로 변경
Introduce Explaning Variable	복잡한 수식이 있는 경우에는, 수식의 결과나 또는 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용
Split Temporary Variable	루프안에 있는 변수나 collecting temporary vatiable 도 아닌 임시변수에 값을 여러 번 대입하는 경우에는, 각각의 대입에 대해서 따로따로 임시변수를 작성
Remove Assignments to Parameters	파라미터에 값을 대입하는 코드가 있다면, 대신 임시변수를 사용
Substitute Alogrithm	알리고즘을 보다 명확한 것으로 바꾸고 싶을 때는 메소드의 몸체를 새로운 알고리즘으로 변경
Replace Magic Number with Symbolic Constant	특별한 의미를 가지는 숫자 리터럴이 있으면, 상수를 만들고, 의미를 잘 나타내도록 이름을 지은 다움, 숫자를 상수로 변경
Decompose Conditional	복잡한 조건문(if-then-else)이 있는 경우, 조건, then 부분, 그리고 else 부분에서 메소드를 추출
Consolidate Duplicate Conditional Fragments	동일한 코드 조각이 조건문의 모든 분기 안에 있는 경우, 동일한 코드를 조건문 밖으로 이동
Remove Control Flag	일련의 boolean 식에서 컨트롤 플래그 역할을 하는 변수가 있는 경우, break 또는 return 을 대신 사용
Replace Nested Conditional with Guard Clauses	메소드가 정상적인 실행결로를 불명확하게 하는 조건 동작을 가지고 있는 경우, 모든 특별한 경우에 대해서 보호절(guard clause)을 사용
Add Parameter	어떤 메소드가 그 메소드를 호출하는 부분으로부터 더 많은 정보를 필요로 한다면, 이 정보를 넘길 수 있는 파라미터를 추가
Remove Parameter	파라미터가 메소드 몸체에서 더 이상 사용되지 않는다면, 그 파라미터를 제거
Parameterize Method	몇몇 메소드가 메소드 몸체에 다른 값을 포함하고 있는 것을 제외하고는 비숫한 일을 하고 있다면, 다른 값을 파라미터로 넘겨 받은 하나의 메소드를 작성
Replace Parameter with Explicit Methods	파라미터의 값에 따라서 다른 코드를 실행하는 메소드가 있다면, 각각의 파라이터 값에 대한 별도의 메소드를 작성
Replace Parameter with Methods	메소드를 호출한 다음, 결과를 다른 메소드에 대한 파라미터로 넘기고 있다. 수신자(파라미터를 넘겨 받은 메소드) 또한 이 메소드를 호출할 수 있다면, 그 파라미터를 제거하고 수진자가 그 메소드를 호출
리팩토링을 통해 코드스멜을 줄이며 클린코드 생성

 

3. 코드스멜(Code Smell)의 정의와 특징, 코드스멜의 종류별 리팩토링 방법

가. 코드스멜(Code Smell)의 정의와 특징

구분	설명
정의	프로그램 내에서 이해하기 어렵고 수정이 힘들며 확장이 어려운 코드를 의미하며, 프로그래머의 육감으로 찾아 리팩토링이 필요한 코드
특징	Code Smell 은 객관적이지 않으며 개발 환경에 따라 틀릴 수 있음 팀이나 회사에서 중요하게 생각하는 가치에 따라 틀릴 수 있음 어떤 언어를 사용하느냐에 따라 틀릴 수 있음

 

나. 코드스멜의 종류별 리팩토링 방법(3개 이상)

코드스멜	설명	리팩토링 방법
중복된 코드	기능이나 데이터 중복	중복제거
긴 메소드	메소드 내부가 너무 긴 경우	메소드를 적정 크기로 나눔
큰 클래스	한 클래스에 너무 많은 속성과 메소드 존재	클래스 몸집 줄임
긴 파라이터 리스트	메소드 파라미터가 너무 많음	파라미터 개수 줄임
두 가지 이유로 수정되는 클래스	한 클래스의 메소드가 두 가지 이상의 이유로 수정이 되면 그 클래스는 한가지 종류의 책임만을 수행하지 않게 됨(SRP위반)	한 가지 이유만으로 수정되도록 변경
여러 클래스 동시수정(Shothun Surgery)	특정 클래스를 수정하면 그때마다 관련된 여러 클래스에서 자잘한 변경을 해야 함	여러 클래스에 흩어진 유사 기능을 한 곳으로 모음
다른 클래스를 지나치게 이용(Feature Envy)	빈번히 다른 클래스부터 데이터를 얻어와서 기능 수행	메소드를 데이터가 빈번히 쓰이는 클래스로 이동
유사 데이터들의 그룹 중복(Data Clumps)	3개 이상의 데이터 항목이 여러 곳에 중복되어 나타남	해당 데이터를 독립 클래스로 정의
기본 데이터 타입 선호(Prime Obsession)	객체 형태의 그룹을 만들지 않고, 기본 데이터 타입만 사용	같은 작업을 수행하는 기본 데이터의 그룹을 별도 클래스로 만듦
주석(Comments)	프로그램 코드가 단순서오가 간결성을 담보로 하고 있다면, 주석이 불필요	간결한 주석으로 대체

 

---

 

공감과 댓글은 아이티신비에게 큰 힘이 됩니다.

블로그 글이 유용하다면 블로그를 구독해주세요.♥