리팩터링2 2장 리뷰

리팩터링 원칙

리팩터링 리팩터링 하는데 정의가 무엇일까? 정의는 다음과 같다.

소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다.

 

여기서 겉보기 동작은 그대로 유지한 채. 라는게 중요하다. 성능을 개선하고 기능을 추가하는 거은 리팩터링이 아니다. 우리는 커밋을 할때도 기능 추가와 리팩터링 두 개의 모자를 구분해서 바꿔써야한다.

 

대부분의 회사에서 하는일은 유지보수다. 그리고 기능추가를 하려고 하는데 코드가 지저분할 경우가 있을 것이다. 그럴때는 먼저 리팩터링을 하자. 대단한 리팩터링을 얘기하는 것이 아니다. 함수가 좀 크다면 함수를 나누고 변수명이 모호하다면 변수명을 바꾸고 이런 기본적인 것들이라도 먼저 적용하면 훨씬 깔끔해진다. 이 이후에 코드를 보면 훨씬 잘 보인다. 실제로 이 방법을 알고 난 후에 리팩터링을 한 경험이 있는데 엄청 좋았다.

리팩터링하는 이유

책 내용은 어차피 깃헙에 정리했기때문에 하고 싶은 얘기만 하겠다. 

내가 생각할 때 리팩터링하는 이유는 크게 두가지다. 첫번째는 코드를 이해하기 쉬워지기 때문이고 두번째는 버그를 막기위해서다.

 

첫번째부터 얘기해보자. 리팩터링하면 코드를 이해하기 쉬워지는건 사실 당연하다. 리팩터링했는데 더 읽기 어려워졌다면 그건 실패한 리팩터링이다. 근데 코드를 이해하기 쉬워지는게 그렇게 중요할까? 아무리 안좋은 코드라도 보다보면 익숙해진다. 여기서 익숙해진다는데 집중해보자. 코드에 익숙해진사람은 크게 불편함을 느끼지 않다면 리팩터링할 필요가 없을까? 좋은 코드는 처음 본 사람도 짧은 시간안에 이해할 수 있는 코드다. 익숙해질때까지 많은 시간이 걸린다면 이건 시간적으로도 손해다. 개발자가 소수일때는 상관없지만 10명이상이라고 해보자. 그리고 회사는 계속해서 개발자가 입사하고 퇴사한다. 입사할때마다 그 코드를 이해하는데 드는 시간은 굉장히 인력적으로 손해다. 또 만약 중간에 그 코드를 알고있는 개발자가 나가게 된다면 어떻게될까? 아무도 건드릴수없다. 그리고 이런 지뢰 코드는 대부분의 회사에 존재한다. 

 

두번째를 보자. 버그를 막기위해서 리팩터링을 한다? 우리는 사람이기 때문에 실수하고 버그도 계속해서 나온다. 테스트코드가 있어도 마찬가지다. 버그없는 프로그램은 없다. 그리고 프로그램이 유지보수되면서 버그들은 새롭게 생기고 그 버그들을 계속해서 수정해야한다. 만약 코드가 지저분하다면 어디서 버그가 발생했고 어떻게 고쳐야하는지도 알기 어렵다. immutable, 함수형 프로그래밍 같은 것들이 각광받는 이유이기도 하다. 버그가 계속 발생하고 그걸 매꾸는건 굉장히 일시적인 행동이다. 물론 상황에따라 그런 선택을 해야만 하는 경우도 많다. 하지만 근본적으로는 좋은 코드로 탈바꿈해야만한다. 그렇지 않으면 계속해서 버그가 발생하고 이걸 디버깅하는데 많은 시간이 소요될것이다. 여유가있다면 리팩터링하고 여유가 없어도 리팩터링을 해야만한다. 물론 거대한 코드를 한번에 리팩터링할 수는 없다. 조금씩 고쳐나가면 된다.

 

