프레임워크 리팩토링 정리

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

프레임워크 리팩토링

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

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

  • 설계원칙
  • 프레임워크가 제공할 가치
    • 확장성 및 범용성
    • 고성능
    • 아키텍처 가변성 지원
    • 개발 생산성 향상
    • 설정 편의성
    • 시스템 통합 일관성
    • 테스트 용이성
    • 정책 가변성 지원

프레임워크 리팩토링

  • 리팩토링 검증방법 : 회귀테스트
    • 버그가 없을것 : 수정전 테스트 케이스가 정상실행되어야 함
    • 기존 기능의 변경이 없을것
    • 리팩토링 이전 테스트 환경을 기억하기 위해서도 테스트 기반 리팩토링이 좋다.
  • 테스트 케이스 작성 과정 및 이슈
    • 테스트 대상 클래스 선정
      • 테스트 대상 제외 : 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(데이터 종속성 그래프)

 

오늘은 월드컵 아르헨티나와의 경기하는 날..
한국형 부부젤라는 이런 느낌!!

사용자 삽입 이미지

CC BY-NC-ND 2.0 KR

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스

저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.

댓글 남기기