[IT/개발] 프레임워크 정의와 개발 요점

프레임워크의 정의
•더글라스 슈미츠 (POSA2 저자) : 프레임워크는 도메인 기반의 지식으로 구성된 객체 구조와 기능을 가지고 있는 "반쯤 완성된 애플리케이션"이다.
•랄프존슨 : 추상클래스들의 집합과 상호 협조하는 클래스들의 인스턴스 동작방법으로 이루어진 재사용 가능한 디자인

프레임워크 개발을 위해 고려할 5가지 기본 속성
•1) 조직 : 조직을 먼저 구성하지 마라. 비지니스 파악 --> 관련된 프로세스 정제 --> 프로세스에 맞게 IT 조직 구성
•2) 계획 : 땅콩버터 (특징을 중심으로 골고루 구현하는 Bottom-UP 방식. 기능중심의 팀이 필요), 마천루(시나리오 중심으로 구현, 특정모듈에만 집중적인 개발이 됨)
•3) 아키텍처 : 아키텍처 타입, API, 실행, 의존성을 고려해 Layering을 구축. 의존성 분석을 위해 xDepend 같은 툴을 사용
•4) 설계 : 메인 시나리오에 부합되는 코드 샘플 만들기 -> 객체 모델 정의. 디자인 스튜디오 등의 툴을 사용하여 설계
•5) 개발 : 80/20룰을 적용해 효율성 고려
•6) 그밖에 : 산출물 가독성, 문서화, 네이밍룰, 프레임워크 매뉴얼

프레임워크 이해를 위한 패턴언어
•1) 프레임워크 선택하기 : 화이트박스(hot spots의 수정 위해 상속과 동적바인딩을 사용)/블랙박스(hot spots의 수정 위해 인터페이스를 사용)/그레이박스 프레임워크
•2) 프레임워크를 이용한 프로젝트 레퍼런스 만들기 : 적당한 예제단위로 레퍼런스를 구축한다면 효율성이 높음
•3) 프레임워크 발전시키기 : 도메인 적용되고 나타나는 문제를 해결하여 다시 프레임워크에 반영해야
•4) 프레임워크 학습
•5) 사용 경험의 보전 방법 : 프레임워크 사용경험을 문서화시키고, 실전코드들을 레퍼런스나 케이스로 정리할것
•6) 애플리케이션 도메인의 이해 : 프레임워크가 App에서 구현할 문제를 해결할 수 있는 범위 파악하는 것이 중요
•7) 프레임워크 아키텍처의 이해 : 프레임워크는 App에 직접적 영향 미침, 구조 파악하면 정확한 프레임워크 사용 가능
•8) 프레임워크 내부 디자인의 이해 : 프레임워크가 복잡하다고 느끼는 것은 내부 디자인이 복잡해서임.
•9) 프레임워크 코드의 이해 : 프레임워크 개발자의 코드는 후배들의 본보기가 되므로 잘 짜라

프레임워크 엔지니어링
•고려할 6가지 사항
•조직 (가장 강력한 설계 툴) : 콘웨이의 법칙 : 팀 구조가 소프트웨어 구조에 영향 미침
•계획 (프레임워크를 올바르게 구축하기 위한 계획) : 마일스톤 = 땅콩버터 + 마천루 (인프라 구축 초기에는 땅콩버터, 인프라 구축된 후 땅콩버터 유지하되 점진적으로 마천루 혼합)
•아키텍처 (오랫동안 사용할 수 있는 품질 좋은 프레임워크를 만들기 위한 고려사항들) : IoC 사용하여 의존성 제거할것, xDepend 도구 사용
•설계 (품질을 보장하기 위해 고려할 사항들) : 메인시나리오 작성 ==> 시나리오에 부합되는 코드샘플 작성 ==> 개발자들에게 피드백하여 정제 ==> 객체 모델 정의 (프레임워크 디자인 스튜디오 도구 사용), 동일성을 위해 FxCop, StyleCop 도구 사용
•개발 (프레임워크를 만들기 위해 팀플레이 시 고려해야 되는 사항들) : Feature별 Quality Gate 구성할것.
•그 외에 고려해야 되는 것들 (가독성, 문서화) : 문서 제공할것
•좋은 프레임워크란..
•쉽게 배워야
•문서 없이도 쉽게 사용해야
•실수하지 않도록 직관적이여야 (실패하기 힘들도록..)
•프레임워크 사용하면 코드가 읽기 쉬워야 (유지보수성도 좋아짐)
•확장이 쉬워야
•사용자를 고려해야..

