[클린 소프트웨어] PART 1 - CHAPTER 5 - 리팩토링

모든 소프트웨어 모듈에는 세 가지 기능이 있다.

• 실행 중에 동작하는 기능: 모듈의 존재 이유이다.
• 변경 기능: 대부분의 모듈이 생명주기 동안 변경 과정을 겪게 되고, 가능한 한 간단하게 그런 변경을 할 수 있도록 만드는 것이 개발자의 책임이다. 변경하기 어려운 모듈은 그것이 제대로 동작한다 하더라도 망가진 것이며 수리가 필요하다.
• 그것을 읽는 사람과 의사소통하는 기능: 개발자가 쉽게 읽고 이해할 수 있어야 한다.

모듈을 읽기 쉽고 변경하기 쉽게 만들기 위해서는 단순히 원칙과 패턴 이상의 그 무엇이 필요한데, 바로 주의력과 훈련이다. 주의력은 어떤 그냥 동작하게 만드는 것과 올바르게 동작하게 만드는 것의 차이이고, 프로그래머가 코드의 구조에 부여하는 가치와도 같다.

 

리팩토링?

외부 행위를 바꾸지 않으면서 내부 구조를 개선하는 방법으로,
소프트웨어 시스템을 변경하는 프로세스
- 마틴 파울러(Martin Flowler) <리팩토링(Refactoring)>

 

리팩토링은 저녁식사 후에 부엌을 청소하는 것과 비슷하다. 처음으로 생략하고 넘어갔을 때는 저녁식사를 좀 더 빨리 끝마칠 수 있다. 하지만 깨끗한 접시와 깨끗한 작업 공간의 부족 때문에 다음 날 저녁 준비는 훨씬 오래 걸릴 것이다. 그래서 다시 한 번 청소를 안 하고 넘어가게 된다. 리팩토링의 목표는 저녁식사 후에 부엌을 청소하듯 매일 코드를 청소하는 것이다. 우리는 문제가 쌓이고 쌓여서, 오랜 시간 동안 축적된 것을 파내고 문질러 닦아야 하는 것을 원하지 않는다. 최소한으 ㅣ노력으로 시스템을 확장하고 수정할 수 있기를 바란다. 이를 위한 가장 중요한 요소는 코드의 깔끔함이다. 원칙과 패턴도 그것이 적용된 코드가 엉터리라면 무의미하다. 원칙과 패턴에 신경 쓰기 전에, 간결하고 분명한 코드를 만드는 데 신경을 써야 한다.

 

 

/메모/
한 번만 호출되는 함수를 추출해낼 경우 성능에 부정적인 영향을 주는 건 아닌지 걱정하는 사람도 있을 것이다. 대부분의 경우 나는 향상된 가독성이 몇 나노초 단위의 가치가 있다고 생각한다. 그러나 이 몇 나노초가 문제가 되는 깊은 내부 루프도 있을 수 있다. 성능의 손해는 무시할 수 있다고 가정하고, 그것이 틀렸다는 것이 증명될 때까지 기다려보라고 조언하고 싶다.

 

---

Reference

• Robert C. Martin - <Clean Software(Agile Software Development)>

책에 나오는 예제 코드는 제외
그냥 내가 기억하고 싶은 내용 위주로 정리