오래된 SW 엔지니어의 평생 공부

[1]의 5장 "디테일한 모델 캡처"는 소프트웨어 시스템의 이해와 리엔지니어링 과정을 지원하기 위한 다양한 방법론을 제공합니다. 이 문서는 시스템을 더 잘 이해하고, 코드의 설계와 동작을 개선하기 위해 사용할 수 있는 구체적인 패턴들을 설명한다. 주요 내용은 다음과 같다.

1. 코드에 대한 질문을 연결하기: 소스 코드에 직접적으로 질문과 주석을 추가하여, 코드의 특정 부분에 대해 이해하고, 팀 내에서 지식을 공유한다.
2. 이해하기 위해 리팩터링하기: 코드의 일부를 반복적으로 리팩터링하여, 코드의 설계를 명확하게 하고 이해도를 향상시킨다. 이 과정은 코드에 대한 가설을 검증하는 실험으로 간주된다.
3. 단계 별 실행해 보기: 런타임에 객체가 어떻게 인스턴스화되고 상호작용하는지 관찰하기 위해 코드를 단계별로 실행한다.
4. 컨트랙트 찾기: 코드에서 클래스 간의 클라이언트-공급자 관계를 분석하고, 인터페이스가 어떻게 사용되어야 하는지를 명확히 한다.
5. 과거로부터 배우기: 과거의 코드 버전을 분석하여, 특정 설계 결정들이 왜 내려졌는지 이해하고, 이를 통해 더 나은 설계 결정을 내리는 데 도움을 준다.

여기서 개발자들이 기존 소프트웨어 시스템을 이해하고, 유지 관리하며, 효과적으로 리엔지니어링할 수 있도록 돕기 위해 설계되었다.

참고 문헌

