I Don’t Understand the Code Well Enough to Change It
레거시 시스템에 어떤 기능을 추가하고 싶을 때, 시스템 전반에 대한 이해도가 부족한 경우가 있다.
하나를 변경하기 위해 알아야하는 것들이 너무 많은 경우, 짧은 시간 내에 파악하는 것은 어려운 일이기 때문이다.
이번 포스팅에서는 코드를 이해하는 방법론들에 대해서 알아보도록 하자.
1. Notes/Sketching
코드 리딩만으로 한계가 있다면 노트에 메모하는 것도 좋은 방법이다.
UML 등으로 완벽하게 시각화하는 것보다는 파악을 용이하게 하는 수준이면 충분하다.
노트나 메모만으로도 기존과는 다른 관점으로 코드를 바라볼 수 있다.
위와 같이 세련된 스케치는 아니더라도 의사소통에 도움이 되는 수준이면 충분하다.
코드의 설계를 이해하고자 노력할때 스케치를 봄으로써 형식에 얽메이지않고 이해할 수 있다.
2. 표시 나열(Listing Markup)
스케치 뿐만 아니라 표시 나열이라는 기법도 자주 사용한다.
이 방법은 규모가 큰 메서드를 파악할때 매우 유용하다.
먼저 작업 대상 코드를 프린터로 출력한 뒤 아래와 같이 용도별로 표시 나열 기법을 사용한다.
책임 분리(Separating Responsibilities)
책임을 분리할 때는 대상을 그룹별로 나누기 위한 표시를 사용한다.
몇 개의 대상이 같은 그룹에 속한다면 같은 표시를 하여 식별을 용이하도록 한다.
가능하다면 다양한 색상을 사용하자.
메서드 구조의 이해(Understanding Method Structure)
코드의 길이가 긴 메서드를 이해하고 싶을 땐, 코드 블록에 선을 긋는다.
코드 블록의 처음과 긑에 선을 긋거나 블록의 끝 부분에 핵심 로직을 간략하게 적어두는 것도 도움이 된다.
메서드 추출(Extract Methods)
분리하고 싶은 대규모 메서드에서 특정 로직을 분리하여 추출하려할 때, 추출하려는 코드 주변을 원으로 표시하고 코드 간의 결합 횟수(coupling count) 를 주석으로 달아둔다.
보다 자세한 방법은 추후 다루도록 하겠다.
변경 영향의 이해(Understand the Effects of a Change)
수행하려는 변경의 영향을 파악하기 위해 영향 다이어그램을 작성하는 대신 변경하려는 코드에 특정 표식을 남긴다.
그 뒤 변경으로 인해 바뀔 가능성이 있는 변수와 영향을 받을 가능성이 있는 메서드의 호출에 모두 표시한다.
이러한 절차를 반복함으로써 변경으로 인한 영향이 어떻게 전파되는 지 이해한다.
3. Scratch Refactoring
리팩토링은 코드를 배우기 위한 최선의 방법 중 하나이다.
이 리팩토링의 유일한 문제점은 테스트 루틴이 준비되지않은 상태라면 위험한 작업이라는 것이다.
리팩토링 후 잘못된 점을 찾기 위해 버전 관리 시스템에서 별도의 브랜치에서 마음껏 리팩토링한 후 영향성을 파악하고 해당 브랜치를 버리는 전략이다.
이러한 걸 스크래치 리팩토링(Scratch Refactoring) 이라고 부른다.
스크래치 리팩토링은 본질을 발견하고 코드의 동작을 이해할 수 있는 좋은 방법이다.
하지만 몇 가지 위험 요소가 존재한다.
첫 번째 위험 요소는 리팩토링 중 착각으로 인해 시스템이 실제로 하지않는 일을 하고 있다는 믿는 것이다.
이는 시스템에 대해 잘못된 관점을 가지게 되고 실질적인 리팩토링을 주저하게 만든다.
두 번째 위험 요소는 리팩토링한 결과에 집착을 하는 것이다.
좀 더 좋은 설계나 구조화 방법이 도출될 수 있음에도, 처음 떠올린 리팩토링 결과가 나오지않으면 불신하게 된다.
4. 미사용 코드 삭제(Delete Unused Code)
명백하게 사용하지 않는 코드와 혼란을 가중시키는 코드는 제거한다.
미사용 코드는 방해만 될 뿐 아무것도 하지 않는 코으이기 때문이다.
과감하게 삭제하더라도 버전 관리 시스템을 이용한다면 언제든지 불러올 수 있기에 망설일 필요는 없다.
