의견.png

"리팩토링"의 두 판 사이의 차이

해시넷
이동: 둘러보기, 검색
잔글
9번째 줄: 9번째 줄:
 
== 특징 ==
 
== 특징 ==
  
 +
 +
== 문제점 ==
 +
데이터베이스 부분에서의 문제점. 대부분의 비즈니스 애플리케이션은 데이터베이스 스키마와 밀접하게 결합되어 있다.  데이터베이스 스키마와 객체 모델간의 종속을 최소화하기 위해 계층구조로 만들었다 하더라도, 스키마를 변경하려면 데이터를 마이그레이트 해야 하는데, 시간도 오래 걸리고 위험도 큰 작업이다. 인터페이스 변경에 따른 문제점. 객체의 중요한 점 중 하나로 인터페이스를 변경하지 않고 내부 구현을 바꿀 수 있따는 것이다. 객체를 사용하는 부분을 변경하지 않고도 객체의 내부 구조를 안전하게 바꿀 수 있지만, 인터페이스를 변경하면 어떤 일이 발생할지 모르기 때문에 인터페이스를 유지하는 것은 중요하다. 하지만, 많은 리팩토링이 인터페이스를 변경 시킨다. 그렇다면 언제 리팩토링을 하지 말아야 하는가? 코드를 처음부터 다시 작성해야 할 때이다. 기존 코드가 너무 엉망이라 처음부터 다시 시자하는 것이 더 쉬운 경우가 있다. 하지만 이런 결정은 쉽게 내릴 수 없고, 가이드 라인도 없다. 또한, 마감일에 가까울 때이다. 리팩토링으로 얻는 생산성 향상은 마감일이 지난 다음에나 나타날 것이다.<ref>키훈키훈킴, 〈[https://codereview.tistory.com/3 리팩토링이란 무엇인가?]〉, 《네이버 블로그》, 2014-07-15</ref>
 +
 +
  
 
{{각주}}
 
{{각주}}
14번째 줄: 19번째 줄:
 
== 참고자료 ==
 
== 참고자료 ==
 
* AIdev, 〈[https://m.blog.naver.com/PostView.nhn?blogId=magnking&logNo=220973095825&proxyReferer=https:%2F%2Fwww.google.com%2F 리팩토링이란 무엇인가?]〉, 《네이버 블로그》, 2017-05-07
 
* AIdev, 〈[https://m.blog.naver.com/PostView.nhn?blogId=magnking&logNo=220973095825&proxyReferer=https:%2F%2Fwww.google.com%2F 리팩토링이란 무엇인가?]〉, 《네이버 블로그》, 2017-05-07
 +
* 키훈키훈킴, 〈[https://codereview.tistory.com/3 리팩토링이란 무엇인가?]〉, 《네이버 블로그》, 2014-07-15
  
 
== 같이 보기 ==
 
== 같이 보기 ==

2021년 2월 24일 (수) 17:28 판

리팩토링(Refactoring)은 외부동작을 바꾸지 않으면서 내부 구조를 개선하는 방법으로, 소프트웨어 시스템을 변경하는 프로세스이다.

개요

리팩토링은 소프트웨어를 보다 쉽게 이해할 수 있도록 만드는 작업이다. 이해하기 쉬운 코드가 수정하기도 쉽기 때문에 수정하기 쉬운 코드를 만든다는 또 하나의 목적 역시 자연스럽게 달성된다. 리팩토링은 들어가는 리소스를 최소화하기 위해서 외부 동작의 변화 없이 소프트웨어의 구조를 바꾸는 것을 중심으로 진행이 된다. 리팩토링이 적절하게 진행되면 소프트웨어가 이해하기 쉬워지고 수정도 용의해 진다. 여기서 얻을 수 있는 다양한 이익이 리팩토링을 해야하는 이유가 된다. 이해하기 쉽고 수정하기 쉬워지니 개발자의 개발 속도가 자연스럽게 빨라진다. 그리고 이해하기 쉽기 때문에 버그가 있다면 훨씬 쉽게 발견할 수 있다. 리팩토링을 마친 다음 뿐만 아니라 코드의 구조를 수정하면서 버그를 발견할 가능성이 더 높을 수 도 있다.[1]

권장 상황

기본적으로 리팩토링은 별도의 시간을 내는 것이 아니라 틈틈히 계속 진행되어야 한다. 또한 다음과 같은 경우에 리팩토링을 진행하는 것이 권장된다. 비슷한 것을 세 번째로 하게 되면 리팩토링을 해야 하는 신호이다. 이것을 삼진규칙이라고 한다. 기능을 추가할 때도 리팩토링을 하는 것이 좋다. 기능을 추가할 때 어떤 부분을 수정해야 할지 더 쉽게 판단할 수 있기 때문이다. 버그를 수정할 때도 리팩토링을 할 필요가 있다. 이미 언급한 것처럼 리팩토링을 하는 도중에 버그가 발견될 수도 있고 이해하기 쉬운 코드에서 버그를 찾기기 훨씬 쉽기 때문이다. 그리고 팀원들과 함께 코드 리뷰를 할 때 리팩토링을 할 필요가 있다. 리팩토링을 진행하는 과정을 공유하면서 팀 전체에 지식이 공유될 수도 있고 다양한 관점으로 보기 때문에 디자인이나 코드의 장단점을 더 잘 파악할 수 있다.[1]

특징

문제점

데이터베이스 부분에서의 문제점. 대부분의 비즈니스 애플리케이션은 데이터베이스 스키마와 밀접하게 결합되어 있다. 데이터베이스 스키마와 객체 모델간의 종속을 최소화하기 위해 계층구조로 만들었다 하더라도, 스키마를 변경하려면 데이터를 마이그레이트 해야 하는데, 시간도 오래 걸리고 위험도 큰 작업이다. 인터페이스 변경에 따른 문제점. 객체의 중요한 점 중 하나로 인터페이스를 변경하지 않고 내부 구현을 바꿀 수 있따는 것이다. 객체를 사용하는 부분을 변경하지 않고도 객체의 내부 구조를 안전하게 바꿀 수 있지만, 인터페이스를 변경하면 어떤 일이 발생할지 모르기 때문에 인터페이스를 유지하는 것은 중요하다. 하지만, 많은 리팩토링이 인터페이스를 변경 시킨다. 그렇다면 언제 리팩토링을 하지 말아야 하는가? 코드를 처음부터 다시 작성해야 할 때이다. 기존 코드가 너무 엉망이라 처음부터 다시 시자하는 것이 더 쉬운 경우가 있다. 하지만 이런 결정은 쉽게 내릴 수 없고, 가이드 라인도 없다. 또한, 마감일에 가까울 때이다. 리팩토링으로 얻는 생산성 향상은 마감일이 지난 다음에나 나타날 것이다.[2]


각주

  1. 1.0 1.1 AIdev, 〈리팩토링이란 무엇인가?〉, 《네이버 블로그》, 2017-05-07
  2. 키훈키훈킴, 〈리팩토링이란 무엇인가?〉, 《네이버 블로그》, 2014-07-15

참고자료

같이 보기

  의견.png 이 리팩토링 문서는 소프트웨어에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.