나쁜 리팩토링은 나쁘다. 리팩토링은 좋다.

1. Good Refactoring vs Bad Refactoring

https://www.builder.io/blog/good-vs-bad-refactoring

Good Refactoring vs Bad Refactoring

builder.io Written By Steve Sewell

 

 

 

[ 요약정리 ]

리팩토링은 중요하다. 그러나, 대부분 개발자들이 새로 리팩터링 된 코드에 대해 이해와 유지 관리를 더 어려워한다. 일반적으로 더 느리고 버그도 많았다. 

그렇다고 리팩토링이 나쁜 것은 아니다. 건강한 코드베이스를 위해 중요하다. 리팩토링이 나쁜 것이 아니라, 나쁜 리팩토링이 나쁜 것이다. 

 

1. 크게 바꾸는 코딩 스타일

• 가장 흔한 실수 중 하나는 개발자가 코딩 스타일을 완전히 바꾸는 것이다.(새로운 라이브러리 도입 등)
• 간결하고 읽기 쉬운 완전히 새로운 패러다임보다는, 보다 관용적인 메서드 등을 활용하여 코드 개선하는 것이 훨씬 더 좋다. 

2. 불필요한 추상화, 지나친 통합

• 기존 코드를 이해하지 못한 채 수많은 새로운 추상화는 지양해야 한다.
• 그룹화해서 안 될 것들을 그룹화하는 등의 실수를 저지를 수 있다.
• 프로그래밍 논리를 작고, 재사용 가능한 메서드로 묶거나 분해하는 방향으로 리팩터링 하는 것이 훨씬 더 좋다.
• 또한, 모든 기능을 무리하게 하나로 묶는 것 또한 좋지 않은 방법이다.
• 때때로 다른 기능에 대해 다른 설정이 필요하기 때문에 우리는 필요한 유연성은 유지하면서 추상화의 강점을 가져가야 한다.
• 단순히 "깔끔한 코드"를 위해 유연성을 제거하는 것은 좋지 않은 방법이다.

3. 기존 코드 이해는 필수!!

• 기존 코드를 이해하지 못한 채 코드를 배우는 동안 진행하는 리팩토링은 수많은 문제를 야기한다.
• 버그를 만들거나 중요한 메커니즘을 제거하여 성능을 저하시키는 등의 다양한 문제가 발생할 가능성이 높다.
• 또한 비즈니스 맥락을 이해하는 것도 중요하다. 

 

 

[결론]: 올바른 리팩토링 방법

1. 작은 것부터 점진적으로 리팩토링 해나가자

2. 코드베이스 일관성

3. 정확하고 완전한 이해

4. 라이브러리 추가 등 새로움을 추가할 때는 팀의 동의가 필요하다

5. 리팩토링 전에 테스트를 진행하면서 업데이트하는 것이 좋다. 이를 통해 기존 기능을 유지할 수 있다

 

*리팩토링 도구

> 린팅 도구(Prettier, Eslint ), 코드 리뷰, 테스트(Vitest, Storybook 등), 적절한 AI 활용

 

 

 

 

 

 

---

 

🤔 이에 대한 나의 생각

리팩토링이 중요하다는 것을 다시 한번 느꼈다. 또, 좋은 리팩토링과 나쁜 리팩토링은 한 끗 차이임을 깨달았다.

과도한 변경이 결국 나쁜 결과를 초래한다. 그만큼 기존 코드 이해는 필수인 것 같다.

적어도 프로그래밍 세계에서 무의미한 코드는 없으며, 선배들이 작성한 코드 한 줄 한 줄 정확히 이해하고 따르는 것이 중요하다는 생각이 든다.