리펙터링 2판 - 2~3장

리펙토링은 무엇인가에 대해 정의를 내리는듯한 설명을 다방면에서 계속한다. 다른 문장이지만 같은 뜻을 나타내고 있는 문장이 많다. 

리펙토링에 대해 중요시하지 않거나, 리펙토링을 처음 접하는 사람에게는 이해가 안 되는 방법이기 때문에 책에서 여러 방면으로 리펙토링에 대해 설명해주고 있다고 생각한다. 이 책에서 리펙토링에 대해 다방면으로 설명을 하면 이해가 되는 부분이 있고, 그렇지 않은 부분이 있다. 하지만 리펙토링을 하지 않았을 때를 생각하고 그 후를 조금이나마 예측을 한다면 하는 것이 분명히 낫다는 것을 알 수 있었다.

 

 

2장. 리팩터링 원칙

 

1장에서 리팩터링을 코드와 함께 예시를 들어 설명하면, 여기서는 글로써 설명을 하게 된다.

리팩터링 : 소프트웨어의 겉보기 동작은 그대로 유지한채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

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

 

한 번에 바꿀 수 있는 작업을 수많은 단계로 잘게 나눠서 작업하는 모습을 처음 접하면 리팩터링 하는 것이 비효율적이라 생각하기 쉽다. 하지만 잘게 나눔으로써 오히려 작업을 더 빨리 처리할 수 있다. 단계들이 체계적으로 구성되어 있고, 무엇보다 디버깅 하는데 시간을 뺏기지 않는다고 설명되어 있다.

리펙터링 목적은 코드를 이해하고 수정하기 쉽게 만드는 것이다. 리팩터링의 목적을 생각한다면 리팩터링 전과 후의 기능이 '≒' 이 아닌 '=' 으로 표현된다고 생각했다.

 

여기서 글쓴이는 개발시에 목적이 '기능추가'와 '리팩터링'을 명확히 구분한다. 기능 추가는 기존 코드를 건드리지 않은 채 새기능을 추가하고, 반대로 리팩터링을 하면 기능 추가를 하지 않은 채 코드 재구성에만 전념한다.

 

리팩터링을 하는 이유

1. 소프트웨어 설계가 좋아진다.

2. 리팩터링하면 소프트웨어를 이해하기 쉬워진다.

3. 리팩터링을 하면 버그를 쉽게 찾을 수 있다.

4. 리팩터링을 하면 프로그래밍 속도를 높일 수 있다.

 

소제목을 나열해 봤는데, 소제목에 대한 설명을 책에 적혀 있어 납득이 갈만한 설명이 적혀져 있다. 그래서 도서관, 서점에 비유해서 적어보려한다.

많은 도서관, 서점들은 엄청나게 많은 책이 있지만, 관리하고 정리한다. 거기서 새로나온 책들은 추가하기도하고, 오래된 책들은 제거하기도 한다. 하지만 모든 도서관들이 완전히 똑같이 책을 정렬하여 관리하지 않는다. 

여기서 도서관, 서점이 소프트웨어이고 책을 정렬하는 방식이 리팩터링이라고 생각한다.

만약 리팩터링을 하지 않는 도서관, 서점이라면 많은 사람들이 원하는 책을 쉽게 찾을 수 없을 뿐더러, 새로운 책이 생겼을 때 추가하기도, 오래된 책을 제거하기도 어려울 것이다.

 

하지만 여기서 가장 기억에 남는 내용은, 리팩터링을 하는 이유는 남을 배려하는 것도 있지만 그 남이 나 자신일 때가 많다는 것이다. 

 

 

 

 

 

언제 리팩터링을 해야하나?

1. 준비를 위한 리팩터링: 기능을 쉽게 추가하기

2. 이해를 위한 리팩터링: 코드를 이해하기 쉽게 만들기

3. 쓰레기 줍기 리팩터링

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

5. 오래걸리는 리팩터링 

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

7. 리팩터링 하지 말아야 할 때

 

여기서도 리팩터링에 대한 소제목이 상당히 많다. 리팩터링을 언제 해야하나 하지말아야 되냐에 대한 내용이다.

여기서도 내 방식대로 정리를 하자면, 리팩터링이 필요하면 하는 것이다.

이상한 소리일 수도 있겠지만 책상 정리를 한다고 가정 했을 때, 언제 책상정리를 보통 하게 될까? 자신이 원하는 물건을 찾기 어려울 때 보통 한다고 생각한다. 그럼 책상을 정리 하지 않는 사람은 뭐냐? 라고 물어본다면 그 사람들은 그렇게 어질러져 있어도 자신이 원하는 물건을 잘 찾기 때문에 안한다고 생각합니다. (물론 정리하지 않는 그 사람만 물건을 잘 찾는다면 협업을 하기에는 좋지 않겠지만)

