책 Code complete2를 점심마다 조금씩 짬 내어 읽으며 분량 중 60%를 간신히 넘긴 시점에서 써보는 기록이다
알고 있던 내용을 다시 한 번 되짚어 보고 또 몰랐던 많은 부분들을 알게 되었다. 사실 분량도 적지 않지만 어렵게 느껴지는 부분이 많은 와중에 가장 흥미롭게 읽고 있는 파트가 지금 막 지나고 있는 리팩토링과 성능 최적화에 대한 부분이다.
기존 경험에 의한 한가지 사례에 대해 먼저 이야기 해보자.
지난 나의 과거 변수 혹은 함수의 이름이 엉망이었던 부끄러운 코드가 있었다. 당시 꽤나 명시적으로 지었다고 생각을 했었는데 복잡한 로직으로 인해 코드가 쌓이기 시작하면서 명확성이 파괴되었던 경험이다. 이때, 변수 혹은 함수명도 한 파일 안에서 꽤나 상대적인 개념이 될 수도 있구나 라는 것을 깨닫게 되었다. 하지만 상대적으로 명확성을 드러내는 식별자명이 아닌 절대적인 명확성을 띄는 식별자명이 꽤나 믿을만한 무기라는 것이다. 이름만 잘 지었을 뿐인데 연쇄적으로 빠른 시간 안에 많은 것이 해결이 되었다. 이에 대한 경험은 이 글에 작성되어 있다.
그 외에도 여러가지 이유로 리팩토링을 하며 코드를 개선한 경험이 있었는데, 이렇게 하는 게 과연 올바른 방법인지에 대한 의구심이 있었다.
책에서 여러가지 와닿는 부분들을 정리해 보았다.
1. 코드가 중복되어 있다는 것은 처음부터 설계를 완전하게 나누는 데 실패했다는 것을 나타낸다.
2. 한 가지 기능만 잘 처리하는 잘 정의 되고, 이름 좋은 함수/컴포넌트로 만들 수 있게
3. 루틴의 엉성한 이름 또한 리팩터링을 하는 이유가 된다. => 이 부분은 내가 뼈저리게 느낀 부분이라 고개를 매우 끄덕이며 읽은 부분이다.
가장 재밌었던 부분은
"때때로 개발자들은 코드가 작동하게 만들려고 코드를 이리저리 수정하고 있을 때 리팩터링을 하고 있다고 말한다. 리팩터링은 프로그램의 행위에 영향을 주지 않으면서 작동하는 코드를 변경하는 것을 가리킨다."
다행히 동작을 위해 구현하는 행위를 리팩토링이라고 생각하진 않지만 행여나 어느 순간에 그렇게 생각할까 하는 의심을 하며 밑줄을 그어놨다. 중요한 것은 프로그램 행위에 영향을 주지 않으면서 작동하는 코드를 변경하는 것을 가리킨다는 것.
지난 프로젝트 중간에 투입되어 함께 일했던 선임님께서는 하나를 리팩토링 하시면 그 많은 코드를 다 돌며 확인하고 수정하는 과정을 거치셨는데 여기서 잠깐, 당연하다고 생각할 수 있지만 나는 그와 대비되는 상황을 얼마 지나지 않아 같은 프로젝트 내에서 경험한 적이 있었다. 누군가 공통 컴포넌트를 수정했는데 관련 코드들을 확인하지 않아 여기저기서 에러가 나게 된 상황이었다. 당연한 것을 당연하게 지키며 개발하는 것이 어쩌면 좋은 개발자가 되는 첫 걸음이지 않을까 싶다.
책에서 언급하는 안전한 리팩터링 방법에서
- 리팩터링한 후 다시 테스트했는가?
- 변경 사항이 컴파일되는지 혹은 중요한 코드에 영향을 미치는지 검토했는가?
에 대한 항목이 있다. 위에서 경험한 사례를 떠올리며 다시금 머리에 입력해 보았다.
현재 개발하고 있는 부분에서 시간적 여유가 생겨 식별자명을 정리하고 리팩터링이 필요한 부분에 대해 고민하고 있는데, 마침 필요한 타이밍에 책에서 리팩토링 파트가 나와서 여러가지 대입해보며 고민 중이다.
리팩토링을 하며 느끼는 것에 대해 조만간 글로 써보려 한다.
