<💡마틴 파울러가 말하는 리팩토링의 중요성> 2014년 마틴 파울러가 OOP에서 발표한 키노트에 한글자막을 넣어주셨습니다. 매우 좋은 내용이라 한번 보시길 추천드립니다. 아래는 제가 듣고 요약한 내용입니다 :) <🎯 중요 내용> 리팩토링은 기능을 개발하는 것이 아닙니다. 2가지 모드가 있다고 생각하세요. 1. 새로운 기능을 만들기 위한 모드 (기능 개발 모드) 2. 이전 기능을 동일하게 하면서, 개발하는 모드 (리팩토링 모드) 이것이 리팩토링의 시작입니다. 버그조차도 리팩토링 모드에선 수정하면 안 됩니다. [대표적인 리팩토링 방식] ✅TDD 리팩토링 (레드-그린-리팩터) 레드는 테스트를 넣는 것 그린은 테스트가 동작하게 하는 것 (기능 개발 모드) 리팩터는 코드를 깔끔하게 만드는 것 (리팩토링 모드) ✅ Litter Pickup 리팩토링 (쓰레기 줍기 리팩토링) 당신이 다른 사람의 지저분한 코드를 볼 때입니다. 눈에 보이는 작은 지저분한 것들부터 깨끗하게 리팩토링 하는 것도 중요합니다. 이는 소프트웨어 엔트로피와 설계에 좋은 영향을 줍니다. ✅ Comprehension 리팩토링(이해하기 위한 리팩토링) 당신이 다른 사람의 난독화 된 코드를 볼 때 입니다. 코드가 복잡해서 어떻게 동작하는지 알 수 없을 때, 리팩토링이 필요합니다. 당신이 읽고 이해할 수 있겠지만, 매우 파편화된 구조를 가질 겁니다. 이를 로직 화해서 다른 사람들이 다음에 볼 때 명확하게 이해할 수 있게 만드십시오. ✅ Preparatory 리팩토링(준비를 위한 리팩토링) 기존 코드에 새로운 코드를 넣어야 할 때가 있습니다. 현재의 코드가 새로운 기능을 넣기에 적당한가를 판단하고 추가해야 합니다. 만약에, 새로운 기능을 넣기도 어렵고 복잡하다면 당장 새로운 기능을 만드는 걸 멈추고 리팩토링 해야합니다. ✅ Planned 리팩토링(계획된 리팩토링) 간혹, 마일스톤 단계에 리팩토링 단계를 넣어 작업을 하는 경우가 있습니다. 이에 대한 문제는 리팩토링을 해야 하는 이유를 그 시기에 찾아야 한다는 것입니다. 그래서 전 지양합니다. 그럼에도 가치있는 건, 안 하는 것보단 낫기 때문입니다. ✅ Long-Term 리팩토링 다양한 모듈이 복잡한 관계를 갖고 있을 때입니다 이 땐 장기적인 비전이 필요합니다. 소프트웨어 설계 관점에서 어떤 목표를 갖고 지향해나아가는지 분명히 해야 합니다. 여기에서도 중요한 건, 아무리 큰 작업도 작은 단위로 쪼개서 리팩토링 해야한다는 것입니다. 최대한 작은 단위로 리팩토링을 수행하십쇼. [왜 리팩토링을 해야 하는가] ✅ 디자인 스태미나 이론(Design Stamina Hypothesis) 소프트웨어 설계에 신경을 쓰지 않으면, 계속 개발할수록 개발 속도가 떨어집니다. 오래된 코드와 싸우는데 시간을 많이 소모하죠. 소프트웨어 설계를 신경 쓰고 좋은 설계를 가진다면, 오히려 시간이 갈수록 개발 속도는 증가합니다. 모듈로 잘 나뉘어있고, 새로운 기능을 추가하는 것도 쉽고, 필요한 기능이나 변경해야 하는 기능은 모듈을 찾아서 그 부분만 바꾸면 됩니다. ✅ 리팩토링은 하는 진짜 이유 리팩토링을 아무리 중요하다고 이야기하고, "더 좋은 퀄리티와 깨끗한 코드를 만들고, 전문성을 갖고 올바른 길로 가야 한다"와 같은 리팩토링의 필요성을 이야기하고 있으면 아무도 들어주지 않습니다. 그러니, 앞으론 이렇게 이야기하세요. 리팩토링은 "💰경제성" 때문에 해야 하는 것입니다. 깔끔한 코드는 더 빠르게 새로운 기능을 만들 수 있게 합니다. <📢 코멘트> 마틴 파울러의 리팩토링의 책을 봤을 땐 좋은 게 좋은 거지,, 근데 뭐 꼭 할 필욘 없지라는 생각을 했는데 이 키노트를 보니 분명히 깨닫게 됩니다. 키노트를 보고 제가 제일 인상 깊었던 건 개발자들이 "다 같이" 좋은 소프트웨어 설계를 지향하고 논의 해야 한다는 부분입니다. 즉, 혼자서 '내 생각은 이게 더좋은데?'라며 수정하거나, '이 사람 코드는 읽기 어려워'라며 수정하는 것이 리팩토링이 아니라, 다른 사람들의 생각을 같이 공유하며 서로의 의견을 듣고 좋은 소프트웨어를 지향하는 것. 그것이 리팩토링의 시작이 아닌가 하는 생각이 듭니다.