결국 리팩터링을 언제 해야하는지에 대한 것을 쉽게 표현하자면 코드에서 원하는 것을 쉽게 얻지 못할 때 정리하는 것 이라고 생각 하였습니다. 

 

리팩터링 시 고려할 문제

리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것이다.

사람들이 빠지기 쉬운 가장 위험한 오류는 리팩터링을 '클린코드'나 '바람직한 엔지니어링 습관'처럼 도덕적인 이유로 정당화 하는 것이며, 리팩터링은 오로지 경제적인 이유로 하는 것이다. 리팩토링을 자주하도록 노력하여 기능시간을 줄이고, 버그 수정 시간을 줄여준다. 동력은 어디까지나 경제적인 효과이다.

리팩터링 할지 말지를 판단하는 능력은 수년에 걸친 경험을 통해 서서히 형성된다.

리더는 리팩터링 경험이 부족한 이들이 이런 능력을 빠르게 갖추도록 개발 과정에서 많이 이끌어줘야한다.

(좋은 내용들이 뒤에 좀 더 있지만, 스스로 설명이 되지않는 부분도 있기에 앞으로도 애써 정리하지 않으려 합니다.)

 

 

추가적으로 리팩터링에 대해 다양한 이야기를 말하는데 아래의 두 문구가 많이 와닿았다.

• 팀으로 개발하면서 리팩터링을 하려면 각 팀원이 다른 사람의 작업을 방해하지 않으면서 언제든지 리팩터링 할 수있어야 한다.
• 시스템에 대해 잘 알더라도 섣불리 추측하지 말고 성능을 측정해 봐야한다.

리팩터링은 넓게 보기도 해야한다는 것을 알려줄 뿐더러 돌다리도 잘 두둘겨 가야한다는 교훈을 잘 말해주는 문구였다.

 

 

 

3장. 코드에서 나는 악취

리팩터링을 '적용방법을 아는 것'과 '제때 적용 하는 것'은 다르다고 책에서는 설명한다. 제때 적용 하는 것에 대한 명확하게 정립된 규칙이 없다는 내용도 덧붙인다.

축구해설가와 축구선수의 차이라고 생각이 들었다. 축구해설가는 기술에 대한 적용방법을 많이 알고 있지만, 축구 시합에서 기술을 제때 적용하는 것은 잘 하지 못할 것이다. 이론과 실전은 다르다 라는 표현과 일맥상통한게 아닐까?

 

여기서는 리팩토링을 해야하는 명확한 정립된 규칙을 확립하기 어렵기 때문에 징후 즉, 냄새라고 표현을 한다. 여기서 냄새에 어떤 리팩토링에 대한 기술은 6~12장에 서술이 되어있고 3장에서는 흔히 말하는 냄새의 종류 위주로 설명이 되어있다.

여기서 말하는 냄새의 종류는 20가지가 넘어가고 이에 해결하는 방법도 중복되거나 종류가 많다. 나는 냄새를 제대로 맡아본 경험이 없다 시피 했기 때문에 냄새가 나면 어떻게 해야하는가에 더 흥미가 갔다. 

 

그 중에서 3. 13에는 반복문에 대해 짤막하게 설명을 해놓았는데, 그 냄새마다 어떠한 기술로 리팩토링 해야하는지 굵은 글씨로 쓰여져 있고, 몇장 몇절인지 표기를 해 놓았다. 그래서 여기에 해당하는 기술 8장에 넘어가 찬찬히 읽어봤는데 신선한 충격이었다. 반복문이 그냥 for, while이 있고 map, filter은 편할려고 쓰는거 아닌가? 라는 생각을 해왔다. 하지만 8장에서 해당되는 내용을 읽었을 때 내가 참 무지한 생각을 해왔던게 느껴졌다.

'남이 내 코드를 본다면?', '반복문에 새로운 기능을 추가하려면?' 에 대한 질문을 받음과 동시에 답변까지 받은 느낌이었다.

 

냄새도 아는 것이 있어야 맡아진다 라는 느낌을 받았다 그렇기 때문에 4장은 테스트코드, 5장은 (6~12장)카탈로그에 대한 보는법을 설명하고 있기에 가볍게 읽고 넘어가고 6장부터 냄새를 지우는 법에 관하여 읽어 보려한다.