프레임워크 리팩토링 정리

본 내용은 월간 마소 2009년 03월호에 실린 내용을 정리한 것입니다.
불펌을 금지하며, 문제시 삭제하겠습니다.

프레임워크 리팩토링

• 리팩토링?
  • 결과의 변경없이 코드의 구조를 재조정
  • 암튼 수정한다는 뜻임
• 언제할까?
  • 너무 늦으면 리팩토링할 수 없을 지경이 될수도 있음
  • 습관적으로 자주 리팩토링하는게 좋을듯
  • 2개 함수 이상일 경우 함수끼리 상호작용이 일어날때..
  • 욕심쟁이 알고리즘(현재꺼만 최선을 다함)과 비슷
• 어떤거?
  • 리팩토링은 습관이다. 뭘할지가 중요한건 아님.
  • 2개의 객체가 양방향이라면, 단방향으로 바꾸자, 필요한 놈만 Get/Set
  • Object같은걸로 리턴하지 말고, 특정객체로 리턴하자
  • 복잡한 if문 제거, 메소드로 빼라
  • 너무 간단한 함수들은 합쳐라
  • 함수 내부의 if가 너무 복잡하면 return을 여러번 사용
  • 부정의 부정을 읽기는 어렵다
• 모듈단위의 리팩토링이 중요

 

애플리케이션 프레임워크 설계 원칙과 리팩토링

• 설계원칙
  • 분명한 목적과 철학이 있어야 한다.
  • http://toby.epril.com/?p=403
• 프레임워크가 제공할 가치
  • 확장성 및 범용성
  • 고성능
  • 아키텍처 가변성 지원
  • 개발 생산성 향상
  • 설정 편의성
  • 시스템 통합 일관성
  • 테스트 용이성
  • 정책 가변성 지원

프레임워크 리팩토링

• 리팩토링 검증방법 : 회귀테스트
  • 버그가 없을것 : 수정전 테스트 케이스가 정상실행되어야 함
  • 기존 기능의 변경이 없을것
  • 리팩토링 이전 테스트 환경을 기억하기 위해서도 테스트 기반 리팩토링이 좋다.
• 테스트 케이스 작성 과정 및 이슈
  • 테스트 대상 클래스 선정
    • 테스트 대상 제외 : DTO클래스, 인터페이스, 추상클래스
    • 비지니스 로직이 포함된 메소드를 가진 추상클래스는 이를 상속한 별도의 Mock객체를 사용하여 테스트 할것
  • 테스트 대상 메소드 선정
    • 제외 : setter/getter메소드, private메소드, static메소드(유틸성), static방식으로 다른 클래스의 API를 호출하는 메소드
  • 테스트 시나리오 선정 준비
    • 메소드에 담긴 비지니스 로직을 이해
    • 메소드에 포함된 고객의 요구사항을 추출
    • 메소드를 작성한 개발자의 의도 파악
• 테스트 시나리오 작업
  • 테스트 클래스 역할 파악
  • 메소드 역할 파악
  • 메소드 파라메터 분석 : 역할은? 쓰이는가? 파라메터 체크하고 있나? 파라메터 값을 가공하나?
  • 메소드 내 분기문 분석 : 어떤 시점에 분기? 분기를 결정하는 변수는? 분기가 발생하는 시점의 변수값은?
  • 메소드 리턴값 분석 : 무엇을 리턴? 리턴값의 의미는? 언제 리턴값이 달라지지?
  • 테스트 구현방식 결정 예제
    • 프레임워크 : NUnit
    • Mock 라이브러리 : easyMock
    • DB 관련 통합 테스트 : xxx를 사용한 팀 자체 개발 테스트 케이스
  • Mock 라이브러리가 배포되었으면.. 이를 사용할지? 아니면 사용자 정의 Mock을 만들지?
  • 단위테스트? 통합테스트? 통합테스트는 DB접속 or 서버와 통신등의 환경시 어쩔 수 없이 사용
  • 테스트 데이타 선정 : DB data, DB Sequence....
• 테스트 작성
  • 테스트 의도 명확히 드러내기
    • 고려사항
      • 메소드 명 길이에 연연하지 않는다 :
      • 메소드 작명 규칙을 정한다 :
      • 한글 메소드 사용도 고려한다
    • 방법
    • 메소드명 : test + 대상메소드명 + 테스트의도 
      (testCopyFilePathTypeIsYMD() ==> CopyFile 메소드 테스트시 path가 YMD..)
    • 주석 : 코드에 적절한 주석
    • 변수명 : 변수명에 테스트 의도를 드러냄
  • 예외 테스트
    • AssertThrows 사용 : sping에서..
    • try~catch 사용
  • – 테스트 케이스 수
    • 하나의 테스트 케이스로 여러 테스트 시나리오 구현하면, 코드 가동성 및 의도 파악에 좋다.
• 테스트 코드 리팩토링
  • 반복적으로 사용되는 코드는 별도의 추상 클래스나 상위 클래스로 추출하여 코드 중복 제거

휴리스틱 프레임워크 리팩토링

• 프레임워크
  • 특정 도메인에서 해결해야 하는 문제점의 공통적인 해결방법 구현체 및 디자인을 가져야 함
  • 일반적일 App 만드는 것보아는 오래걸림
  • 차후의 다양한 App 기능 예측..
  • 암튼 일반 App 만드는 것보다 계획적인 개발과 발전단계가 필요

• 프레임워크 개발 방법론
  • 랄프존슨의 논문 : 일반적으로 9단계의 패턴 언어를 거치는 방법을 개발된다.
  • 1) Three Example : 세가지 애플리케이션 패턴
  • 2) White-box Framwork : 화이트박스 패턴
  • 3) Component Library : 컴포넌트 라이브러리 패턴
  • 4) Hot Spots : 핫 스팟 패턴
  • 5) Pluggable Object : 플러그러블 오브젝트 패턴
  • 6) Fine-grained Object : 파인-그레인드 객체 패턴
  • 7) Black-box Framework : 블랙박스 패턴
  • 8) Visual Builder : 비주얼 빌더 패턴
  • 9) Language Tools : 언어도구 패턴

• 프레임워크 발전 단계의 한계

  • 미래에 만들어지게 될 App 기능을 예측 불가
  • 반복되는 오버라이딩(Hot Spots)으로 인한 수정사항 요구를 프레이워크 유지보수자는 분석해야함
  • 이전 프레임워크의 발전과정을 유지보수자는 알아야 효율적

• 프레임워크 리팩토링
  • Hot Spots(자꾸 오버로딩해서 사용되는 놈)과 Frozen Spots(거의 그대로 쓰는놈)를 파악하여야 함
  • Graph-based Model(그래프 기반 모델)로 나쁜냄새 맡기
  • Control Flow Graph(제어 흐름 그래프)로 테스트 및 디버깅시 사용
  • Forward Dominance Tree(포워드 도미넌스 트리)로 영향을 주는 노드 찾기
  • Control Dependence Graph(제어 종속성 그래프)로 종속성 찾기
  • Data Dependence Graph(데이터 종속성 그래프)