| 중 | 소프트웨어 리팩토링 (SW Refactoring) |
[정의] 소프트웨어 생산성, 유지보수 용이성 향상을 위해 모듈의 외부적 기능은 수정하지 않고, 내부적인 구조, 관계 등을 단순화하여 소프트웨어 코드의 단순성, 명확성을 향상시키는 소프트웨어 코드 개선 기법 [절차] 대상선정 > 테스트 코드 작성 > 리팩토링 수행 > 테스트 수행 > 종료 [대상] 중복된 코드, 긴 메소드, 큰 클래스, 긴 파라미터 리스트, 산탄총 수술 [기법] 이동(Move), 분리(Extract), 일반화, 통합 [Good SW 조건] 단순성, 명확성, 일반성, 자동화 |
Refactoring, Pullup Method, Extract Interface, Move Method 내부 기능만 변경, 외부는 변화는 없음 , bad smell, 수행 절차 | [절차] 데코리테종 [대상] 중긴큰긴산 [기법] 이분(에) 일통 [조건] 단명일자 |
| 토픽 이름 | 소프트웨어 리팩토링 (Refactoring) |
| 분류 | SW > 유지관리(유지보수 변경) |
| 키워드(암기) | Inline Class, Inline Method Extract Class, Extract Method, Extract Interface Move Class, Move Method, Move Field Pull Up Method, Pull Up Field, / Push Down Method, Push Down Field Rename Method |
| 암기법(해당경우) |
기출문제
| 번호 | 문제 | 회차 |
| 1 | 5. 은행에서 계좌의 당좌 대월액을 계산하는 프로그램이다. 새로운 계좌 타입이 몇 가지 추가될 예정이고, 이들은 당좌 대월액을 계산하는 각각의 규칙이 필요하여 메소드 overdraftCharge()를 클래스 AccountType으로 옮기려고 한다. 리팩토링 기법 중의 하나인 Move 메소드의 개념과 절차를 설명하고 이를 활용하여 리팩토링한 코드를 작성하시오. | 110.관리.3교시 |
| 2 | 3. DB Refactoring에 대하여 다음 질문에 답하시오. (1) DB Smell에 대하여 설명하시오. (2) DB Refactoring 유형 및 절차에 대하여 설명하시오. |
95.관리.4교시 |
| 3 | 2. 리팩토링 기법 중 Extract Interface에 대해 설명하시오. | 합숙_17.08.3일차.공통 |
| 4 | 12. 디자인패턴과 리팩토링을 설명하시오. | 모의_18.05.관리.1 |
| 5 | 12. 리팩토링의 목적과 기법을 설명하시오. | 합숙_14.07.3일차.관리 |
| 6 | 리팩토링에서의 Pull Up Method에 대하여 설명하시오. | 합숙_14.01.5일차.공통 |
| 7 | 데이터베이스 냄새(DB Smell)와 DB 리팩토링의 분류에 대해 설명하시오. | 합숙_12.08.4일차.공통 |
| 8 | 2. 리팩토링 기법 중 Extract Interface에 대해 설명하시오. | 합숙_17.08.3일차.공통 |
| 9 | 7. 리팩토링의 목적과 기법을 설명하시오 | 모의_09.05.공통.1 |
| 10 | 소프트웨어 리팩토링(Refactoring)에 대해 설명하시오. | 모의_15.05.응용.1 |
| 11 | 소프트웨어 리팩토링(Refactoring)에서 Pullup Method와 Extract Interface에 대해 설명하시오. | 모의_16.01.응용.1 |
| 12 | 4. SW 리팩토링에 대해 다음을 설명하시오. 가. SW 리팩토링(SW Refactoring)의 개념을 설명하시오. 나. 코드악취(Bad Smells in Code) 유형을 5 개 이상 제시하시오. 다. ‘Inline Method’ 기법을 설명하고, 이를 활용하여 아래 제시된 코드를 리팩토링 하시오. ----------------------------------------------------------------------- int getRating( ){ return (moreThanFiveLateDeliveries( )) ? 2 : 1; } boolean moreThanFiveLateDeliveries( ){ return _numberOfLateDeliveries > 5; } ----------------------------------------------------------------------- |
모의_16.06.관리.2 |
- 소프트웨어 코드의 정제를 통한 생산성 향상기법, SW 리팩토링의 개요
가. SW 리팩토링(Refactoring)의 정의
- 소프트웨어 모듈의 외부적 기능은 수정하지 않고 내부적인 구조, 관계등을 단순화하여 소프트웨어의 유지보수성을 향상시키는 기법
- SW 리팩토링의 목적
| 목적 | 내용 |
| 소프트웨어 디자인 개선 | - 설계 의도와 구현 코드의 일관성을 유지하여 설계 변경 용이 |
| 소프트웨어 이해도 향상 | - 이해하기 쉬운 코드는 개발자의 작업시간 단축 |
| 오류발견 용이성 확보 | - 소스 구조를 명확히 함으로써 버그 원인 쉽게 발견 |
| 전체 개발 생산성 유지 | - “좋은 디자인 유지 -> 개발자 이해 향상 -> 오류감소” 개발 가속화 |
- Good 소프트웨어의 조건
| 조건 | 내용 |
| 단순성(Simplicity) | - 프로그램을 짧고 관리하기 편하게 만들어 주는 기능 |
| 명확성(Clarity) | - 이해하기 쉽게 만들어 주는 기능 |
| 일반성(Generality) | - 새로운 상황에 잘 적응하고 확장이 가능하도록 해주는 기능 |
| 자동화(Automation) | - 사람이 해야 하는 수고를 덜어주는 기능 |
라. 리팩토리 대상
- SW 리팩토리 수행절차와 기법
가. SW 리팩토리 수행절차
나. SW 리팩토링의 주요 기법
| 기법 | 내용 |
| 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 Explaing Variable | - 복잡한 수식이 있는 경우에는, 수식의 결과나 또는 수식의 일부에 자신의 목적을 잘 설명하는 이름으로 된 임시변수를 사용 |
| Split Temporary Variable | - 루프안에 있는 변수나 collecting temporary variable도 아닌 임시변수에 값을 여러 번 대입하는 경우에는, 각각의 대입에 대해서 따로따로 임시변수를 작성 |
| Remove Assignments to Parameters | - 파라미터에 값을 대입하는 코드가 있으면, 대신 임시변수를 사용하도록 하라 |
| Substitute Algorithm | - 알고리즘을 보다 명확한 것으로 바꾸고 싶을 때는 메소드의 몸체를 새로운 알고리즘으로 변경 |
| 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 | - 메소드를 호출한 다음, 결과를 다른 메소드에 대한 파라미터로 넘기고 있다. 수신자(파라미터를 넘겨 받는 메소드) 또한 이 메소드를 호출할 수 있다면, 그 파라미터를 제거하고 수신자가 그 메소드를 호출 |
III. 리팩토링을 제대로 하기 위한 기술 및 적용시점
- 리팩토링을 제대로 하기 위한 기술
| 항목 | 내용 |
| 나쁜코드 식별 | - 문제가 될 수 있는 코드를 식별해 내는 능력 - 어느 정도의 경험이 필요 |
| 좋은코드 식별 | - 어떤 방향으로 고치면 좋은지를 아는 것 |
| 테스트 | - 테스트를 만들어 내는 방법을 익혀야 한다. - 테스트프레임워크를 선택하고, 이를 이용해서 단위테스트를 구축해서 자동화까지 하도록 만들어야 한다. - 중간에 Mock과 같은 것을 이용할 수 있어야 하기에, 대부분 경우 TDD(Test Driven Development)와 같은 곳에서 사용하는 방법을 같이 적용해 볼 수 있다. |
| 시간확보 | - 리팩토링을 할 수 있는 시간을 확보 - 작게 시작하려고 노력 - 리팩토링 테크닉이 익숙해지기 전에는 대규모로 할 수 있다는 생각은 잠시 접어두는 것이 좋다. |
- 리팩토링 적용시점
| 시점 | 적용사유 |
| 삼진규칙 | - 비슷한 중복이 세번째 나타나는 경우 수행 -> 기본가이드제공 |
| 기능추가시 | - 기존코드의 구조를 개선으로 이해향상 -> 기능추가를 쉽고 빠르게 수행 |
| 버그수정시 | - 버그수정 전에 더 깊은 이해를 제공 -> 버그수정용이 |
| 코드리뷰중 | - 코드의 명확성 유지,더 나은 설계 아이디어가 제안 -> 품질향상 |
[참고]
- Pull up Method
- 동일기능 중복해서 구현되었을 경우, 확산적 변경현상이 발생할 확률 농후
- 중복된 기능(메소드, 클래스)를 상위로 올리는 것
- Extract Interface
- 두 클래스에 공통적인 기능(메소드, 클래식)이 있을 경우 인터페이스로 분리하여 참조 받는 방식
- Move Method
- 메소드가 자신이 정의된 클래스보다 다른 클래스의 기능을 더 많이 사용하고 있다면 이 메소드를 가장 많이 사용하고 있는 클래스에 비슷한 몸체를 가진 새로운 메소드를 만들어라
-- 2018.06.04 추가내용
<참조 사이트>
https://www.refactoring.com/catalog/
http://arisu1000.tistory.com/search/Inline%20Class
| 기법 | 개념도 | 설명 |
| Inline Class |  |
클래스가 별로 하는일이 없다면 해당 클래스의 기능을 다른 클래스안으로 옮기고 클래스를 삭제 |
| Inline Method |
 |
