2장 리팩터링 원칙

오케이 오늘도 가보자

https://tenor.com/ko/view/minions-strong-cute-flex-time-to-get-serious-gif-17504468

 

리팩터링

소프트웨어의 겉보기 동작은 그대로!

하지만 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법.

 

리팩터링 하기 전과 후는 성능이 변할 수 있지만, 사용자 관점에서는 달라지는 점이 없어야 한다.

즉, 리팩터링하는 과정에서 발견된 버그는 리팩터링 후에도 버그가 그대로 있어야 한다.

 

습관처럼하는 리팩터링은 프로그래밍 속도를 높인다.

리팩터링을 함으로써(코드를 이해하기 쉽게 바꿈으로써) 새로운 기능을 추가할 때 마다 쉽게 활용할 수 있기 때문이다.

 

리팩터링을 해야 할 때

리팩터링은 시간을 잡고 한다기 보다는 보고 바로바로 보기싫은 코드를 바로 리팩터링 해야 한다.

리팩터링을 계획적으로 하는것도 상관없다.

 

리팩터링 관점에서 브랜치같은 경우는 하루에 한번씩 마스터와 합쳐서 작업하는 경우가 좋다(최신화).

리팩터링은 코드를 보기 좋게 바꾸는 것인데 하루에 한번씩 갱신하지 않는다면 함수나 클래스가 이름이 겹치거나 의미가 겹치거나, 또는 기능이 겹칠 위험이 있기 때문이다.

따라서 다른 사람들과의 코드를 합쳐서 의미가 겹치지 않도록 해야 리팩터링하기 쉬워진다.

 

리팩터링 종류

 

1. 준비를 위한 리팩터링 

새로운 기능을 만들거나 버그를 해결해야 할때 코드를 이해해야 할 필요가 있다.

2. 이해를 위한 리팩터링

코드를 수정하는 순간이 오면 해당 코드를 이해해야 하는 순간이 온다. 복잡한 코드 속에 다양한 기회들을 정리함으로써 코드 수정에 더 많은 도움을 준다.

3. 쓰레기 줍기 리팩터링

코드를 파악중에 로직이 쓸데없이 복잡하거나, 같은 일을 여러번 반복하거나, 문제를 발견하면 이때는 간단한 내용이 아니라면 메모만 남겨놓고 원래하던 일을 끝내놓는다. 그러고 남겨놓은 메모를 조금이라도 개선을 해 두는 편이 좋다.

 

리팩터링 목적

 

리팩터링은 코드 베이스를 이쁘게 꾸미는 데에 있지 않으며,

클린 코드나 바람직한 엔지니어링 습관 같은 도덕적인 이유로 정당화 되어선 안된다.

리팩터링은 순수하게 경제적인 이유로 해야한다.

개발 기간을 단축해야 한다는 목표에 집중되어야 한다.

 

 

추가

 

KISS - Keep it Simple, Stupid (단순하고 멍청하게 코딩 해라 - 가독성을 낮추지 말것)

DRY - Don't repeat yourself ( 반복된 코드를 작성하지 말라)

YAGNI - You aren't going need it ( 지금 필요없는 기능을 만들지 말라)