이 두가지로부터 리팩터링의 궁극적인 목적이 나온다. 그건 바로 시간 단축이다. 잠깐 다른데로 빠지자면 웹뷰를 사용하는 가장 큰 이유중 하나도 경제적인 측면 때문이다. 

언제 리팩터링해야할까?

책에서는 3의 법칙을 소개한다. 따로 더 할말은 없어서 설명은 생략한다.

1. 처음에는 그냥 한다. 
2. 비슷한 일을 두 번째로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다. 
3. 비슷한 일을 세 번째 하게 되면 리팩터링한다.

 

사실 책에서 엄청 상세하게 경우를 나눠서 소개했다. 나는 그 중 몇가지만 가져와서 얘기해보겠다.

 

계획된 리팩터링과 수시로 하는 리팩터링

기본적으로는 수시로 리팩터링해야한다. 시간내서 하는게 아니다. 함수를 만들고 두가지 이상의 역할을 한다고 느끼거나 컴포넌트가 비대해졌다고 느끼면 바로 리팩터링을 적용하자. 그리고 아무리 잘 작성된 코드라도 기능이 추가됨에 따라 끊임없이 리팩터링해야한다.

뛰어난 개발자는 새 기능을 추가하기 쉽도록 코드를 수정하는 것이 그 기능을 가장 빠르게 추가하는 길일 수 있음을 안다.

기본적으로는 수시로 하는 리팩터링이 좋지만 계획된 리팩터링도 필요하다. 내가 소홀했을 수도 있고 팀이 소홀했을 수도 있다. 이럴때는 계획을 잡고 리팩터링을 하는 것도 좋은 방법이다.

오래 걸리는 리팩터링

저자는 오래 걸리는 리팩터링에 회의적이라고 한다. 그리고 조금씩 개선해나가자는 의견이다. 여기서 또 중요한게 있다. 어떻게 조금씩 개선해나갈 수 있을까? 그건 커밋을 잘게 쪼개고 기능에는 문제없게 리팩터링했기 때문이다. 단, 기능을 건드려야하는 경우라면 시간이 필요하다. 이런경우라면 먼저  코드를 개선하고 그 이후에 기능을 건드리자.

코드리뷰에 리팩터링 활용하기

리팩터링은 다른 이의 코드를 리뷰하는 데도 도움이 된다. 보통은 몇 가지 개선사항들을 제시하는데서 그치지만 실제로 리팩터링을 해보고 적용하면 훨씬 더 코드베이스에 긍정적인 영향을 끼친다. 단 이런방법은 pr, mr같은 방식보다는 페어 프로그래밍에서 효과적이다.

관리자에게는 뭐라고 말해야할까

책에서는 관리자가 기술에 정통하지 않다면 관리자에게 리팩터링한다고 말하지 말라고 한다. 그리고 이건 하극상이 아니라 프로 개발자로서 내리는 판단이라고 한다.

사실 좀 어려운문제다. 개발바닥의 호돌맨님은 이런상황에서 설득시킬 자신이 없어서 그냥 주말에 일을 한다고 하셨다. cto입장인데도 이게 쉽지 않다. 그러면 직급상 cto보다 아래인 경우가 99퍼센트일텐데 이런 사람들은 어떻게 해야할까?? 사실 정답은 없다. 다만 관리자에게 속이는게 옳은일인지는 잘 모르겠다. 몰래 리팩토링을 하는 경우 당연히 다른 일을 할 시간이 부족하고 많은 기능을 치지 못한다. 그렇게 되면 관리자는 그 사람을 코딩속도가 느린사람으로 판단할 수도 있다. 사내 평가도 있겠지만 관리자의 평가는 그 이상으로 중요하지 않나??(사실 이건 잘 모르겠다.) 평가뿐만이 아니라 개발자는 어쨋든 개발을 하는 사람이고 전체적인 회사의 상황이나 우선순위등을 관리자만큼 잘 알지는 못한다. 그렇기 때문에 소통이 필요하다. 서로 입장이 다르다보니 서로 의견충돌이 있을 수도 있다. 하지만 그런 논의는 가치있는 논쟁이라고 생각한다. 하지만 항상 관리자가 항상 허락해주지 않는다면 어떻게 해야할까?. 켄트백은 리팩터링을 하지 않으면 결국 그 프로젝트는 망한다고 했다. 이런 상황에 관리자의 의견을 무조건 따라가는 것은 옳지 않다. 개발환경이나 개발자의 불편함도 있겠지만 무엇보다 회사의 입장에서도 좋은 것이 아니다. 사실 나에게 아직 이걸 판단하기에는 경험이 너무 부족하다. 지금 생각은 관리자에게 얘기를 하지만 어쩔 수 없는 경우에는 선의의 거짓말을 해야할때도 있지 않을까?? 라는 생각이든다.