메소드의 본문이 메소드 이름 만큼이나 명확하다면 해당 본문을 메소드를 호출하는 호출자 안으로 옮기고 메소드를 삭제 |
| Extract Class |  |
두개의 클래스에서 작업 되야 하는 하나의 클래스가 있다면 새로운 클래스를 만들고 이전 클래스에 있던 관련된 필드와 메소드를 새로운 클래스로 옮김 |
| Extract Method |
 |
함께 그룹화될 수 있는 코드 조각이 있다면 적절한 메소드를 만들고 코드들을 해당 메소드 안으로 옮김 |
| Extract Interface |  |
인터페이스가 같은 부분을 사용하면, 인터페이스의 같은 부분은 추출하여 인터페이스를 통합 추출 적용함. |
| Move Class |  |
기능과 관련 없는 다른 클래스들이 패키지에 포함되어 있다면 해당 클래스를 더 관련성이 높은 패키지로 옮기거나 추후 사용될 가능성이 있는 새 패키지를 생성 |
| Move Method |  |
메소드가 정의된 클래스보다 다른 클래스에서 더 많이 사용된다면 해당 클래스로 메소드를 옮기고, 이전 메소드에는 단순 대리자를 만들거나 전체에서 제거 |
| Move Field |  |
필드가 정의된 클래스보다 다른 클래스에서 더 많이 사용된다면 필드를 더 많이 사용되는 다른 클래스로 옮기고, 필드를 사용하는 모든 사용자들을 변경 |
| Pull Up Method |  |
서브클래스들에 같은 결과를 반환하는 메소드들을 가지고 있다면 해당 메소드들을 슈퍼클래스로 옮김 |
| Pull Up Field |  |
두개의 서브클래스가 같은 필드를 가지고 있다면 해당 필드를 슈퍼클래스로 옮김 |
| Push Down Method |  |
슈퍼클래스의 행위가 특정 서브클래스하고만 관련있다면 해당 메소드를 그 서브클래스로 옮김 |
| Push Down Field |  |
어떤 필드가 특정 서브클래스에서만 쓰인다면 그 서브클래스로 필드를 옮김. |
| Rename Method |  |
메소드의 이름이 메소드의 목적을 나타내지 못한다면 메소드의 이름을 변경 |
반응형
'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글
| SW사업 대가산정 가이드 (0) | 2024.04.22 |
|---|---|
| 간이법 계산 (0) | 2024.04.21 |
| Function Point / ISO/IEC 14143 (0) | 2024.04.20 |
| SW 비용 산정 일반 (0) | 2024.04.19 |
| 감리결과보고서 작성하기 (1) | 2024.04.18 |
