개발자는 향후 변경에 유연하게 대처할 수 있는 유연성 메카니즘(flexibility mechanism)을 고려하곤 한다. 그래서 함수 사용 시 매개변수를 추가하는 처리를 하여 변화에 대응하려고 한다. 하지만 시간이 지나면 사용하기 복잡해지거나 필요한 기능들을 잘못 사용하는 원인이 되기도 한다. 미래의 필요할지 알 수 없는 기능들을 미리 추가하는 것은 지양해야 할 방법으로 알려져 있다.
저자는 리팩토링의 관점에서 현재의 요구사항에 맞춰 해결하면서 소프트웨어를 변경할 것을 말하고 있다. 개발을 진행하면서 요구사항을 잘 이해하게 되면 아키텍처 변경이 가능하다. 즉, YAGNI는 리팩터링이 이루어지면서 개발이 진행돼가면서 아키텍처와 설계가 더 나아진다고 할 수 있다. 선제적인 아키텍쳐를 소홀히 하라는 의미는 아니지만 이러한 구조를 가져간다면 진화형 아키텍쳐로 나아갈 수 있다.
XP(Xtreaming Programming) 에서 지속적 통합, 자가 테스트 코드, 리팩터링 등의 요소가 강조되었다. 단순한 시스템은 변화를 하기 더 쉽고, 세 가지 실천 방법은 변화 대응에도 안정적으로 만든다.
기초적인 가이드. 비슷한 일을 세 번째 하게 되면 리팩터링한다(삼진 리팩터링).
저자는 리팩터링을 위한 기간을 따로 잡지 않는다. 기능 추가나 버그 수정 기간에도 리팩터링은 함께 진행된다. 즉, 기회가 될 때마다 하는 것을 추천한다.
저자에 따르면 20년 전만 해도 설계를 잘하려면, 설계가 완벽해야하는 것이 개발자들의 인식이었다. 소프트웨어는 코딩 단계에 들어서면 부패한다고 생각했기 때문이다. 하지만 리팩토링을 통해 이를 개선시킬 수 있다는 것이 저자의 생각이다. 처음부터 좋은 설계를 하기 힘들다. 리팽토링은 설계를 개선할 수 있기 때문에, 요구사항이 변하더라도 설계를 지속적으로 개선해나갈 수 있다.
개발자는 코딩이 시작되기 전 아키텍쳐를 확정 지으려 하고 요구사항을 모두 챙기기를 원하지만, 막상 개발 단계에선 실현할 수 없는 목표를 확인하기도 한다. 또한, 실제 사용 시 요구사항이 발생하기도 한다.
이에 대응하는 방법으로는 미래에 발생할 수 있는 상황을 가정하여 유연성 메커니즘(flexibility mechanism) 요소를 소프트웨어를 넣을 수 있다. 하지만 저자에 입장은 앞서 YAGNI에서 서술하였듯 현재에 요구사항을 해결하는 소프트웨어를 개발하되, 리팩토링을 통해 아키텍쳐가 변화에 대응할 수 있어야 한다는 것이다.
리팩토링을 진행하면 코드를 잘 이해하게 되고 버그를 찾기 쉬워진다. 리팩토링하면서 깨닫는 점을 코드에 반영하고, 버그를 발견하기 쉬워진다. 견고한 코드를 작성하는 데 도움이 된다.
리팩토링은 품질에 긍정적인 영향을 끼칠 수 있다. 내부 설계와 가독성이 개선되는 것은 품질하고 연관이 있기 때문이다. 개발자들은 기존 시스템에 새로운 기능을 추가하는 것은 시간이 지날수록 어려움을 느낀다.
내부 설계가 잘 된 소프트웨어는 새로운 기능을 추가할 지점과 어떻게 고칠지를 빠르게 찾을 수 있다. 모듈화가 잘되어있으면 코드 이해에도 좋다. 이를 설계 지구력 가설이라 부르며, 내부 설계에 심혈을 기울이면 소프트웨어 지구력이 높아져 빠르게 개발 가능한 상태를 높일 수 있다.