아래 내용은 '레거시 코드 활용 전략 - 마이클 C. 페더스' 에서 발췌한 내용입니다.
우리는 개발을 하다보면 이런 상황을 겪고 합니다. 종종 이해하기 어려울 정도의 코드를 마주치기도 하고, 코드를 수정하려고 보니 겁이 나는 그런 상황이요.
우리는 이럴 때 어떻게 행동하게 되나요? 두려움을 이겨내고 코드 수정을 바로 이어가나요? 그렇게 했을 때 우리의 코드는 마치 비웃듯이 git rollback 을 하라고 소리치곤합니다.
그런 상황에서 써먹을 수 있는 간단하지만 강력한 방법을 소개하고자 합니다.
1. 노트와 스케치 활용하기
저도 자주 사용하는 방식인데, 어려운 코드보다는 도메인에 대한 이해도를 높이기 위한 수단으로 사용해왔습니다.
이해하고 싶은 코드의 도식화를 직접 그려보는 것입니다. 아주 단순하지만 강력한 방법입니다. 어떤 온라인상의 그림 도구(draw.io, google whiteboard)를 사용하지 않는 것을 추천합니다. 온라인에서 사용하는 그림 도구의 경우, 쓰고 지우기가 쉽지 않기 때문에 추천하지 않습니다. 언제든 쓰고 버릴 수 있는 옥스포트 노트를 추천합니다.
코드를 위해 그리는 스케치는 완벽할 필요가 없습니다. 다만, 그림이 복잡해질 수록 효율적인 표현을 위해 좀더 정형화된 표기법을 사용하고 싶어질 것입니다.
코드 설계를 이해하고자 노력할 때 스케치를 봄으로써 얻을 수 있는 장점은 형식에 얽매이지 않는 영향력이 있다는 것입니다.
2. 표시 나열
- 주로 규모가 큰 메서드일 경우에 유용하다고 합니다.
- 표시나열 기법은 이해하려는 대상에 따라 달라진다.
먼저 작업 대상 코드를 프린터로 출력합니다.
그리고 다음과 같은 용도별로 표시 나열 기법을 사용할 수 있습니다.
책임 기법
- 책임을 분리할 때는 대상을 그룹별로 나누기 위해 표시를 사용한다.
- 몇 개의 대상이 동일 그룹에 속한다면, 이것들을 식별할 수 있도록 각각에 특별한 기호를 표시합니다.
메서드 구조의 이해
- 코드의 길이가 긴 대규모 메소드의 구조를 이해하고 싶을 때는 코드 블록에 선을 긋는다.
- 코드 블록에 선을 긋는 가장 쉬운 방법은 안쪽에서 바깥쪽으로 순차적으로 따라간다.
- 색이 다른 형광펜으로 표시한다.
메서드 추출
- 코드의 길이가 긴 대규모 메소드를 분리하고 싶을 때는 추출하려는 코드 주변을 원으로 표시한다.
- 그리고 결합 카운트를 주석으로 단다.
변경 영향의 이해
- 수행하려는 변경의 영향을 이해하고 싶을 때는 영향 스케치를 작성하는 대신에 변경하려는 코드에 표시한다.
- 그리고 나서 변경으로 인해 값이 바뀔 가능성이 있는 변수와 영향을 받을 가능성이 있는 메소드 호출에 모두 표시한다.
3. 스크레치 리팩토링
가장 인상깊은 방법으로, 현업에서도 우리가 종종 무의식적으로 사용하는 방법이였지 않았을까 싶어요. 스크레치 리팩토링이라고 말했을 때는 무슨말인지 이해하기 어려웠습니다. 스크레치 라는 단어에 대한 사용이 다음 절차를 통해 이해될 수 있을 것입니다.
스크레치 리팩토링은 다음과 같은 절차를 가집니다
1. 변경을 가하고자 하는 코드를 형상관리시스템을 통해 체크아웃한다.
2. 메서드 추출이든 변수 이동이든 다양한 방법으로 마음껏 리팩토링한다. 단, 그 코드는 다시 Commit 하지 말고 그냥 버린다.
3. 코드가 친숙해질 때까지 반복하여 기존의 코드를 스크레치내며 이해한다.
스크레치 리팩토링은 코드를 반복적으로 수정하고 버림으로써 영향범위를 이해하는 방식입니다. 모퉁이 저편에 언제나 무서운 괴물이 숨어있는 것만은 아니라는 확신을 얻을 수 있습니다. 혹시 그러한 것이 있더라도, 최소한 미리 간파할 수 있습니다.
그러나 스크레치 리팩토링에도 위험한 요소가 있는데, 다음과 같습니다.
- 리팩토링 중에 무언가 착각해서 시스템이 실제로는 하지 않는 일을 하고 있다고 잘못 믿어버리는 것. 이 경우 시스템에 대한 잘못된 관점을 가지게 되고 나중에 실질적인 리팩토링을 주저하게 된다.
- 리팩토링한 결과에 집착하게 돼 항상 그 결과에 맞쳐서 생각하게 되는 것. 얼핏 이는 그다지 나쁜 것 같지 않아 보이지만, 큰 문제를 일으킬 가능성이 있다.
읽어보면 정말 별거 아니네? 라고 생각하실 수 있습니다. 하지만 이것을 직접 실천하는 것은 다른 이야기입니다.
'가치관 쌓기 > 개발 돌아보기' 카테고리의 다른 글
다형성과 OCP(Open Closed Principle)은 무슨 관계일까? (0) | 2023.05.27 |
---|---|
[리팩토링] 다형성을 이용한 IF 문 제거하기 (4) | 2023.05.21 |
개발DB 꼭 필요한가요? 진짜 필요한거예요? (0) | 2023.02.24 |
왜 테스트 코드를 작성하는 걸까? (0) | 2022.10.29 |
DB AutoIncrement 가 아니라, 왜 굳이 IDGenerator Server 을 만들었을까? (2) | 2022.10.05 |
댓글