[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"

[2] https://github.com/blcktgr73/OORP 

[1]의 4장 초기 이해에서는 소스 코드의 초기 분석을 위한 세 가지 주요 패턴을 제시한다. 퍼시스턴트 데이터 분석하기, 디자인 추측하기, 예외적인 엔터티 연구하기가 그것이다. 각 패턴은 리엔지니어링 프로젝트의 성공적인 진행을 위한 필수적인 단계이다.

퍼시스턴트 데이터 분석하기

• 의도: 데이터베이스 시스템 내부에 보관해야 할 중요한 개체를 식별하고 이해한다.
• 문제: 귀중한 데이터는 외부 저장 장치에 보관되어야 하지만, 정리되지 않은 데이터와 혼재될 수 있다.
• 해결:
  1. 모든 테이블 이름을 열거하여 초기 모델을 준비.
  2. 각 테이블에 대해 열 이름을 수집하고 속성으로 추가.
  3. 후보 키 및 외래 키 관계를 분석.
  4. 상속 관계를 유추하여 클래스 다이어그램을 도출.
  5. 데이터 샘플과 SQL 문을 통해 검증.
• 장점: 팀 커뮤니케이션 개선, 가치 있는 데이터 추출.
• 단점: 범위 제한, 정크 데이터 포함, 전문 지식 필요.

디자인 추측하기

• 의도: 소스코드에서 디자인 개념을 복구하여 가설을 검증하고 구체화한다.
• 문제: 많은 디자인 개념이 있으며 프로그래밍 언어에서 이를 표현하는 방법이 다양하다.
• 해결:
  1. 초기 가설 역할을 하는 클래스 다이어그램 작성.
  2. 클래스, 연산, 속성 이름을 소스 코드에서 찾아 가설 검증.
  3. 불일치를 기반으로 클래스 다이어그램을 조정.
  4. 만족스러운 다이어그램을 얻을 때까지 반복.
• 장점: 대규모 객체 지향 프로그램에 유리, 저렴한 리소스 투자.
• 단점: 전문 지식 필요, 시간이 많이 소요됨.

예외적인 엔터티 연구하기

• 의도: 시스템에서 예외적인 엔터티를 식별하고 분석하여 전체 구조를 이해한다.
• 문제: 예외적인 엔터티는 일반적인 패턴을 따르지 않으며, 특별한 처리가 필요하다.
• 해결:
  1. 예외적인 엔터티를 식별.
  2. 해당 엔터티의 특성과 동작을 분석.
  3. 다른 엔터티와의 관계를 이해하여 시스템 전체의 구조를 파악.
• 장점: 시스템의 비정상적인 부분을 이해하고 해결하는 데 도움.
• 단점: 예외적인 상황을 처리하기 위한 추가 분석이 필요.

이 세 가지 패턴은 소프트웨어 리엔지니어링 프로젝트의 초기 분석 단계에서 시스템을 이해하고 문서화하는 데 필수적인 방법들이다. 이를 통해 프로젝트의 안정적인 기반을 구축하고, 성공적인 진행을 보장할 수 있다. [2]에서 번역된 내용을 찾을 수 있다.

참고 문헌

[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"

[2] https://github.com/blcktgr73/OORP 

[1] 의  3장 초기 접근 방법에 다음과 같은 리엔지니어링 프로젝트 예제를 이용해서 실제 예시로 패턴에 대해 설명한다.

• 시나리오: 사용자 팀은 의료 소프트웨어 시스템인 proDoc을 개발하고 있으며, 경쟁사인 XDoctor의 인터넷 기능을 proDoc에 통합하려고 합니다.
• 주요 과제: 시스템을 통합하고 리엔지니어링하기 위해 첫 번째 평가와 계획을 수립하는 것입니다.

주요 요구사항

1. 규모 문제: 레거시 시스템이 크고 복잡하므로 이를 관리 가능한 부분으로 나누어야 한다.
2. 시간 부족: 프로젝트 초기에는 시간을 낭비하지 않도록 주의해야 한다.
3. 불완전한 지식: 초기에 중요한 결정을 내릴 때 불완전한 지식으로 인해 잘못된 결정을 내릴 수 있다.
4. 다양한 이해관계: 여러 이해관계자들이 서로 다른 의제를 가지고 있을 수 있다.

패턴 적용:

• 유지보수자와의 담소나누기: 시스템의 역사적, 정치적 맥락을 이해하기 위해 유지보수자와 논의한다.
• 한 시간 안에 모든 코드 읽기: 소프트웨어 시스템의 상태를 빠르게 평가하기 위해 집중적으로 코드를 검토한다.
• 모의 설치 수행하기: 리엔지니어링 적합성을 평가하기 위해 시스템을 실제로 설치하고 실행해 본다.
• 문서 스키밍하기: 관련 문서를 빠르게 검토하여 중요한 정보를 파악한다.
• 데모 중 인터뷰하기: 시스템을 사용하는 사람들과 인터뷰를 통해 추가 정보를 수집한다.

예시

예시에서는 앞에서 설명한 것의 사례에서 일어 났던 경험을 해당 패턴에 연계하여 이야기 한다.

• XDoctor 인수: XDoctor의 개발팀에서 유일하게 남은 데이브와의 대화를 통해 중요한 기술적 정보를 얻고, 두 시스템을 통합하는 계획을 세훈다.
• 코드 검토: Java와 C로 작성된 코드를 검토하여 시스템의 구조와 품질을 평가한다.

결론

리엔지니어링 프로젝트를 성공적으로 수행하기 위해서는 초기 단계에서 정확한 평가와 계획이 중요하며, 이를 위해 다양한 패턴을 적용하여 시스템의 상태와 문제를 파악해야 한다고 이야기한다. 이 패턴들을 읽어 보면, 실재로 경험한 듯한 것들이 많다. 특히, 유지보수자와 담소나누기, 모의 설치하기 등은 마치 내 경험을 몰래 들여다 본 것 같은 느낌도 들 정도였다. 다른 것들의 경우도, 일부는 경험한 듯 하고 시간 제약을 두고 하는 것도 눈에 띄는 이야기였다. 무엇보다도 사회적 맥락에서 접근하는 패턴은 이 부분이 매우 실용적인 것이라는 생각도 많이 들었다. [2]에 번역 내용이 올라가 있다.

참고 문헌

[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"

[2] https://github.com/blcktgr73/OORP