친구와 간단한 스터디로 리팩터링 2판을 읽고 매주 수요일 점심시간에 간단한 의견을 나누었다. 나는 평소에 강의나 직접 만들어보며 공부하는 것을 선호하기 때문에 이런 이론 서적을 끝까지 읽어 본 것은 처음이었다. 평소 실무에 사용하지 않아 생소한 내용들도 많았지만 나에게 여러 영감을 준 것은 분명하기에 글로 남겨보려 한다.
리팩터링은 유연한 것이다.
나는 평소 리팩터링은 일방적인 것이라 생각했다. 다시말해 정답이 정해져 있는 작업이라 생각했다. 비효율적인 코드를 효율적으로 수정하거나 중복된 코드를 삭제하는 것은 한번 작업하면 이전으로 되돌아 갈 일이 없기 때문이다. 하지만 책의 내용을 보면 리팩터링의 기법은 항상 양방향성이었다. 변수를 inline화 시키면 반대로 inline을 변수로 빼는 방법을 항상 알려준다. 그리고 내용을 읽어보면 언제든 다시 되돌릴 수 있다는 표현이 작성되어있다. 내가 작성한 코드가 항상 정답이 아니고 상황에 따라 바뀔 수 있기 때문이다. 그래서 리팩터링은 항상 필요하고 코드가 유연해야한다는 말이 어떤 의미인지 다시 생각해 보았다.
테스트 환경은 필수이다.
책을 읽다보면 테스트 이야기가 정말 많이 나온다. "수정 후 테스트가 통과하는지 확인한다" 처럼. 그리고 책의 초반에 테스트 코드에 대한 필요성에 대해 언급하기도 한다. 이런 테스트의 중요성에 대한 내용을 볼때 마다 생각나는 일화가 있다. 회사에서 프로젝트 회고 미팅때 있었던 일이다. 프로젝트 내에서 나의 작업을 마무리하니 시간이 뜨는 경우가 있었다. 그래서 리더에게 이런 상황을 말씀드렸더니 "그럼 리팩터링 하면 될 것 같은데요?" 라고 답변해 주셨다. 순간 리팩터링 하면 QA를 다시해야하는데.. 라는 생각이 들며 벙찐 경험이 있다. 현재 테스트 환경이 전혀 없어서 코드가 변경되면 무조건 QA가 필요한 상황이다.
물론 프론트엔드 특성상 테스트가 힘든 측면도 있다. 그래서 지인들한테 물어보면 테스트코드를 작성하는 곳은 그렇게 많지 않다. 내 생각엔 어떤것을 테스트 해야할 지가 정말 애매한 것 같다. 화면을 기준으로 테스트 하자니 화면이 자주 바뀌면 매번 테스트 코드를 수정해야하고 unit 테스트를 진행하자니 화면 구성 코드 비율이 매우 높으니 이마저도 애매하다.
그래도 테스트 환경이 필요하긴 한 것 같다. TDD처럼 테스트 기반으로 코드를 작성하지는 못해도 자동화된 테스트가 있어야 기본적인 품질에 대한 보증이 있고 리팩터링이 가능하다.
아는 만큼 보인다.
책 내용의 절반은 "객체를 어떻게 다루는가?"이다. 객체의 역할, 객체간 관계등을 지속적으로 개선해 나가며 리팩터링을 진행한다. 사실 나는 리액트를 다루다 보니 클래스를 마주할 경우가 많이 없었다. 그래서 음.. 그렇구나 하고 넘어가는 내용도 꽤 많았던 것 같다. 나중에 경험이 더 쌓이고 이 책을 다시 본다면 이해할 수 있는 범위가 더 넓어질 것 같다.
마무리
이 책을 읽으며 평소 나의 코드 습관이나 테스트에 대해 많이 생각하게 되었다. 그리고 리팩터링을 도와주는 도구가 참 편리하다는 것도 새삼 느끼게 되었다. 리팩터링을 계속 시도하던 다른 개발자들의 필요에 의해 만들어진 것이 아닐까 하는 생각을 한다. 나의 경험이 더 쌓이면 다시한번 읽어보고 싶은 생각이다
