리팩터링 2판 - 04. 리팩터링하는 시기 및 고려할 문제 (YAGNI!)

이번 내용을 읽으면서는 다음과 같은 내용을 나누고 싶었어요.

언제 리팩터링을 하면 좋을지 명확하게 정할 수 있는 개발자, 그리고 적용할 수 있는 문화를 갖춰가는 개발팀이 되기 위해서 리팩터링을 언제할지 생각해보면 좋겠어요.

2.4 언제 리팩터링해야 할까?

리팩터링을 하는 시기는 생각보다 자주 일어나요. 저자는 거의 한시간마다 한 번은 한다고 말해요!

하지만 뭐든지 시기가 중요한게 아니라! 자연스럽게 본인의 개발 스타일에 맞게 리팩터링을 하는 시기를 녹여내는게 중요한거겠죠??

저는 책을 읽으며, 그리고 직접 최근에 계속해서 적용해보며 앞으로 새로운 기능 개발을 할 때, 이렇게 하려고 해요!

• 보이스카웃트 원칙! 기능을 쉽게 추가할 수 있도록 리팩터링
• 기능 구현 (기능 중심 개발)
• 자가 리팩터링 (컴포넌트 분리, 중복코드 등 코드 개선 리팩터링, 쓰레기 줍기 리팩터링)
• 코드리뷰 및 페어 프로그래밍 (이해하기 쉬운, 버그를 위해 견고하게 리팩터링)

저는 꼭 위와 같은 플로우로 현재 팀에서 진행하고 있고, 이러한 과정을 모두 생각하면서 함께했으면 좋겠어요!! (더 단단한 팀문화를 세워가고 있죠!!)

물론 위와 같은 플로우대로 정말 완벽한 분기로 진행된다는건 말도 안되는거 알고있죠?..ㅎ!!

이러한 플로우로 개발하는 규칙을 세우는건 플로우에 따라 무작정 리팩터링해야지! 라고 생각하라는게 아니에요.

 

1. 새로운 기능을 개발하기 위한 곳(페이지 단위?)을 ‘이해’하면서 기존 코드가 새로운 기능과 잘 어울러지게 리팩터링하라는 거죠!

2. 리팩터링을 통해 기능 구현이 더 쉬워졌을거에요! 기존 시스템에 찰떡인 기능을 개발하세요!

3. 자신의 코드를 처음 본다고 생각하고 찬찬히 정리를 해봐요!

4. 서로의 코드를 뜯어보며 버그가 날 수 있는 곳을 수정하고, 더 이해하기 쉬운 코드로 함께 고쳐가요!

 

💡 예를 들어, 2주 전엔 리뷰페이지에 지하철 정보를 개발했어요. 그리고 지난 주엔 편의시설 정보를 개발했죠. 지하철 정보의 UI가 다른 곳에선 안나올거라고 생각했기에 SubwaySection에 전체를 개발했었지만, 편의시설 정보를 개발할 때 완전 같은 UI로 데이터를 제공함을 확인할 수 있었죠.
그래서 새로운 기능을 구현하기 전, 지하철 정보에서 구현한 내용을 리팩터링하여 편의시설 정보에서도 적용할 수 있는 컴포넌트를 분리하여 새로운 기능을 추가하기 쉽게 리팩터링했어요.
결과적으로 리팩터링 후, 편의시설 정보와 학군 영역을 개발하는데에는 1시간도 안걸렸다는 사실을 알고 다시 한 번 리팩터링 해야하는 이유를 깨달았죠!

한가지 더! 기존에 별로인 코드는 없다고 생각해요.
단지 추가되는 기능과 잘 어울리지게 리팩터링하는게 중요한거라 생각해요. 쌓이고 쌓이면 썩어갑니다~

 

2.5 리팩터링 시 고려할 문제!

비기술적!

리팩터링의 궁극적인 목적은 개발 속도를 높여서, 더 적은 노력으로 더 많은 가치를 창출하는 것을 목표로 해라!

리팩터링은 경제적인 이유(개발속도 향상)로 하는거지 단순히 코드를 예쁘게 하는거로 생각하면 안돼요. 우리는 코드를 이해하기 쉽고 무언가를 추가하기 편리한 설계로 생산성을 높이기 위해서 리팩터링한다는 걸 명심하세요!

리팩터링 작업 대부분은 드러나지 않게, 기회가 될 때마다 진행해라!

리팩터링을 진행하며 어설픈 작업으로인해 관리자, 고객에게 불신을 주지 않기! (오해할 일을 만들지 말자! ex. 장기간 리팩터링)

굳이 수정할 필요가 없는 지저분한 코드는 리팩터링을 하지 말자! (수정할 필요가 생기는 시점에 해도 늦지 않아!)

 

기술적!

브랜치 전략과 테스트 작성에 대한 부분도 매우 중요한 부분이에요.

이 부분은 다음에 자세하게 적도록 할게요!

 

2.6 리팩터링, 아키텍처, 애그니(YAGNI) / 2.7 리팩터링과 소프트웨어 개발 프로세스

리팩터링은 소프트웨어의 관점을 크게 바꾸게 되었어요.

기존에 이미 코드로 작성된 아키텍처(폭포수모델 개념)는 바꿀 수 없고 부패할 일만 남았다.

→ 리팩터링은 탄탄한 테스트를 통해 레거시 코드를 대폭 변경할 수 있어요!

→ 물론 수시로 진행한 리팩터링을 기반으로 “요구사항에 더 적합하게” 대폭 변경할 필요가 없도록 적절히 유연한 메커니즘을 만들어가세요

(물론, 정말 적절하게 해야지 덜 고생하고, 더 변화에 빠르게 대응할 수 있음…! 뭐든지 적절히가 어렵지!! 그게 바로 YAGNI)

 

YAGNI(You aren't gonna need it)

유연성 메커니즘이 오히려 변화에 대응하는 능력을 떨어뜨릴때가 대부분입니다..!ㅠㅠ

예상되는 변경을 미리 반영하는 리팩터링을 할 때는 리팩터링을 미뤄서 훨씬 더 힘들어짐이 확실할 때, 유연성 메커니즘을 추가해야해요. (오히려 미래의 변경사항에 대응이 어려워지기에 적절하게..!)