<마이클 C. 페더스 > 레거시 코드 활용 전략

레거시 코드 활용 전략은 테스트 코드 없이 레거시 코드를 다 감수하시겠습니까? 글을 읽은 후, 흥미를 갖게 된 책이었다. 이후, 비즈니스 로직이 복잡한 업무를 담당하게 되었고 나의 복잡한 심정을 대변해줄 대상을 찾는 심정으로 이 책을 읽게 되었다. 

이 책은 현업에서 리팩토링을 하면서 암묵적으로 체득한 기법들이 명쾌하게 정리되어 있어 흥미로웠다. 리팩토링을 할 때, 적용 결과가 이전보다 낫다고 확신할 수 없는 경우가 종종 있었다. 이 때, 리팩토링을 하지 않으면 코드를 이해하기 어려웠기 때문에 별다른 선택지가 없어서 고민하고는 했다. 몇 번의 실패를 경험한 후, 스케치하듯이 연습 삼아 리팩토링을 하며 코드를 분석하는 패턴을 체득하게 되었다. 물론, 이 코드는 로컬에서만 사용했고, 리팩토링 효과가 확실하다고 생각되는 부분만 별도로 프로덕션 레벨에 반영하고는 했다. 그런데 이미 레거시 코드 활용 전략에서는 이를 "스크래치 리팩토링"이라고 부르고 있었다.

출판된지 16년된 서적이다보니 예제 코드와 테스트 코드 작성 스킬은 요즘의 기술과는 맞지 않은 설명들도 있었다. 그러나 전반적인 맥락과 소프트 스킬은 현재에서도 사용하기에 유용했다.

영문 번역이 매끄럽지 않아서 꾸역꾸역 어렵게 끝까지 읽느라 힘들었다. 그러나 이 책을 완독하고 나니, 다른 기술 서적들이 너무 수월하게 읽혔다. 심지어 재밌기까지 했다. 어려운 고전 서적이었지만, 뜻밖의 장점이 있는 책이었다. 

밑줄 그으며 책 읽기

Chapter 20. 클래스 추출

클래스 추출은 선을 넘는 불필요한 작업을 하기 쉽다는 위험이 있다. 스크래치 리팩토링을 하거나 시스템의 바람직한 모습에 대한 관점을 새로 만들 수 있지만, 현재 애플리케이션 구조가 정상적으로 동작하고 있음을 기억해야 한다. 현재 구조는 애플리케이션의 기능을 뒷받침하고 있으며, 향후 개선에 적합한 구조가 아닐 뿐이다. 가끔 리팩토링을 통해 거대한 클래스가 어떻게 바뀔지 고민한 후 그냥 잊어버리는 것이 최선일 때가 있다. 고민을 통해 무엇이 가능한지 발견할 수 있기 때문이다. 개선을 위해서는 이미 존재하고 있는 것들을 충분히 고려하고, 반드시 이상적인 설계는 아닐지라도 최대한 지금보다 나은 방향을 바라봐야 한다.

Chapter 22. '괴물' 메서드를 변경해야하는데 테스트 코드를 작성하지 못하겠다.

감지변수

감지변수는 클래스에 임시 변수를 추가하여, 메소드의 상태를 감지할 수 있게 해주는 역할을 한다. 이는 리팩토링 대상 함수에서 임시변수에 확인하고 싶은 값을 대입하고, 테스트 코드에서 감지변수의 값을 확인하는 방식으로 활용하면 된다. 그리고 리팩토링이 모두 완료되면 감지변수는 제거하는 것이 좋다.

아는 부분 추출하기

결합계수

• 결합 계수란 추출 대상 메소드에 드나드는 값의 총 개수를 말한다. 함수의 매개변수 개수로 볼 수 있다.
• 결합 계수가 낮은 함수를 추출하는 것이 안전하다. 그래서 매개변수가 0개인 함수 추출이 가장 안전하다. 어떤 매 개변수도 받지 않고, 어떤 값도 반환하지 않는 메소드를 추출하는 것만으로 괴물 메서드를 개선하는 데에 많은 도움이 된다.

아는 부분을 점진적으로 함수추출하는 방식은 작업의 진전을 체감하기 어렵다. 그러나 알지 못하는 사이에 차근차근 진전되는 것은 분명하다. 이해하고 있는 부분을 하나씩 추출할 때마다 메소드는 조금씩 명확해진다. 메소드의 범위와 나아갈 방향이 점점 눈에 들어오게 될 것이다.

Chapter 23. 기존 동작을 건드리지 않았음을 어떻게 확인할 수 있을까?

짝 프로그래밍

저자는 짝 프로그래밍을 할 때에 파트너가 "무슨 일을 하고 있어요?" 라고 물어봐주기를 요청한다. 이 때, 저자가 2가지 이상을 하고 있다고 말하면, 이 중 한 가지만을 골라서 처리한다. 프로그래밍을 할 때, 한 번에 큰 부분을 건드리기 쉽다. 그렇게 되면 결국, 코드가 실제로 어떤 일을 하는지 매우 잘 아는 상태에서 신중이 작업하기보다는 그저 코드가 동작하게 만드는 데에 급급해진다.

Chapter 24. 어찌해야 할지 모르겠다. 나아질 것 같지 않아

레거시 코드 업무의 성공을 위한 열쇠는 일의 가치를 아는 것이다. 대부분의 프로그래머는 고독한 존재다. 하지만 업무를 즐기는 방법을 알고 있으며, 여러분이 존경할 만한 사람과 일하는 것보다 좋은 환경은 거의 없다.

업무가 즐겁고 기존 시스템의 개선에 긍정적인 사람들이 모인 프로젝트에서 일할 때조차도 다른 형태로 실망하게 될 때가 있다. 코드가 너무 거대해서 10년 이상 시간을 들여도 10%도 개선하지 못할 것 같다는 느낌을 받으면 의기소침해지는 개발자가 있다. 이것이 정말 우울해할 만한 것일까? 저자는 수백만 줄로 된 레거시 코드를 매일 공부하면서 도전과 실력 향상의 기회로 삼고 즐기는 많은 개발팀을 경험했다고 한다. 반면, 더 나은 코드베이스에서 작업하면서도 불행하다고 여기는 팀들도 봐왔다고 한다.결국, 마음가짐이 중요한 것이다.

코드베이스를 제어할 수 있게 되면 오아시스가 나타나기 시작한다. 그 속에서 작업은 정말 즐거울 것이다.