리팩터링하지 말아야 할 때

사실 설명하지 않아도 알고 있다. 변경사항이 거의 없고 그냥 호출해서 잘 쓰고 있으면 리팩터링 할 필요가 없다. 이게 영원히 지속되도 상관없다는 것은 아니다. 정말 여유가 난다던가(그럴리가 없겠지만...) 그 코드에 버그가 발생하거나 기능추가를 해야한다면 그 때 리팩터링하자.

 

리팩터링 시 고려할 문제

새 기능 개발 속도 저하

리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다. 경제적인 측면에서 하는 것이다. 다른 이유가 아니다. 위에서도 비슷한말을 해서 더 자세한 설명은 생략하겠다.

브랜치

팀원들이 기능별로 브랜치를 만들고 main브랜치에 머지하는 방법이다. 이 방법의 단점은 독립적인 브랜치에서 코드를 작성하는 시간이 길어질 수록 통일하기 어렵다는 것이다. 특히나 리베이스를 사용하고 오랫동안 머지를 하지 않았다면 진짜 지옥이다. 그렇기 때문에 빨리 합치면 좋다. 여기서 ci, cd의 중요성이 나오게 된다. ci, cd가 잘 갖춰진 팀이라면 이런 일이 발생하기 어렵다. 또한 pr도 너무 큰 단위로 나누면 안된다. 최대한 기능별로 쪼개서 나가자.

테스팅

테스트코드가 있으면 리팩터링의 불안감을 많이 없앨 수 있다. 그런데 프론트에서는?? 글을 좀 적었다가 주제에 맞지 않는 것 같아서 적지는 않겠다. 테스트코드가 없다면 테스트코드를 조금씩이라도 적용하자!!

레거시 코드

레거시 시스템을 파악할 때 리펙터링이 굉장히 도움된다. 그런데 테스트가 하나도 없다면 어떨까?? 테스트코드없이 대규모 시스템을 리팩터링하기엔 너무나도 위험하다. 이 문제의 정답은 테스트 보강이다.

쉽게 해결할 수는 없다. 테스트코드가 고려되지 않은 코드는 쉽게 테스트할 수 없다. 그래서 비집고 들어가서 테스트를 추가하고 테스트를 추가할 수 없다면 어쩔수없지만 그냥 리팩터링해야한다.

서로 관련된 부분끼리 나눠서 하나씩 조금씩 리팩터링하자. 모든 코드를 한번에 바꾸는 것을 저자는 추천하지 않는다. 캠핑규칙에 따라 처음보다 정돈된 상태를 만들면 된다.

리팩터링과 성능

대부분의 프로그래밍은 극히 일부의 코드에서 대부분의 시간을 소비한다. 그래서 전체를 고르게 최적화할 필요는 없다. 의도적으로 성능 최적화에 몰임하기 전까지는 코드를 다루기 쉽게 만드는데 집중하자. 만약 코드가 다루기 쉬운 상태가 된다면 최적화하는데도 유리해진다.

깃헙

https://github.com/yoonminsang/refactoring-2/blob/main/yoonminsang-robin/2/README.md

GitHub - yoonminsang/refactoring-2: 리팩토링2 스터디