리팩터링 2판 리뷰 - 3장

리팩터링 2판(마틴 파울러 저)을 읽고 작성한 리뷰입니다.

앞선 1, 2장에선 리팩토링의 예시와 왜 리팩토링이 필요한지에 대한 내용과 대략적인 적용 방법이다.

3장에선 대체 이 리팩터링을 언제 적용 할 까?에 대한 내용이다.

리팩터링을 해야되는 기준을 명확하게 규정 할 수 없다. 이 책에서는 악취가 나면 바로 리팩터링할 시점이라고 주장한다. 여러가지 예시가 등장하는데 현재 나의 개발 경험상 몇 가지만 공감 할 수 있었다. 나머지는 경험이 부족한 탓인지 미래에 대한 예방이라고 생각하고 대충 읽고 넘어갔다. 하지만 몇 가지 예시 중에선 정말 공감이 됬다. 역시 겪어보고 해결책을 찾아야 잘 읽히는것 같다.

악취의 몇 가지 종류

이름

코드를 표현하는 데 가장 중요한 요소 "이름"이다. 모듈 명, 클래스 명, 함수 명, 변수 명등 어떠한 일을 하는지 이름을 잘 지어줘야 한다. 혼란스러운 이름, 어떤 역할을 하는지 모르겠는 이름은 당장 수정한다. (실제로 리팩터링 도구에서 가장 많이 사용되는 필드 바꾸기, 변수 이름 바꾸기라고 한다)

중복코드

코드를 읽다 비슷한 코드를 두 가지를 발견하게되면 어떠한 차이점 있나 살펴보게 된다. 이는 중복된 코드에서 로직이 변경사항이 생긴다면 중복되서 사용되는 곳을 찾아가 다시 수정해야 한다. 이는 미처 수정 못해서 생기는 버그를 유발 할 수도 있고 중복된 곳을 찾아다니며 수정해야되는 생산성 낭비이다. 그러므로 하나로 통합하여 함수 추출하기로 수정하도록 해야 된다. 만약 완전히 똑같지 않다면 공통된 기능만 함수로 추출한다.

긴 함수

함수 내부 로직이 많아 코드가 길어진다면 어느 곳에서 버그가 발생하는지 디버깅이 어렵기도 하고 코드를 분석하는데에 있어 어려움이 있다. 함수가 길어지게 된다면 기능 별로 함수를 추출하여 쪼개야 한다.

전역 데이터 사용

전역 데이터는 코드 어디서든 접근이 가능하고 수정이 가능하기 때문에 사용하기 까다롭다. 전역 데이터를 오염 시킬 수 있는 코드는 지양한다.

이후에도 몇 가지의 리팩터링을 해야되는 시점이 제시되는데 아직까지 공감이 되질 않아 글이 적히질 않는다..(ㅠ)

느낀점

이 책을 읽기 전까진 중복된 코드나 긴 함수들은 아 나중에 고쳐야지하고 넘어간다던가 심지어 나중에 발견해도 모르는 척(기능 구현하기 바쁘니까...) 넘겼는데 이제 그 시점에 리팩터링을 진행해야 될 것 같다. 이 책에선 캠핑장 규칙을 예시로 드는데 처음 왔을 때 보다 깨끗하게 하고 떠난다. 라는 말이 캠핑족 사이에는 있다고 한다. 개발자들도 악취가 나는 코드를 보면 처음 봤을 때보다 더 개선하고 떠나라는 말 같은데 어느정도 공감이 된다. 리팩터링의 이점도 공감이 되고 현업때 이미 범접을 수 없을 정도로 설계가 무너져서 새로운 기능을 추가 할 때 고생한 기억이 있기 때문에 앞으론 리팩터링을 적용해봐야 겠다.