-
[Refactoring] 위대한 시작..Software/Refactoring : 리팩토링 2017. 9. 23. 18:19반응형
* 해당 포스팅은 Martin Fowler의 Refactoring 책의 내용을 정리한 것이다.
현업에서는 동일한 소스 코드를 여러명이 붙어서 수정하거나 디버깅 하기 때문에 직관적이고 이해가 쉬운 코드를 작성하는 것이 매우 중요하다. 그러나 우리는 언제나 그렇듯 일정에 쫓겨 날림 코드를 작성해야만 하는 경우가 매우 많다. 이렇게 추가/수정 된 코드들은 결국 작성자만 알게되는 코드로 남게 되고 이는 다른 개발자들의 휴먼 에러(Human Error) 혹은 사이드 이펙트(Side Effect)를 불러일으키게 되는 주요 원인이 되기도 한다. 이렇게 작성 된 코드들로 인해 지저분해진 설계/구조를 수정하고 재배치, 변경하는 작업을 우리는 리팩토링(Refatoring) 이라고 한다.
리팩토링을 통해 우리는 성능 향상, 기능의 고도화 같은 결과물을 낼 수는 없지만 기능, 코드의 본래의 목적과 의도를 되살리고 코드를 조금 더 이해하기 쉬운 구조로 변경할 수 있다. 리팩토링의 중요성은 프로그램 외적인 부분보다 내적인 부분에서 더욱 인정받는다. 하지만 프로그램의 내적인 부분은(설계/구조, 코드 품질 등) 눈으로 쉽사리 볼 수 있는 것이 아니다 보니 많은 사람들이 리팩토링의 중요성과 그 가치를 간과하기 쉽다. 그렇기에 오늘은 리팩토링을 왜 해야만 하는 지.. 그리고 언제 리팩토링을 실시해야 하는 지에 대하여 정리 하고자 한다.
-------------------------------------------------------------------------------------------------------------------
Why?
- 설계 개선
Software는 코드 라인의 수의 증가로 인한 설계 노후화를 피할 수 없다. 특히 급하게 추가된 코드들이나 코드 구조를 완벽히 이해하지 않고 수정한 코드들로 인하여 코드 구조가 망가지기 시작하면서 최초 계획/구현 되었던 설계 구조가 틀어지기 시작한다. 그렇기에 오래된 Software는 코드 구조가 산만해지고 애초의 설계 목적은 잃어버린 채 존재하고 있는 코드들이 다수 존재하게 된다. 산만해지고 복잡해 진 설계/구조로 인한 유지 보수의 난이도 증가는 또 다시 코드 설계/구조를 더욱 복잡하고 지저분하게 만드는 악순환을 불러 일으킨다. 그렇기에 처음의 설계/구조를 유지하기 위해서는 정기적인 리팩토링 작업이 필요하다.
- 쉬운 코드
Software 개발작업은 대부분 여러명의 동료 개발자와 이루어지는 경우가 많고 큰 기업의 경우 한 프로그램을 세계 여러 곳의 개발자들과 함께 작업하는 것이 일반적일 것이다. 그러므로 최초 코드를 작성한 사람 이외에 다른 사람들이 쉽게 이해할 수 있도록 하는 코드 작성은 매우 중요하다. 1시간이면 수정가능한 코드를 그 이상의 시간을 들여서 수정한다는 것은 비효율적일 뿐만 아니라 프로젝트 일정에도 영향을 줄 수 있기 때문이다.
그렇기에 해당 코드가 가지고 있는 최초 의도와 목적을 명확히 하는 것은 매우 중요한 작업이다. 분명히 시간이 지남에 따로 오래된 코드들은 그 목적과 의도와는 맞지 않게 바뀌어 있을테니 말이다.
- 디버깅 용이
현재 디버깅을 도와주는 수 많은 디버깅 도구들이 존재한다. 그러나 코드의 근본적인 이해가 없다면 해당 도구들의 사용도 무용지물이 될 것이다. 직관적인 그리고 이해가 쉬운 코드 구조/설계가 쉬운 버그 발견 및 디버깅을 해준다는 것은 예전이나 지금이나 같다.
"난 뛰어난 프로그래머는 아니고, 단지 습관을 잘 들인 착실한 프로그래머다"
- 켄트 벡 (Kent Beck) -
- 프로그래밍 속도 향상
사실 리팩토링 작업은 기존의 기능을 개선하거나 고도화는 작업이 아니다. 버그를 찾거나 버그를 해결하는 작업도 아니며 그 저 이해하기 쉬운 코드로 혹은 최초 설계의 목적과 의도에 맞는 코드로 다시 되돌리는 작업을 하는 것이다. 그렇기에 단순히 신규 기능을 추가하는 개발 시간을 생각한다면 리팩토링 작업이 해당 개발 시간을 늦추게 될 것이라고 예상하기 쉽다.
그러나 전체 개발 일정에서 살펴본다면 리팩토링 작업은 추후 발생할 수 있는 버그의 가능성을 줄여 주고 디버깅 속도를 높여 주며 동료 개발자들의 개발 효율을 높여 준다는 점에서 실질적인 개발 속도를 향상 시켜주는 효과를 가지고 있다.
-------------------------------------------------------------------------------------------------------------------
When?
- 비슷한 작업을 3번 해야하는 경우
돈 로버츠(Don Roberts)가 이야기 한 리팩토링 시점 판단법이다. 어떤 작업을 처음 하고 나서 비슷한 작업을 또 하게 된다면 망설여지더라도 일단 그냥 하고 만약 세 번째 또 하게 되면 그 떄 리팩토링을 실시하라는 것이다.
- 기능 추가
어떤 기능을 추가해야 하는 경우 이 기능의 베이스가 되는 혹은 연관되어 있는 코드들이 이해하기 어렵게 되어 있는 경우가 많다. 이런 경우 리팩토링을 실시하여 주변 코드들과 직간접적으로 신규 기능과 얽혀 있는 코드들을 이해하기 쉽게 해야할 필요성이 있다. 이를 통해 신규 기능 추가로 인한 사이드 이펙트(Side Effect)를 줄일 수 있고 리팩토링 작업을 진행하면서 해당 코드들을 더욱 더 깊이 이해하게 될 것이다. 이와 더불어 만약 지저분 해진 설계/구조로 인해 신규 기능 추가가 어렵다면 당연히 고민 없이 리팩토링을 실시해야 할 것이다.
- 버그 수정
버그를 수정하려고 할 때 만약 코드의 기능이나 설계/구조를 이해하기 어렵다면 리팩토링을 이해 이해하기 쉬운 구조로 변경해야 한다. 그 이후부터는 버그를 찾거나 수정하기 조금 더 수월해 진다.
(항상 이렇게 하려고 노력하지만.... 현실은 긴급으로 처리해 해달라는 요청으로 인해 기존 코드에서 현재 문제가 되고 있는 부분만 살짝 고쳐 버그를 고치는 일이 허다하다.ㅜㅜ)
- 코드 검수
보통 정기 코드 검수 일정이 있는 경우 내가 작성한 코드 이외에 다른 사람들이 작성한 코드를 검수해야 하는 경우도 있다. 이러한 코드 검수 작업을 통해 동료 개발자 혹은 선임 개발자들로부터 새로운 지식을 전수받기도 하고 그들의 경험/지식을 통해 새로운 영감과 아이디어를 받기도 한다. 그렇기에 이런 코드 검수가 자주 이루어 질 수록 코드 품질이 좋아지고 기존 개발업무의 난이도가 이전보다 쉬워지게 될 가능성이 크다.
리팩토링은 코드 검수의 효과를 극대화 하는데 큰 도움을 준다. 리팩토링을 하면 다른 개발자가 작성한 코드를 검수 하기 쉬워질 뿐 아니라 리팩토링 이전에는 생각할 수 없었던 높은 수준의 아이디어도 이끌어 낼 수 있다. 또한 리팩토링은 더 구체적인 코드 검수 결과를 이끌어 낼 수 있다.
반응형댓글