220806 TIL 리팩터링을 왜 해???

오늘은 정말 오랜만에 책을 읽었다.!!

이유는 어제 동료들의 액션플랜에 책을 읽는다는 액션플랜이 많아서 나도 이제는 시간을 내서 책을 읽어야겠다는 생각을 했다.

그리고 골든벨 우승 상품으로 주신 책도 다 읽지 못했기 때문에 책값이 아깝지 않게 조금씩이라도 읽어야 겠다는 생각떄문에 책을 펼쳤다.

 

어떤 책을 읽을까 하다 실용주의 프로그래머의 목차를 보던 중 리팩터링 주제가 있어서 읽어봤다.

리팩터링 주제를 선택한 이유는 바로 어제 로그인 / 회원가입 과제를 리팩터링 하다 많은 오류를 마주하고 멘털이 부서졌기 때문이다.. 

그래서 잘 작동하기만 하면 됐지 리팩터링 왜 해??? 라는 생각이 내 머릿속 박혀버렸다.. 

그래도 분명히 리팩터링 하는 과정이 필요하니까 이렇게 책으로도 써져있고 트레이너님들이 시키는 게 아닐까? 

 

 

리팩터링 왜 해?

우선 리팩터링을 하는 이유는 프로그램이 발전함에 따라 초기에 내린 결정을 다시 고려하여 코드의 일부분을 다시 작성할 일이 생기기 때문이다.

코드는 정적인 존재가 아니고 발전해야 한다.

코드는 정적인 존재가 아닌 발전해야 한다는 글을 보고 내가 생각한 잘 작동하기만 하면 됐지 라는 생각을 바로 깨부셨다.

 

 

리팩터링이란

마틴 파울러가 정의한 리팩터링

밖으로 드러나는 동작은 그대로 유지한 채 내부 구조를 변경함으로써 이미 존재하는 코드를 재구성하는 체계적 기법

이 정의에서 핵심적인 부분이다.

"밖으로 드러나는 동작은 바뀌지 않는다. 즉 기능을 추가하는 작업이 아니다." 

리팩터링을 한다고 코드를 전체적으로 다시 쓰는게 아니라, 정확한 목적을 해야 한다.

 

 

리팩터링은 언제하는가?

나는 지금 리팩터링을 내가 목표했던 일단 다 완성한 뒤나, 트레이너님이 코드 리뷰를 해주시면 그 리뷰에 맞게 리팩터링 하고 있다.

 

이 책에서는 리팩터링을  언제나 바로 지금이 최적기이기 때문에 무엇이든 잘못되었다고 생각이 들 때 주저하지 말고 변경하라고 한다.

예를 들어서 두 가지로 분리했던 클래스가 알고보니 한 클래스로 합쳐져야 한다는것을 발견했을때 바로 리팩터링하는게 좋다

근데 나는 코드를 작성하다 뭔가 잘못되었다는 것을 인지했어도 일단은 완성하는게 목표라고 생각해서 수정하는 작업은 일절 하지 않았다.

괜히 수정하다 더 꼬이고 시간만 쓰다 완성도 못할까봐...

 

근데 나만 이렇게 코드를 수정하는것을 주저하는게 아니였다.

많은 개발자들이 코드에 조금이라도 개선할 부분이 있다는 이유만으로는 다시 코드를 열기를 주저한다고 한다.

잘 작동하는거 건드려서 괜히 오류라도 생기면 어떡하나? 라는 마음은 다 똑같은거 같다.

 

일찍, 자주

리팩터링은 일찍, 자주 하는게 좋다.

나처럼 코드를 다 완성하고 리팩터링을 하면 신경 써야하는 문제들이 더 많아진다.
특히 신경 써야 하는 의존성 문제가 많아졌을 때 리팩터링 하는것은 시간이 오래 걸린다. 

그래서 문제가 작을때 리팩터링을 진행하는게 훨씬 쉽다고 한다.

 

저 말에 공감이 되는게 과제를 진행하면서 다 완성하고 리팩터링을 했을때는 정말 괴로웠다.

어제 로그인 회원가입 리팩터링 하다 몇시간을 고생한걸 생각하면... 

하나를 고치면 의존 관계에 있는 코드들은 다 고쳐야한다.

 

지금 내가 작성한 코드의 규모가 작아서 금방할 수 있었지만 더 큰 프로젝트였다면 리팩터링하는데 엄청 많은 시간을 쓸 수 있겠구나 생각했다.

그래서 리팩터링은 바꿔야 겠다고 생각이 들때 바로바로 바꿔주는게 최고인것같다.

 

 

어떻게 하는가?

1. 리팩터링과 기능 추가를 동시에 하지말라.

 

2. 리팩터링 하기 전 테스트가 있는지 확인 하고 자주 테스트를 하라.

테스트를 자주 해야 내가 바꾼것 때문에 무언가 작동이 안될 경우 그 사실을 빨리 알 수 있다.

 

3. 단계를 작게 나누어서 신중하게 리팩터링을 해라. 

변수명 하나 바꾸기, 메서드 하나 쪼개기 뜽과 같은 작은 단위로 작업을 해야 한다. 

리팩터링은 작은 변경들이 많이 모여서 커다란 규모의 변화를 낳는 일이 자주 발생한다고 한다. 

하지만 단계를 작게 나눈 뒤, 한 단계가 끝날 때마다 테스트를 돌려서 확인을 해준다면 디버깅 하는 시간을 절약할 수 있다.

 

 

액션플랜

앞으로 책을 하루에 30분씩 읽겠어! 라고 한다면 나는 분명 지키지 않을게 뻔하다.

하루에 30분 책을 읽는다는게 쉬워보이지만 매우 어렵다.

 

그렇기 때문에 내가 지킬 수 있는 최소한의 작은 단위는 실용주의 프로그래머 책의 주제 한개를 선택해서 읽는거다.

실용주의 프로그래머 책 같은 경우 하루에 부담되지 않을 정도의 양으로 주제가 나눠져 있기 때문에 이 정도는 지킬 수 있다고 생각한다.