[OOP Software Meets Business 2014] 마틴 파울러가 말 하는 리팩토링의 절차와 중요성.

이 글은 Youtube 데브원영이라는 채널에서 본 마틴 파울러의 리팩토링의 중요성 을 보며 글로 정리하며 제 개인적인 생각을 추가한 글 입니다. 자세한 사항 혹은 원본을 보고싶다면 아래의 링크로 들어가서 확인해주세요

 

• 데브 원영 마틴 파울러 리팩토링의 중요성 -한글 자막
• OOP 2014 Martin Fowler OOP2014 Workflows of Refactoring

가장 기본적인 리팩토링

리팩토링이라고 하면 가장 먼저 생각나는게 무엇일까?

 

바로 TDD이다.

 

TDD는 다음과 같은 Cycle이 있다.

Red

Make It Run !!

실행되는 실패하는 코드를 작성한다.

Green

Make It Work !!

기능적으로 정상 동작을 수행하는 코드를 작성한다.

Refactor

정상적인 동작을 하는 코드를 더 깔끔하게 한다.

 

이런 TDD 에서 Refactor이라는 과정이 존재하는데, 여기서 생각을 해볼게 있다.

 

왜 우리는 코드를 구현할 때 Green과 Refactor 두 단계로 나눌까?

 

이걸 알기 위해서는 리팩토링이 무엇을 하는가를 알아야 한다.

리팩토링은 뭘까?

테스트 주도 설계 TDD 를 창시해낸 켄드 벡이 이야기 하길, 모든 프로그래밍에는 2가지의 모자가 있다는 것을 알아야 한다.

그리고 그 모자 중 하나가 바로 리팩토링이다. 라고 했다.

1. Add Function Hat
2. Refactoring Hat

Add Function Hat

기능 개발 모드에서는 테스트가 성공하도록 개발하거나 모든 상황에서 개발을 하는 행위인 모드이다.

 

Refactoring Hat

리팩토링 모드에서는 새로운 코드를 만드는 것이 아니라 기능은 이전과 동일하지만 소프트웨어 내부 설계만 더 높은 수준으로 고도화시키는 모드이다.

 

라고 불리는 2가지 모드가 있고, Refactoring Hat을 썼을 때는 버그를 찾았다고 해서 당장 그걸 수정하면 안된다.

그 행동은 기능을 변경하는 행동이고 결국 Refactoring Hat의 본질을 흐트리는 것이 된다.

만약 버그를 고치고 싶다면 Refactoring Hat에서 Add Function Hat으로 모자를 바꿔야 한다.

다시 TDD로 돌아가서

위에서 본 모자를 TDD에 씌워보면 이런 형태가 되고 이 것을 우리는 TDD Recatoring 라고 부른다.

2가지 상황의 리팩토링

위에서 본 TDD 말고 또 다른 상황에서의 리팩토링을 이야기 해보겠다.

첫 번째 리팩토링 : Yuck

처음에 Yuck 라는 단어가 뭔지 몰라서 사전에 찾아보니 위와 같다고 한다.

 

우리가 역한 것을 보았을 때, Yuck

 

만약 우리가 코드를 정말 잘 짜는 좋은 개발자라고 가정해보자.

 

우리는 특정 코드를 보고 아주 못생겼다는 생각이 들 때가 있다.

변수명이 아주 제멋대로네?
아니, 함수 네이밍이랑은 전혀 다른데?
와.. 이건 진짜 너무 비효율적이야..

이런 것을 보면 우리는 뭔가 이상한 것 같다고 느끼고 그대로 두고싶어 하지 않는다.

 

그리고 이걸 고치려고 하는데 이 과정에서 리팩토링을 해야겠다는 생각이 들곤 한다.

 

이런걸 Litter-Pickup Rectoring (쓰레기 줍기) 리팩토링 이라고 부른다.

 

보이 스카웃 룰에는 항상 머문 자리는 깨끗히라는 룰이 있다.

 

그러기 위해서 우리는 우리가 머물었던 자리에 쓰래기를 줍고 깨끗하게 하려 노력하는데, 핵심은 바로 지속이다.

 

우리는 리팩토링 할 때 오해하는 것이 하나 있다.

 

만약 리팩토링을 해야한다면 완벽하게 해야 한다?

 

절대 아니다.

 

중요한 것은 할 수 있는 만큼 (최소한의 변경도 좋으니까) 하는게 좋다.

 

이렇게 최소한의 변경이 이어진다면 적어도 전보단 좋아지게 되고 결국 이렇게 작게 작업하던 것이 크게 모여 하나의 견고한 소프트웨어를 만들기 때문이다.

 

만약 이게 안되고 한 번에 크게 리팩토링을 수행하려 한다면 아주 힘든 결과를 초래할 수 있다.

I don't understand

여러분은 이런 상황에 놓인 적이 있을 것이다.

이 코드는 진짜 무슨 동작을 하는지 모르겠어 ;;
이건 마치 퍼즐 같아
무슨 추리소설 보는거 같아. 새로워

