Object-Oriented Reengineering Patterns

Object-Oriented Reengineering Patterns을 읽고 정리하자.

(2) Setting Direction

• 아키텍처 비전을 유지하기 위해 네비게이터가 있어야한다.
• 문제 정의 및 달성 방법에 대한 기준을 세우기 위해 원칙이 있어야한다.
• 올바른 문제와 중요한 결정에 집중할 수 있도록, 가장 가치있는 것 먼저 해결해야한다.
• 리팩토링 및 재작성 여부를 결정할 때에는 증상이 아니라 문제에 집중해야한다.
  • 변화를 위한 변화는 생산적이지 않다. 고장난게 아니면 고치지말아라.
• 새 시스템을 범용적으로 만들고 싶은 마음이 들 수 있다. 그러나 단순하게 유지해라. 참아라.

 

(2.1) Agree on Maxims: 원칙에 동의하기

Q. 팀의 목적 의식을 수립하려면?

A. 핵심 우선순위를 정의하고, 팀의 목표 달성에 도움이 되는 기본 원칙을 세운다.

 

(2.2) Appoint a Navigator: 네비게이터 정하기

Q. 프로젝트가 진행되는 동안, 아키텍처 비전을 유지하는 방법은?

A. 아키텍처 비전이 유지될 수 있도록 담당자를 지정하자.

리엔지니어링 프로젝트의 목표는 레거시 시스템을 몇 년 더 지속시킬 수 있는 새로운 아키텍처 비전을 개발하는 것이다. 네비게이터가 없으면 기존의 설계와 아키텍처가 새 시스템에 스며들기 쉽다.

시간이 지나면 리엔지니어링 아키텍처가 희석되고 퇴화할 수 있다. 새롭고 중요한 요구사항이 들어오면서 퇴화할 수 있다. 그래서 중요한걸 먼저 해야한다.

(2.2) Speak to the Round Table: 헤쳐모여

Q. 팀원 간의 싱크를 맞추는 방법은?

A. 짧고 정기적인 회의를 운영하자.

• 레거시 시스템에 대한 지식과 이해도는 분산되어있거나, 숨겨져있다.
• 리엔지니어링 팀도 고고학을 연구하는 것처럼, 지식을 파헤친다.
• 레거시 시스템에서 추출한 정보를 활용하는 것은 반드시 공유되어야하는 귀중한 자산이다.
• 누구도 회의할 시간은 없다. 그러나 회의를 하지 않으면, 커뮤니케이션은 임시적이거나 무작위로 진행된다.그러다보면 관련자가 모두 참석하지 않은 채로 커뮤니케이션을 하게 된다. 그러면 중복으로 토론을 하게 되고, 결정이 지연된다.
• 정기적이고 집중적인 원탁 회의가 있으면, 팀원들이 현재 상황에 대한 최신 정보를 공유할 수 있다. 원탁 회의는 짧게 진행하되, 모든 사람이 참여해야 한다.
• 간단한 진행 방법은 다음 세 가지를 말하는 것이다.
  • 지난 회의 이후 무엇을 했는지
  • 무엇을 배웠는지 or 어떤 문제가 발생했는지
  • 다음 회의까지 무엇을 할 계획인지
• 원탁 회의는 적어도 주1회, 많게는 매일 개최하는 것이 좋다.
• 귀찮은 일이 될 수 있다. 간단하게 유지하려면 특정 기한까지 내린 결정과 수행할 조치만 기록하자.

 

2.4 Most Valuable First: 가장 가치있는 것을 먼저 하자.

Q. 가장 먼저 집중해야하는 것은 무엇인가?

A. 고객에게 가장 가치있는 작업부터 시작해야한다.

레거시 시스템은 많은 문제가 있다. 그 중 어떤건 중요하지만, 어떤건 고객의 비즈니스에 전혀 중요하지 않을 수 있다.

가장 가치있는 부분에 집중하면 다음과 같은 이점을 얻을 수 있다.

• 당면한 올바른 문제를 파악할 가능성이 높아진다.
• 가장 중요한 결정을 프로젝트 초기에 테스트할 수 있다.
  • 어떤 아키텍처로 마이그레이션할지
  • 새로운 시스템에 어떤 종류의 유연성을 반영할지

클라이언트에게 가장 가치있는 시스템을 먼저 개발하면, 팀원과 고객의 프로젝트에 대한 헌신도도 극대화할 수 있다.

리엔지니어링 노력이 가치있고, 필요하다는 것을 프로젝트 초반부에 인정받을 가능성도 높아진다.

 

2.5 Fix Problems, Not Symptoms: 증상이 아니라, 문제를 해결하라

증상이 아니라 문제의 근본적인 원인을 해결하자.

각 이해관계자마다 보는 관점이 다를 수 있다. 혹은 보고 있는게 다를 수 있다. 그래서 스택홀더가 해결하기를 원하는 문제는 실제로 더 본질적인 원인이 있을 수 있다.

리엔지니어링 작업중 흔히 겪는 어려움이 있다. 세가지 갈래에서 고민하게 된다.

1. 레거시 컴포넌트를 래핑하기
2. 리팩터링하기
3. 다시 개발하기

사례를 통해 해결 방법을 살펴보자.

Q. 레거시 컴포넌트가 비교적 안정적이고, 클라이언트를 수정할 때 문제가 빈번하게 발생하는 경우에는?

A. 이 경우, 인터페이스에 문제가 있을 수 있다. 이 경우, 올바른 인터페이스를 제시하여 인터페이스만 수정해야한다.

Q. 레거시에 결함은 거의 없지만, 시스템을 변경하기 어려운 구조라면?

코드 수정 시, 사이드 이펙트를 줄이기 위해 리팩토링을 해야한다. 깔끔하게 마이그레이션을 하기 위해 클래스 분할을 참고하면 된다.

Q. 레거시 컴포넌트에 결함이 많은 경우에는?

새로 만들자.