실행 지침

다양한 특성과 요소를 포함하는 과정으로 초점을 맞춰야 하는 세 가지 사항은 아래와 같다.

• 활동의 근거지를 도메인으로 삼는다.
• 현상과 사물을 다른 방식으로 바라보도록 노력한다.
• 도메인 전문가와 지속적으로 대화한다.

도메인에 대한 통찰력을 추구하다 보면 리팩터링 과정을 위한 더욱 폭넓은 컨텍스트가 만들어진다.

고전적인 리팩터링은 개발자 한두 명이 코드 개선을 발견하고 즉시 수정하는 것이며, 단위 테스트로 결과를 검증한다. 하지만 리팩터링은 이것만을 의미하지는 않는다.

앞의 다섯개의 장에서는 전통적인 마이크로 리팩터링 접근법을 보충하는 확장된 관점의 리팩터링을 제시했다.

리팩터링은 도메인을 더욱 심층적으로 이해한 개발자가 더 명쾌하고 유용한 모델로 개선할 수 있는 여지를 발견하는 과정에서 얻게 된 학습의 결과다.

1. 해당 유형의 문제에 대한 사고 능력이 탁월하거나, 해당 도메인 영역을 잘 알고 있거나, 모델링 기술이 뛰어난 두 명의 개발자를 선발한다.
   • 난해한 부분이 있다면 도메인 전문가도 함께 참여해야 한다.
2. 이렇게 구성된 4~5명 정도의 그룹은 회의실이나 커피숍에 모여 30분에서 1시간 30분 동안 브레인스토밍을 한다.
   • 이 때 UML 다이어그램을 스케치해 보거나 객체를 사용해서 시나리오를 재현해 본다.
3. 만족스러운 개념을 발견했다면 자리로 돌아와 발견한 내용을 코드로 옮긴다.
   또는 며칠 동안 좀더 생각해보기로 하고 다른 작업을 진행할 수도 있다. 이틀 후에 그룹에 속한 사람들이 다시 모여 이전에 발견한 내용을 세밀히 검토한 후 어떤 결론에 도달한다. 다시 컴퓨터 앞으로 돌아와 새로운 설계를 코드로 옮긴다.

이런 과정을 생산성 있게 진행하는 몇 가지 비결은 다음과 같다.

• 자기 결정. 설계 문제를 조사하기 위해 즉시 규모가 작은 팀을 소집할 수 있다. 팀은 며칠 동안 작업을 진행한 후 해산한다. 장기간의 정교한 조직 구조는 필요하지 않다.
• 범위와 휴식. 며칠에 걸쳐 두세 번 정도의 짧은 회의를 진행한 후 시도할 가치가 있는 설계안을 도출해야 한다. 결정을 늦추는 것은 도움이 되지 않는다. 진행이 막혔다면 한 번에 너무 많은 부분을 한 번에 해결하려는 건 아닌지 돌아보라. 더 작은 설계 영역을 선택하고 해당 영역에 집중한다.
• UBIQUITOUS LANGUAGE의 사용. 브레인스토밍 과정에 다른 팀 구성원, 특히 주제 영역의 전문가를 포함시키는 것은 UBIQUITOUS LANGUAGE를 사용하고 이를 개선할 수 있는 좋은 기회다. 이런 노력을 기울인 결과 UBIQUITOUS LANGUAGE가 개선되고 개발자가 이를 코드에 반영할 것이다.

항상 바퀴를 다시 발명할 필요는 없다. 과거의 지식과 경험을 활용하자. (eg. 서적, 도메인 문서, 분석패턴 등)

10 유연한 설계 참조.

변경을 완벽하게 정당화할 수 있을 때까지 기다린다면 지나치게 오랫동안 기다린 셈이다.

소프트웨어 개발은 변경의 이익과 변경을 하지 않음으로써 입게 되는 손실을 정확하게 계산할 수 있는 예측 가능한 프로세스가 아니다.

다음과 같은 경우에 리팩터링을 수행한다.

• 현재 팀에서 도메인을 이해하고 있는 바가 설계에 표현돼 있지 않은 경우
• 중요한 개념이 설계상에 암시적으로 표현돼 있는 경우 (그리고 개념을 명확하게 표현할 수 있는 방법이 보이는 경우)
• 설계상의 중요한 부분을 더욱 유연하게 만들 기회가 보이는 경우

도메인의 핵심을 찌르지 못하면서 단지 기술적인 기교를 뽐내기 위한 용도로 유연한 설계를 도입해서는 안된다! 우아한 정도와 상관없이 도메인 전문가가 납득하지 못하는 더 심층적인 모델을 도입해서는 안된다!

더 심층적인 통찰력을 향한 리팩터링을 하다보면 어느 순간 갑자기 모든 것을 뒤흔드는 통찰력을 얻는다.

이런 상황은 종종 기회가 아닌 위기처럼 보인다. 이는 팀이 새로운 이해 수준에 도달했다는 의미고, 더 훌륭한 모델을 생각해낼 수 있다.