•
레거시 코드처럼 익숙하지 않은 코드에 발을 들이는 것은 두렵게 느껴질 수 있다.
•
어떤 사람들은 시간이 지나면 두려움에 면역이 생기기도 하지만 이를 완전히 떨쳐내기는 어렵다.
•
코드를 이해하는 방법은 다양하지만 대부분의 사람들은 가장 직접적인 방법에만 사로잡혀 다른 방법들을 간과하곤 한다.
•
그 결과, 코드 이해에 많은 시간을 들여봤자 별 효과가 없다고 느끼게 되고 코드 이해에 쓰는 시간을 줄이곤 한다.
노트/스케치
•
코드를 읽는 것만으로 파악하는 것이 어렵다면 그림을 그리거나 노트에 메모하는 것이 효과적이다.
◦
중요 사항의 이름을 쓰고, 그다음 중요 사항의 이름을 적어나가며 그들 사이에 관계가 있다면 선을 긋는다.
•
이렇게 스케치를 그려봄으로써 기존과는 다른 각도로 사물을 바라볼 수 있다. 또한 매우 복잡한 것을 이해하고자 할 때 도움이 된다.
표시 나열
•
표시 나열이라는 기법도 좋다. 이 방법은 매우 규모가 큰 메소드일 때 유용하다.
•
먼저, 작업 대상 코드를 프린터로 출력하여 다음과 같은 분류로 코드들을 묶어볼 수 있다.
책임 분리
•
책임을 분리할 때는 대상을 그룹별로 나누기 위해 표시를 사용한다.
•
몇 개의 대상이 동일한 책임을 지니고 있다면 이것들을 식별할 수 있도록 묶는다.
메소드 구조의 이해
•
구조를 이해하고 싶을 때는 코드 블록에 선을 긋는다. 거대한 메소드의 경우 충분히 들여쓰기가 되어있더라도 읽기가 어렵기 때문에, 선을 그어 경계를 확실하게 하면 좋다.
⇒ Rainbow Bucket 플러그인과 유사한 것 같다.
메소드 추출
•
추출하려는 코드 주변을 원으로 표시하고, 결합 카운트를 주석으로 달아둔다.
◦
결합 카운트는 22장에서 설명한다.
변경 영향의 이해
•
변경의 영향을 이해하고 싶은 경우, 영향 스케치를 작성하는 대신 변경하려는 코드에 표시한다.
◦
그러고 나서, 이 변경으로 인해 바뀔 가능성이 있는 변수와 메소드 호출에 모두 표시한다.
◦
표시한 메소드와 변수에 바뀔 가능성이 있는 것들을 또 표시하며 이를 재귀적으로 수행한다.
•
이로써 변경으로 인한 영향이 어떻게 전파되는지 이해한다. 이는 무엇을 테스트해야 할지 이해하는 데도 도움이 된다.
스크래치 리팩토링
•
코드를 배우는 최선의 기법 중 하나가 리팩토링이다.
◦
코드에 뛰어들어 이리저리 손을 대다보면 코드를 가장 빠르게 이해할 수 있다.
•
리팩토링의 유일한 문제점은 테스트 루틴이 준비되어 있지 않은 경우, 위험하다는 것이다. 스크래치 리팩토링은 이를 해결해준다.
◦
코드를 먼저 체크아웃한 후, 리팩토링을 성실히 수행한다.
◦
그리고 그 코드를 버린다. 그럼 당신은 기존 코드에 대해 충분한 이해를 갖고 있을 것이다.
•
이는 본질을 발견하고 코드의 동작을 이해할 수 있는 훌륭한 방법이지만 몇 가지 위험 요소도 존재한다.
◦
첫 번째 위험 요소는 리팩토링 중에 무언가 착각하여 코드를 잘못 이해하는 것이다.
▪
이 경우, 시스템에 대한 잘못된 관점을 가지게 되고 실질적인 리팩토링을 수행할 때, 문제가 발생할 수 있다.
◦
두 번째 위험 요소는 리팩토링을 한 결과에 집착하게 되어 편향적인 시각을 갖게 되는 것이다.
▪
실제 리팩토링 시, 스크래치 리팩토링의 결과와 달라질 수 있다. 하지만 이에 너무 집착하면 관점 변화를 얻어낼 수 없다.
미사용 코드 삭제
•
코드 이해에 방해가 되고 사용되지 않는 코드를 삭제한다. 어차피 버전 관리 시스템이 잘 관리해줄 것이다.
