(→개요) |
(→같이 보기) |
||
| (같은 사용자의 중간 판 23개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
==개요== | ==개요== | ||
; | ;[[refactoring]] | ||
;리팩토링, 재구조화 | |||
* 결과의 변경 없이 코드의 구조를 재조정하는 일 | * 결과의 변경 없이 코드의 구조를 재조정하는 일 | ||
* [[기술 부채]]([[설계 스멜]], [[코드 스멜]])를 해소하는 일 | * [[기술 부채]]([[설계 스멜]], [[코드 스멜]])를 해소하는 일 | ||
* 외부 동작에는 변화없이 기존 코드의 내부구조를 개선하는 일 | * 외부 동작에는 변화없이 기존 코드의 내부구조를 개선하는 일 | ||
* 사용자 화면은 그대로 유지한 채 내부 논리나 구조를 개선하는 일 | * 사용자 화면은 그대로 유지한 채 내부 논리나 구조를 개선하는 일 | ||
* 기능은 그대로 동작하도록 두고, 소프트웨어 내부를 수정하는 작업 | |||
* 기능의 변화없이 기능의 추가 용이함을 의한 일련의 소스 수정 과정 | |||
* 애플리케이션 실행 결과의 변경 없이 코드의 구조를 재조정하는 기법 | |||
* 목적: 가독성 향상, 생산성 향상, 코드 품질 향상, [[견고성]] 향상, [[유지보수성]] 향상 | * 목적: 가독성 향상, 생산성 향상, 코드 품질 향상, [[견고성]] 향상, [[유지보수성]] 향상 | ||
---- | ---- | ||
* 리팩토링이 최적화는 아니다. | * 리팩토링이 최적화는 아니다. 오히려 성능이 저하될 수도 있다. | ||
* | * 일정이 촉박한 경우에는 하기 어렵다. | ||
* [[유닛 테스트]] 없이는 제대로 | * [[유닛 테스트]] 없이는 제대로 하기 어렵다. 리팩토링 후에 뭔가 안될 때, 원래 있던 문제인지 리팩토링 때문에 발생한 문제인지 확인하기 어렵기 때문이다. (즉, 오작동에 대한 걱정 + 원인 규명의 어려움) | ||
==하는 이유== | |||
* 가독성이 높아진다. | |||
* 버그를 찾기 쉬워진다. | |||
* 소프트웨어 설계가 개선된다. | |||
==꺼리는 이유== | |||
* 일손·시간 부족 | |||
* 리팩토링 지식 부족 | |||
* 변경 후 오작동 우려 ★ | |||
==예시== | ==예시== | ||
*[[메소드 추출 | {{참고|리팩토링 기법}} | ||
* | * [[메소드 추출]] ★ | ||
* | * 인터페이스 추출 | ||
* | * 이름변경 | ||
* | * 파라미터 제거 | ||
* 파라미터 재배열 | |||
==같이 보기== | ==같이 보기== | ||
{{z컬럼3| | {{z컬럼3| | ||
* [[난독화]] | * [[난독화]] | ||
* [[역공학]] | * [[역공학]] | ||
| 29번째 줄: | 41번째 줄: | ||
* [[소스 코드]] | * [[소스 코드]] | ||
* [[코드 리뷰]] | * [[코드 리뷰]] | ||
* [[코딩 표준]] | |||
* [[코드 검사]] | |||
* [[코드 스멜]] | * [[코드 스멜]] | ||
* [[기술 부채]] | * [[기술 부채]] | ||
* [[단위 테스트]] | |||
* [[디자인 패턴]] | * [[디자인 패턴]] | ||
* [[ | * [[테스트 코드]] | ||
* [[DB 리팩토링]] | * [[DB 리팩토링]] | ||
* [[짝 프로그래밍]] | |||
* [[소프트웨어 품질]] | * [[소프트웨어 품질]] | ||
* [[테스트 주도 개발]](TDD) | |||
}} | }} | ||
==참고== | ==참고== | ||
* {{영어위키백과|Code refactoring}} | * {{영어위키백과|Code refactoring}} | ||
* https://refactoring.com/catalog/ | * https://refactoring.com/catalog/?filter=tags-basic | ||
* https://refactoring.guru/refactoring/techniques | |||
* https://www.youtube.com/watch?v=mNPpfB8JSIU [마틴 파울러] 리팩토링의 중요성 | |||
[[분류: 리팩토링]] | [[분류: 리팩토링]] | ||
[[분류: 프로그래밍]] | [[분류: 프로그래밍]] | ||
[[분류: 소프트웨어 품질]] | [[분류: 소프트웨어 품질]] | ||
2023년 8월 18일 (금) 15:44 기준 최신판
1 개요[ | ]
- refactoring
- 리팩토링, 재구조화
- 결과의 변경 없이 코드의 구조를 재조정하는 일
- 기술 부채(설계 스멜, 코드 스멜)를 해소하는 일
- 외부 동작에는 변화없이 기존 코드의 내부구조를 개선하는 일
- 사용자 화면은 그대로 유지한 채 내부 논리나 구조를 개선하는 일
- 기능은 그대로 동작하도록 두고, 소프트웨어 내부를 수정하는 작업
- 기능의 변화없이 기능의 추가 용이함을 의한 일련의 소스 수정 과정
- 애플리케이션 실행 결과의 변경 없이 코드의 구조를 재조정하는 기법
- 목적: 가독성 향상, 생산성 향상, 코드 품질 향상, 견고성 향상, 유지보수성 향상
- 리팩토링이 최적화는 아니다. 오히려 성능이 저하될 수도 있다.
- 일정이 촉박한 경우에는 하기 어렵다.
- 유닛 테스트 없이는 제대로 하기 어렵다. 리팩토링 후에 뭔가 안될 때, 원래 있던 문제인지 리팩토링 때문에 발생한 문제인지 확인하기 어렵기 때문이다. (즉, 오작동에 대한 걱정 + 원인 규명의 어려움)
2 하는 이유[ | ]
- 가독성이 높아진다.
- 버그를 찾기 쉬워진다.
- 소프트웨어 설계가 개선된다.
3 꺼리는 이유[ | ]
- 일손·시간 부족
- 리팩토링 지식 부족
- 변경 후 오작동 우려 ★
4 예시[ | ]
리팩토링 기법 문서를 참고하십시오.- 메소드 추출 ★
- 인터페이스 추출
- 이름변경
- 파라미터 제거
- 파라미터 재배열
