첫 포스팅을 하고 두 달만에 포스팅을 한다는;; 그동안 얼마나 게을렀는가를 스스로 반성.ㅠㅠ 앞으로 두 번의 포스팅에 걸쳐 리팩토링의 정의... 리팩토링을 왜 해야 되고, 리팩토링을 할 때 어려운 점 등을 정리하고; 그 다음부터 실제 기술적인 면을 정리할 생각이다.
리팩토링 - 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것.
리팩토링은 소프트웨어의 모든 문제점을 해결할 수 있는 방법은 아니지만, 많은 문제점을 해결할 수 있는 유용한 도구가 될 수 있으며, 다양한 목적으로 사용할 수 있다.
구체적으로 리팩토링을 적용할 수 있는 사례를 살펴보자면~
- 리팩토링은 소프트웨어의 디자인을 개선 시킨다.
앞서 얘기 했듯이 단기적인 목적을 이루기 위해서, 또는 코드 전체의 디자인을 제대로 이해하지 못하는 상태에서 코드를 변경할 때, 결국 그 코드는 원래의 구조를 잃을 것이며, 시간이 흐르면 이 효과는 누적되어, 종국에는 어떻게 이도 저도 건드리지 못하는 몬스터가 되는 경우가 발생한다. 정기적인 리팩토링 작업은 이런 문제를 미연에 방지할 수 있으며, 코드의 디자인을 유지하도록 도와준다. 가장 간단한 리팩토링의 예는 중복된 코드를 제거하는 것!
- 리팩토링은 소프트웨어를 더 이해하기 쉽게 만든다.
굳이 남이 이해하기 쉽도록 이타적인 생각을 할 필요도 없다. 그 대상은 미래의 자신이 될 수도 있다. 아마 누구나 자신이 코딩한 프로그램을 시간이 흘러 다시 봤을 때, 쉽게 이해하지 못하는 경험이 있을 것이다.
- 리팩토링은 버그를 찾도록 도와준다.
당연한 얘기로 이해하기 쉬운 소프트웨어가 버그를 찾기도 쉽다.
- 리팩토링은 프로그램을 빨리 작성하도록 도와준다.
개발 이외에 리팩토링을 해야되는데, 그것이 정말 시간을 단축시켜 주는 것일까? 하지만, 정기적인 리팩토링을 통해 코드의 디자인이 유지되고, 코드의 가독성이 높아진다면, 이후 새로운 기능을 추가하거나 기능을 수정 변경할 때 훨씬 수월하다.
그럼, 언제 리팩토링을 해야될까?
사실 날을 잡고, 리팩토링을 하는 것은 개발자에게 너무 많은 부담이 될 수 있다. (정말 부지런한 사람만이 할 수 있을 것 같다.)
- 기능을 추가할 때 리팩토링을 하라.
새로운 기능을 추가하는 경우, 지금의 디자인이 기능 추가가 쉽지 않은 디자인일 수 있다. 그 때 아 예전에 디자인을 할 때 이런 식으로 했었다면, 후회를 하지 말고, 새로이 리팩토링을 하라. 그것이 미래에 똑같은 후회를 방지 할 수 있는 방법이다.
- 버그를 수정할 때 리팩토링을 하라.
- 코드 리뷰를 할 때 리팩토링을 하라.
코드 리뷰는 지식이 개발팀 전체로 확산되는 것을 돕는 좋은 방법이다.
리팩토링을 공부하면서, 정말 나에게 뼈져리게 와닿는 내용이 많다. 시간에 쫓겨서란 변명을 일단 급한대로 코딩을 해오다, 시간이 흘러 기능 추가나 수정이 발생했을 때, 정말 후회한 기억이 지금도 새록 새록 난다. 리팩토링의 가장 큰 적은 귀차니즘이다.
리팩토링 - 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것.
리팩토링은 소프트웨어의 모든 문제점을 해결할 수 있는 방법은 아니지만, 많은 문제점을 해결할 수 있는 유용한 도구가 될 수 있으며, 다양한 목적으로 사용할 수 있다.
구체적으로 리팩토링을 적용할 수 있는 사례를 살펴보자면~
- 리팩토링은 소프트웨어의 디자인을 개선 시킨다.
앞서 얘기 했듯이 단기적인 목적을 이루기 위해서, 또는 코드 전체의 디자인을 제대로 이해하지 못하는 상태에서 코드를 변경할 때, 결국 그 코드는 원래의 구조를 잃을 것이며, 시간이 흐르면 이 효과는 누적되어, 종국에는 어떻게 이도 저도 건드리지 못하는 몬스터가 되는 경우가 발생한다. 정기적인 리팩토링 작업은 이런 문제를 미연에 방지할 수 있으며, 코드의 디자인을 유지하도록 도와준다. 가장 간단한 리팩토링의 예는 중복된 코드를 제거하는 것!
- 리팩토링은 소프트웨어를 더 이해하기 쉽게 만든다.
굳이 남이 이해하기 쉽도록 이타적인 생각을 할 필요도 없다. 그 대상은 미래의 자신이 될 수도 있다. 아마 누구나 자신이 코딩한 프로그램을 시간이 흘러 다시 봤을 때, 쉽게 이해하지 못하는 경험이 있을 것이다.
- 리팩토링은 버그를 찾도록 도와준다.
당연한 얘기로 이해하기 쉬운 소프트웨어가 버그를 찾기도 쉽다.
- 리팩토링은 프로그램을 빨리 작성하도록 도와준다.
개발 이외에 리팩토링을 해야되는데, 그것이 정말 시간을 단축시켜 주는 것일까? 하지만, 정기적인 리팩토링을 통해 코드의 디자인이 유지되고, 코드의 가독성이 높아진다면, 이후 새로운 기능을 추가하거나 기능을 수정 변경할 때 훨씬 수월하다.
그럼, 언제 리팩토링을 해야될까?
사실 날을 잡고, 리팩토링을 하는 것은 개발자에게 너무 많은 부담이 될 수 있다. (정말 부지런한 사람만이 할 수 있을 것 같다.)
- 기능을 추가할 때 리팩토링을 하라.
새로운 기능을 추가하는 경우, 지금의 디자인이 기능 추가가 쉽지 않은 디자인일 수 있다. 그 때 아 예전에 디자인을 할 때 이런 식으로 했었다면, 후회를 하지 말고, 새로이 리팩토링을 하라. 그것이 미래에 똑같은 후회를 방지 할 수 있는 방법이다.
- 버그를 수정할 때 리팩토링을 하라.
- 코드 리뷰를 할 때 리팩토링을 하라.
코드 리뷰는 지식이 개발팀 전체로 확산되는 것을 돕는 좋은 방법이다.
리팩토링을 공부하면서, 정말 나에게 뼈져리게 와닿는 내용이 많다. 시간에 쫓겨서란 변명을 일단 급한대로 코딩을 해오다, 시간이 흘러 기능 추가나 수정이 발생했을 때, 정말 후회한 기억이 지금도 새록 새록 난다. 리팩토링의 가장 큰 적은 귀차니즘이다.
Trackback
Trackback Address :: http://www.nohungry.net/tt1/trackback/158
Comments