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

본 내용은 월간 마소 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팀 이상이 추가 기능을 필요할 경우 수락하라.

 

 

읽느라 수고했어염.. 쪽~
사용자 삽입 이미지

CC BY-NC-ND 2.0 KR

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

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

댓글 남기기