2015. 9. 6. 21:27ㆍ프로그래밍/리팩토링
리팩토링이란?
명사 - 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업.
동사 - 리팩토링 기법을 연달아 적용해서 겉으로 드러나는 기능은 그대로 둔 채 소프트웨어 구조를 변경한다.
리팩토링의 목적은 소프트웨어를 더 이해하기 쉽고 수정하기 용이하게 한다.
리팩토링은 겉으로 드러나는 소프트웨어 기능에 영향을 주지 않는다.
기능 추가와 리팩토링을 구분하자.
기능 추가 - 코드를 추가하지 말고 기능만 추가.
리팩토링 - 기능은 추가하지말고 코드 구조만 수정.
두 개의 작업을 할때 프로그래머가 무엇을 하고 있는지 인식하고 해당 작업에 대한 일관성을 유지해야한다.
리팩토링은 왜 하는가?
소프트웨어 설계가 개선된다.
- 중복 코드를 없앤다. 시스템 속도엔 영향이 미미하지만 코드 수정이 용이해진다.
- 중복 코드 제거는 깔끔한 설계의 필수 요건.
소프트웨어를 이해하기 더 쉬워진다.
- 실행하는데만 집착한 코드가 있을 수 있다. 자신이 짠 코드도 잊어버린다.
- 코드의 기능을 떠올리며 실행되는 방법을 알 수 있다.
버그를 찾기가 쉽다.
프로그래밍 속도가 빨라진다.
리팩토링이 필요할 때
같은 작업의 삼진 아웃 때
- 처음 할 땐 그냥 하고
- 두 번째 해야 할 땐 중복 작업이라 좀 망설여져도 일단 그냥 하고
- 세 번째 하게 되면 그때 리팩토링을 실시한다.
기능을 추가할 때
- 코드를 이해하기 쉽게 하기 위해.
- 설계가 지저분해서 어떤 기능을 추가하기 힘들 때.
버그 수정할 때
코드를 검수할 때
- 코드 검수가 용이하고 다양한 아이디어가 나올 수 있다.
리펙토링 관련 문제들
데이터베이스
- 수많은 애플리케이션이 데이터베이스 스키마와 강력하게 결합되어 있다.
- 데이터베이스 스키마를 수정하면 데이터도 이전해야 한다. 시간이 오래 걸리고 위험성이 높다.
인터페이스 변경
- 상당수의 리팩토링이 인터페이스를 건드린다.
- '메서드명 변경'과 같은 기법은 그 자체가 인터페이스 수정작업.
- 새 매서드를 만들더라도 이전 매서드를 두고 새 인터페이스를 호출하게 한다.
* published(public 보다 한 단계 더 적극적으로 공개된) 인터페이스가 필요하긴 하지만 함부로 해당 타입으로 만들진 말자.
팀원 간의 트러블이 생기지 않는 융통성 있는 리팩토링을 위해 코드 소유권 정책을 수정하자.
리팩토링을 어렵게 하는 설계를 수정하는 일
- 설계에 대한 결정이 바뀌거나 수정학디 힘들 것 같은 민감함 부분이 있을 때.
- 리팩토링은 공정이 어렵긴 하나 가능하긴 하다.
리팩토링하면 안되는 상황
- 기존 코드가 너무 개판이라 새로 짜는게 나을 때.(다시 짜)
- 납기가 임박했을 때도 리팩토링은 삼가.
리팩토링과 설계
리팩토링은 설계를 보완하는 툭수한 역할을 한다.
설계 후 개발
- 사전 설계의 역할이 매우 중요하다.
- 나중에 수정할 필요가 없도록 사전 설계에 많은 시간과 노력을 들여야 한다.
리팩토링-설계 후 개발
- 사전 설계 과정에서 완벽한 솔루션을 찾지 않아도 된다.
- 구축해 나가며 문제를 더 잘 이해할 수 있다.
- 설계가 단순해진다는 장점이 있다.
- 무작정 유연한 솔루션을 구현하는 것이 아니라 먼저 단순한 솔루션으로 구현하고
나중에 그걸 유연한 솔루션으로 리팩토링하는 비용을 생각하면 설계 과정의 복잡한 과정을 줄일 수 있다.
리펙토링과 성능
리팩토링이 소프트웨어 개발 기간을 단축하는데 도움 된다.
리팩토링하는 동안에는 단기적으로 소프트웨어가 느려지긴하지만 최적화를 거치면 튜닝하기 훨씬 쉬워지고
결과적으로 소프트웨어 개발이 더 빨라진다.
빠른 소프트웨어 작성을 위한 일반적인 세 가지 방법.
- 실시간 시스템에 주로 사용되는 시간 분배. 설계를 분해하면서 각 구성 요소에
시간이나 메모리 사용량과 같은 자원별 예산을 할당한다.
- 성능에 꾸준히 관심을 갖는것.
- 실행될 일 없는 90%의 코드보단 성능에 큰 영향을 미치는 작은 부분에 집중하여 성능에 꾸준히 관심을 가진다.
'프로그래밍 > 리팩토링' 카테고리의 다른 글
(작성중) 코드의 구린내 (0) | 2015.09.06 |
---|