refactoring

리팩토링?

소프트웨어 관점으로 결과의 변경 없이 코드의 구조를 재조정함 을 의미한다.
즉, 기능은 보존하면서 설계 및 구조를 개선하는 것이다.

• 소프트웨어 설계가 좋아진다.
• 소프트웨어를 이해하기 쉬워진다.
• 버그를 쉽게 찾을 수 있다.
• 프로그래밍 속도를 높일 수 있다.

진짜 중복

• 한 인스턴스가 변경되면, 동일한 변경을 그 인스턴스의 모든 복사본에 반드시 적용해야한다.

우발적 중복 (거짓된 중복)

• 중복으로 보이는 두 코드의 영역이 각자의 경로로 발전한다면, 즉 서로 다른 속도와 다른 이유로 변경된다면 이 두 코드는 진짜 중복이 아니다.

3의 법칙

1. 처음에는 그냥 한다.
2. 비슷한 일을 두 번째로 하게 되면(중복이 생겼다는 사실에 당황스럽겠지만), 일단 계속 진행한다.
3. 비슷한 일을 세 번째 하게 되면 리팩토링한다.

기능을 새로 추가하기 직전

• 리팩터링 하기 가장 좋은 시점은 기존 기능에 새로운 기능을 추가하기 직전이다.
• 기능을 추가하기 쉽게만드는 것이 리팩터링의 핵심
• 구조를 살짝 바꾸면 다른 작업하기 쉬워질 만한 부분을 찾는다.
• 기능을 추가하면서 중복코드가 생길만한 부분을 함수화 시킨다.

코드를 이해하기 어려울때

• 코드 수정시 코드를 이해하기 어렵다면 이해를 위한 리팩터링을 진행한다.
• 코드만 보더라도 이해를 쉽게 할 수 있도록 변수와 함수의 이름을 변경한다.
• 코드를 이해하기 쉽게 만드는것은 협업하기도 좋고 코드를 오래 보존 할 수 있게된다.

불필요한 코드를 발견했을때

• 코드가 비효율적으로 수행되는 것을 발견했을대 리팩터링을 진행한다.
• 로직 혹은 코드가 쓸데없이 복잡하거나 불필요한 코드를 발견했다면 보이스카웃 규칙을 떠올리자.
• 원래 하려던 작업시간을 뺏길 수 있으니 간단한 일이라면 바로 처리하고, 시간이 좀 걸릴 것 같으면 TODO를 남겨두자.

계획된 리팩토링

• 수시로 진행하는 리팩터링 외에도 따로 시간을 내서 리팩터링을 진행 할 수 있다.
• 미리 새기능을 추가 할 수 있도록 코드를 개선해둔다.
• 코드가 이미 깔끔하다면 리팩터링을 하기에도 더 쉽다.

오래걸리는 리팩토링

• 각 잡고 전체 개발자들이 달려들어서 리팩토링을 하는 짓은 좋지않다.
• 리팩토링 해야될 코드와 관련된 작업을 하게 될 때 마다 원하는 방향으로 조금씩 개선하는 방향을 추구하자

코드리뷰에 리팩토링 활용하기

• PR 피드백을 활용하여 리팩토링 해나가는 것도 좋은 방법이다.

리팩토링 하지 말아야 할 때

• 호출해서 쓰는 코드라면 굳이 건들지 말자
• 리팩터링보다 새로 코드를 작성하는 쉬운 코드의 경우 그냥 둔다.
• 어떤 코드가 리팩터링보다 새로 만드는게 쉬운가에 대한 판단은 많은 경험이 뒷받침 되어야한다.