이런 상황에서 겪게 되는 것이 바로 리팩토링이다.

 

우리는 위와 같은 코드를 마주했을 때, 아주 어렵겠지만, 많은 시간을 들여서 특정 로직에 대한 이해가 된다.

그리고 실타래같던 코드가 하나 둘 씩 풀리게 되면서 우리는 결국 이해할 수 있게 되는 경험을 해본 적이 있을 것이다.

 

문제는 코드는 잘 동작한다는 것이다.

 

여기서 코드는 잘 동작 하고 이해는 했겠지만 다른 사람들은 내가 아니다.

 

다른 사람이 또 이 코드를 보게 된다면 이해하는데 시간이 걸릴 것이고 아주 비효율적인 상황이 일어나게 된다.

 

그래서 이런 과정에 다른 사람들을 이해시키기 위한 방법으로, 해당 로직을 이해하기 쉽게 리팩토링 해야한다.

 

이런과정을 바로 Comprehension Refactoring (이해를 위한 리팩토링) 이라고 한다.

이건 Yuck 완전 다른 개념이지만 둘 다 역겨운 코드는 맞다.

언제 리팩토링을 해야할까?

이제 이런 코드를 보고 우리는 리팩토링 해야겠다고 느꼈잖다. 근데 언제 리팩토링을 해야할까?

단순히 변수명이 문제가 되면 그것은 판단 기준을 적용시키지 않고 당장 고치면 되지만, 그게 아닌 경우에 우리는 선택을 해야한다.

그 선택 기준으로 판단해야될 것은 지금 고쳐야하는가? 를 판단해야됨.

 

우선 결정해야할 점은 내가 현재 하는 일에 영향을 받지 않고 쉽게 고칠 수 있는가?를 판단해야된다.

 

그렇다면 당장 리팩토링을 시작해야하고 그게 아니라면 조금 고려해보아야 한다.

하지만

리팩토링은 어느 특정 시점에 계획해서 하는 것이 아니다.

위에서 말 했던 쓰래기 줍기 처럼 항상 함께 가야 하는 것이다.

왜 리팩토링은 중요한가.

초기에 개발자들은 코드를 변경해야 하는 것이 Rework 라고 생각되던 떄가 있었다.

이미 잘 동작하는 코드를 다시 한 번 시간을 쏟아서 변경하는 것은 불필요하다고 생각이 되었지다.

왜냐하면 한 번 개발 한 코드를 왜 또 봐야하냐는 생각 때문에.

그럼에도 불구하고 왜 리팩토링을 해야하는지 이유가 있다.

Design Stamina Hypothesis

Design Stamina Hypothesis 디자인 스태미너 이론은 마틴 파울러가 제안한 디자인과 개발자의 스트레스에 관련된 이론이다.

소프트웨어 설계에 신경쓰지 않으면 생산성이 시간이 지날 수록 떨어진다는 것

 

좋은 디자인은 초기에 디자인을 하기위한 스트레스가 들어가지만 시간이 지날 수록 그 생산성이 높아지는 반면, 디자인이 없다면 초기의 생산성은 좋아지지만 뒤에 갈 수록 생산성이 현저하게 떨어진다는 내용이다.

왜 이게 리팩토링과 관련이 있을까?

 

디자인이 없을 때는 개발자가 기능에 대한 개발을 하면 할 수록 코드가 쌓이게 된다.

 

여기서 리팩토링이 없다면 불필요한 코드가 쌓이게 되면서 모듈끼리의 결합도가 증가 한다거나 몸집이 거대해져 보기도 싫은 코드가 될 수 있다.

 

하지만 여기서 좋은 설계와 리팩토링이 함께 가게 된다면 좋은 설계로 모듈 결합도를 낮추고 리팩토링을 통해서 코드를 항상 깔끔한 상태로 유지하고 좋은 아키텍쳐로 방향을 유도하기 때문에 결과적으로는 매우 좋은 것이다.

리팩토링의 장점은?

• Quality
• Clean Code
• Professionalism
• Right Thing

리팩토링이라고 하면 위의 것들을 생각하는데, 마틴 파울러는 이런 것들을 생각하는 순간 리팩토링은 망했다. 라고 한다.

이것보다 경제성으로 접근하는게 맞다.

Economic

리팩토링은 많은 개발자가 새로운 기능을 더 쉽고 빠르게 적용하기 위함이다.

만약 리팩토링을 하지 않는다면, 새로운 기능이 추가될 때 마다 지속해서 이상한 코드가 쌓이고 개발자들은 더 쳐다보기 싫어지는 코드가 된다.

 

그럼 결국 생산성이 떨어지고 조직에서는 이를 비용적으로 감당해야 하는 상황이 생기게 된다.

끝으로..

개발자는 전문가이다.

전문성이 있는 개발자들에게 개발자로 책임감이 있다면 항상 코드를 깨끗하게 유지하길 바란다.

이것이 바로 개발자를 전문가로 만들어주는 길이 된다.

만약 개발자가 깨끗하게 안 하면 기업과 조직의 돈을 낭비하는 도둑과도 같다.