리펙토링 원칙

리펙토링 원칙

(https://myadventuresincoding.wordpress.com/2010/07/03/refactoring-principles/ 글을 번역 + 코멘트)

• 코드의 양을 줄어야 합니다. 한 메쏘드에 5줄이 넘어가면 의심해 봐야 합니다.
• 모든 것을 다 할 수 있는 슈퍼 메쏘드/객체는 없어야 합니다. 한가지 기능을 하도록 단순하게 해야 합니다.
• 작고 응집력있게 만들어야 합니다. - SOLID 중에 SRP
• 중복제거! - DRY Don't repeat yourself!!
• 종속성 제거 - 종속성을 줄이기 위해 노력해야하는 것이 아니라 없애야 합니다.
• 자체 문서 작성 코드 - 주석이 필요 없이 코드를 보고 이해할 수 있도록 해야 합니다.
• 코드는 보는 즉시 이해할 수 있어야 합니다. - 코드의 양을 줄이는 것을 의미하는 것이 아니라 명확하게 표현되어야 합니다. 
• 원시적인 강박관념을 피하세요. - 높은 추상화 생성에 집중해야 합니다.
• 자주 확인하고 작은 단계로 진행하세요. - 모든 커밋은 한 개의 변경사항만 가지고 있어야 합니다.- 1 commit 1 change
• 피드백 주기를 단축시키세요.
• 다른 개발자는 루프에 보관하세요.
• 커다란 고통스러운 머지는 피하세요.
• 코드를 한 종류의 추상화 수준으로 맞추세요. - 모든 메소드는 한가지만 해야 하고, 각 메서드는 각각 한 가지 작업을 하는 다른 메서드에 위임해야 합니다.

리펙터링 하지 말아야 할 때.

• 다른 코드를 변경하는 동안 리펙터링하지 마세요. 리펙토링을 기록하고 버그 수정이나 기능 변경이 커밋되면 완료하세요. 절대로 다른 코드가 변경되는 동안에 리펙토링을 수행하지 마세요. 

1. 나쁜 냄새를 맡으면 메모를 남깁니다.
2. 하던 일을 마무리 짓습니다.
3. 커밋합니다.
4. 리펙터링 시작

• 혼자서 리펙토링하지 마세요. 문제에 대해 눈 2개를 같이 가지고 진행해야 합니다. 페어 프로그래밍은 리펙토링하는 동안에 필수적입니다. 짝은 코드를 이해하기 쉽게 만들고, 좋은 이름을 가지고 기존 로직을 망치지 않는데 도움을 줍니다.

리펙토링 해야 할 

• 버그 수정이나 기능 변경 전이나 후에 리팩토링 할 수 있습니다.
• 변경으로 인해 코드 디자인이 개선된다고 생각한다면
• 변경으로 인해 다른 개발자를위한 코드의 가독성이 향상된다고 생각한다면