프레임워크 구축과 발전 - 랄프존슨의 9가지 패턴
•1) 세가지 애플리케이션 패턴 : 3개 이상의 App을 만들어서 재사용 모듈 파악
•2) 화이트박스 패턴 : 인터페이스를 사용하여 상속하라. 없으면 구현클래스에서 유추하여 만들어라. 상속을 이용하여 프레임워크의 기능 확장 구현을 반복한다.
•3) 컴포넌트 라이브러리 패턴 : 재사용하지 않는 클래스는 프레임워크에 넣지않고, 애플리케이션의 구현클래스에 위치
•4) 핫 스팟 패턴 : 화이트박스 패턴으로 계속 추가하고, 컴포넌트 라이브러리 패턴으로 계속 제거 --> 기존 클래스와 추가될 클래스의 관계를 정의하면서 확장하여 중복을 막자
•5) 플러그러블 오브젝트 패턴 : 객체 생성시 다양성 구분에 필요한 인자 사용 --> 객체가 인자에 따라 행동하게 개발
•6) 파인-그레인드 패턴 : 간단한 API가 복잡한 API보다 사용하기 쉽다 --> Small Objects Pattern
•7) 블랙박스 패턴 : 애플리케이션은 요구변경에 유연해야 함 --> 클래스의 확장에는 열려있고, 수정에는 닫혀 있어야 함. --> 상속보다는 구성을 사용
•8) 비주얼 빌더 패턴과 언어 도구 패턴 : 프레임워크 정리한 문서, 프레임워크 사용을 도와주는 툴 등을 제공할것

 

 

애플리케이션과 프레임워크 동시 개발
•1) Framelets for Multiple Use : 심플할 수 있고, 3번이상 재사용될꺼면 프레임워크를 개발해라
•2) Budget Factor 2.5 : 프레임워크는 애플리케이션보다 비싸다. F개발 = 2.5 * A개발
•3) Two Pilot Applications : 매우 보편적인 요구사항을 가진 애플리케이션 2개를 먼저 만든 후 프레임워크 개발
•4) Small Functions : 기능은 많고 작고 단순하게 구현하라. 이해하기 좋고 많은 요구사항에 적합하다
•5) User Involvement : 사용자에게 같이 참여시켜서 확신을 줘라. 교육/툴/테스트/튜토리얼 제공하라
•6) Tests Based on Pilot Applications : 회귀테스트 - Pilot Applications에서 핵심 컴포넌트 추출 --> 보편적 시나리오 추출 --> 테스트
•7) Double Change Request : 기능추가 요구가 있을때 적어도 2팀 이상 원할때 추가하라.

프레임워크 리팩토링
•리팩토링 검증방법 : 회귀테스트
•테스트 케이스 작성 과정 : 테스트 대상 클래스 선정 --> 테스트 대상 메소드 선정 --> 테스트 시나리오 선정 준비
•테스트 시나리오 작업 : 테스트 클래스 역할 파악. 메소드 역할 파악. 메소드 파라메터 분석. 메소드 내 분기문 분석. 메소드 리턴값 분석....
•테스트 작성 : 테스트 의도 명확히 드러내기. 예외테스트도 수행.
•테스트 코드 리팩토링 : 반복적으로 사용되는 코드는 별도의 추상 클래스나 상위 클래스로 추출하여 코드 중복 제거

출처: http://kimstar.pe.kr/blog/190 <-- 여기 가시면 더 잘 정리되어 있습니다.