애플리케이션과 프레임워크 동시 개발

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

 

값 비싸고 어려운 프레임워크

• 프레임워크를 사용한다는 것 : 기능을 재사용뿐만 아니라, 추상화 수준과 구조(Design)까지 재사용
• 애플리케이션 만드는 것보다 비용이 많이 듬.

프레임워크와 애플리케이션을 동시 구축해야 되는 상황

• 일반적으로 비슷한 애플리케이션을 개발후 프레임워크 개발하는게 좋음 (Three Examples 패턴)
• ex) 보험회사 전산 시스템 = 건강보험 시스템 + 생명보험 시스템 + 손해보험 시스템 ==>
  재사용 부분이 보임 ==> 프레임워크와 애플리케인션 개발을 병렬적으로 진행 ==> 
  프레임워크 개발 적임자 선정 ==> Three Examples 이 없어서 난감함 ==> 
  프레임워크 설계가 힘듬 ==> 어떻게 하지????

프레임워크와 애플리케이션을 동시 구축하기 위한 패턴언어

• 아휴.. 약어로 써야겠다.. 프래임워크 = F, 애플리케이션 = A
• 2000년 PLoP(Pattern Language of Programs) 에서 F와 A를 동시 개발하기 위한 7가지 패턴을 발표
• 1) Framelets for Multiple Use
• 2) Budget Factor 2.5
• 3) Two Pilot Applications
• 4) Small Functions
• 5) User Involvement
• 6) Tests Based on Pilot Applications
• 7) Double Change Request

1) Framelets for Multiple Use

• F와 A를 동시에 구축하는 것을 어떻게 합리화 할껀가?
  • 프레임렛(Framelet) : 작은 F, ex) DB접근 F
  • Rule of Three
    • 재사용 가능한 SW 구축 기준
    • 최소 3번 이상 재사용이 보장되어야만 재사용 가능한 SW를 구축하라
  • 재사용 가능한 기능에 대해 팀별로 요구사항이 미묘하게 다르다.. 그럼에도 불구하고 비싼 비용으로 F를 만들어야 할까??

• 심플할 수 있고, 3번이상 재사용될꺼면 F를 개발해라
  • 심플 : F가 할일이 많으면 사용자들의 요구사항 충돌할 가능성이 높아진다. 심플하게 가자
  • 3번 이상 재활용 : 3번 이하로 재사용될꺼면 비용 측면에서 F개발 안하는게 좋다.
  • 헐리우드 원칙 : don't call us, we call you. 의존성을 고려하자

2) Budget Factor 2.5

• F 구축시 필요한 예산은?
  • F는 A보다 비싸다. 왜? 추상화 수준을 찾고 일반화 기능을 제공하기 어려워서..
  • F개발 뿐만 아니라, 유지보수, 교육도 책임져야 함.
  • F와 A를 동시에 개발하려면 A개발기간과 동일하다는 얘기므로.. 그동안 다 해야 한다. 시간이 모자라다..
  • F가 늦으면 A도 늦어진다.
  • 얼마의 예산이 있어야 F 개발이 가능할까나?

• F예산은..
  • F개발 = 2.5 * A개발
  • 3 * A개발 = F개발 + 3 * F이용한 A개발
  • F이용한 A개발 = 1/6 * A개발
  • 충분한 실력을 갖춘 팀을 찾아라. 충분한 인원도..
  • Jim Coplien의 Size The Organisation 패턴 / Size The Schedule 패턴 참조할것.

3) Two Pilot Applications

• F 요구사항을 어떻게 찾나?
  • 이미 구현된 A들이 있다면 : 차이점 제거하고, 공통된 추상화를 찾아라.
  • 이미 구현된 A들이 없다면 : Two Pilot Applications !!

• F에서 사용할 Two Pilot Applications 찾아라
  • Two Pilot Applications은..
    • 매우 보편적인 요구사항을 가진 A
    • 핵심적인 F 사용자들과 밀접한 관계를 유지하는 중요 역할
    • 좀 더 일찍 개발해야 함.
  • A개발팀과 F개발팀이 같은 장소에서 개발하며 서로 피드백하자

4) Small Functions

• F의 기능들을 인터페이스로 어떻게 나눌까?
  • "적은 수"의 기능으로 구성된 F의 이해가 쉽고, 기능이 "단순"할 수록 F 이해가 쉽다.

• 기능은 많고 단순하게
  • trade-off에 따른 고민 : 개수는 적지만 크고 강력한 기능 vs 개수는 많지만 작고 단순한 기능
  • 개수는 많지만 작고 단순한 기능이 좋다.. 마치 뷔페처럼..
    • 이해하기 쉽다
    • 특정조건에 상관없이 사용자들이 원하는 기능에 부합될 가능성이 높다.
    • 기능들을 결합하여 사용자가 원하는 기능을 만들 수 있다.

5) User Involvement

• F사용하는 A개발자에게 F의 확신을 심어주려면?
  • A개발자가 F 경험부족 또는 F 이해부족으로 실패시.. F의 문제라고 생각할 수 있다.
  • F는 유연성 & 효율성의 관계를 고려해야 함. 효율성이 중요하다면 성능이 잘 나오도록 F를 확장할 수 있도록 제공해야 함

• F 사용하는 팀을 참여시켜라
  • 워크샵을 통해 F를 A에 적용하는 법을 교육
  • A쉽게 만드는 툴 제공 & 교육
  • F적용된 A 테스트 제공
  • F적용된 A 최적화 방법 제공
  • F의 튜토리얼 제공

6) Tests Based on Pilot Applications

• F의 버그는 모든 A에 영향을 미친다. 어떻게 F를 신뢰성 있게 테스트 하지?
• 회귀 테스트
  • Pilot Applications 에서 핵심적인 component를 찾는다.
  • Pilot Applications 에서 가장 보편적인 시나리오를 찾는다.
  • Pilot Applications 에서 적용한 테스트를 F가 변경된 경우에도 테스트한다.

7) Double Change Request

• F에 새로운 기능을 추가해 달라고 하면.. 다른 팀에서는 안쓰는 기능일 수도 있다.. 심플하고 싶은데.. 추가하는 기준이 필요하다.
• 기능 추가하는 기준 : 다른팀에도 물어봐서.. 적어도 2팀 이상이 추가 기능을 필요할 경우 수락하라.