고상원@funkcode

프레임워크와 어플리케이션함께 개발하기

# 패턴 & 프레임워크 이야기

Wednesday, June 29,

•오늘 하려는 이야기는..

기술에 대한 패턴이 아닙니다.

개발하면서 발생하는 다양한 이슈에 대한 패턴입니다.

Wednesday, June 29,

•References

Building Frameworks and Applications Simultaneously - Andreas Ruping, PLOP2000

Wednesday, June 29,

•패턴이란?

•프레임워크란?

먼저 살펴볼 이야기

Wednesday, June 29,

패턴이란?

경험으로 얻은 지식의 재활용

Wednesday, June 29,

“김대리 신규 프로젝트 일정 좀 작성해"

‘헉! 어떻하지.. 전혀 모르는 분야인데..’

‘예전에 박대리가 만들었던 일정을 참고해야겠다.’

선지자의 경험 / 고민을 특정 매개체를 통해서간접적으로 체험할 수 있음

Wednesday, June 29,

패턴은 이론적이다

실용적

Wednesday, June 29,

패턴의 구성

문제점고려사항해결책연관된 패턴들

- 다양한 템플릿이 존재

- 오늘의 구성 :

Wednesday, June 29,

쉽게 하는 실수 :

Solution에 집중한다

Solution에 집중하면, 탁상공론

Context와 Force 등에 현실적인 고민이 나타남

Wednesday, June 29,

프레임워크란?Flow of control, Generic functionalitySemi Application, Reusable Design

- 전체가 아닌 공통된 부분을 프레임워크化하는 경우 多

Wednesday, June 29,

“프레임워크를 개발해야 할까?”

어플리케이션들이 공통된 기능을 가지고 있음

프레임워크를 개발해야 될 시점 :

Wednesday, June 29,

근데,

프레임워크가 필요하다

공통된 기능

참고할 어플리케이션도 없다!

Wednesday, June 29,

프레임워크를 어떻게 만들지?

어플리케이션도 없고,프레임워크도 없고,프레임워크는 사용하고 싶고,개발을 해야되나? 말아야 되나?

Wednesday, June 29,

뭐.. 이거.. 그냥..

프레임워크와 어플리케이션을 같이 만들면 안되나?

똑같은 프로그램 여러 개 만드는건데, 뭐..

김대리 잘하잖아? 우리 핵심인재니까! 다들 보고 배워~

그..그게..

...

Wednesday, June 29,

언제,

무엇을 고민하고,

어떻게 해결해야 될까?

Wednesday, June 29,

기획

요구사항 분석

설계

개발

테스트

유지보수

Framelets for Multiple Use

Budget Factor 2.5

Two Pilot Application

Small Functions

UserInvolvement

Tests Based on Pilot Applications

Double Change Request

Wednesday, June 29,

Framelets  forMul.ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica.ons

SmallFunc.ons

Double  ChangeRequest

Test  Based  OnPilot  Applica.ons

Wednesday, June 29,

프레임워크와 어플리케이션을

같이 개발해야 되는 합당한 이유?

1.  Framelets  for  Mul.ple  Use

Wednesday, June 29,

TEAM A어플리케이션

ApplicationA

TEAM B어플리케이션

ApplicationB

TEAM C어플리케이션

ApplicationC

공통된 기능

프로젝트 팀

프레임워크없나요?

프레임워크가 구축될 때까지, 기다릴 수 없음

Wednesday, June 29,

1. 어플리케이션들이 중복된 기능을 가지고 있음

2. 프레임워크가 없음

3. 프레임워크가 먼저 준비될 때까지 기다릴만한 시간적

여유가 없음

[정리] 어플리케이션과 프레임워크가 동시에 개발되어야 하는 경우

Wednesday, June 29,

1. 공통된 기능이 있지만,

사용 방법이 조금씩 다르다. 관심사항도..

2. 손익분기점

3. 어플리케이션의 구현이 시작되기 전에,

프레임워크의 첫 버전 준비

고려사항

Wednesday, June 29,

둘째, 프레임워크를 적어도 세 번 이상은 사용될 수 있을 때

두 가지 조건을 만족할 때만 프레임워크를 구축해라

첫째, 심플하게 만들 수 있을 때

해결책

Wednesday, June 29,

연관된 패턴들

Framelets  forMul.ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica.ons

SmallFunc1ons

Double  ChangeRequest

Test  Based  OnPilot  Applica1ons

Wednesday, June 29,

비용이 얼마나 들어갈까?

2.  Budget  Factor  2.5

Wednesday, June 29,

1. 어플리케이션 개발 비용 < 프레임워크 개발 비용

(약 2~3배)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

누적비용

제품 개수

Product Line DevelopmentTranditional Development

Calculating ROI for Software Product Lines IEEE SOFTWARE, 2004

고려사항 #1

Wednesday, June 29,

2. 여러가지 업무 병행 : 개발, 유지보수, 코칭

3. 지연이 발생하는 경우,

어플리케이션 개발팀의 일정도 지연

고려사항 #2

개발팀에서 별도 라이브러리를 사용하는 경우 발생 = 프레임워크 無의미

Wednesday, June 29,

1. 어플리케이션을 개발 비용의 약 2.5배로 산정

2. 프레임워크 개발 실력을 갖춘 팀으로 구성

3. 어플리케이션을 개발하는데 필요한 인원 수의 약 두배 정도의 인원을 가지고 시작

해결책

Wednesday, June 29,

1. 올바른 추상화(the  right abstractions)를 찾기 어려움

2. 프레임워크를 사용하는 다른 팀을 코칭해줘야 함

추가적인 예산이 더 필요한 이유

1. 프레임워크가 세 번 사용된다면, 충분히 이득

2. 프레임워크 사용자를 교육하는 일은 프로젝트의 성공에 기여

거기다가..

Wednesday, June 29,

연관된 패턴들

Framelets  forMul.ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica1ons

SmallFunc1ons

Double  ChangeRequest

Test  Based  OnPilot  Applica1ons

SIZE  OF  ORGANIZATION  

/  SIZE  THE  SCHEDULE

Wednesday, June 29,

framework development = 2.5 * application development

3 * application development =

framework development + 3 * framework instantiation

framework instantiation = 1 / 6 * application development

프레임워크,

어플리케이션(프레임워크 없는),

프레임워크 적용(framework instantiation)에 대한 추정 :

Wednesday, June 29,

요구사항 분석은 어떻게 하죠?

만들어진 어플리케이션도 없는데..

3.  Two  Pilot  Applica.ons

Wednesday, June 29,

1. 동일한 추상화가 존재하는 기능을 다른 방법으로 사용

2. 프레임워크를 위한 올바른 추상화 필수

3. 충돌하는 요구사항은 프레임워크를 복잡하게 만듦

고려사항

Wednesday, June 29,

프레임워크를 사용할

두 개의 파일럿 어플리케이션을 찾아내라

해결책

Wednesday, June 29,

Framelets  forMul1ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica.ons

SmallFunc1ons

Double  ChangeRequest

Test  Based  OnPilot  Applica.ons

연관된 패턴들

ENGAGE  CUSTOMERS IT’S  A  RELATIONSHIPNOT  A  SALE

Wednesday, June 29,

Wednesday, June 29,

기능들을 어떻게 제공하면 좋을까요?

4.  Small  Func.ons

Wednesday, June 29,

1. 어플리케이션의 잘 정의된 일부분을 커버

2. 적은 수의 기능을 가진 프레임워크가 좀 더 이해하기 쉬움

3. 필요한 만큼의 기능을 집어넣고 싶음

4. 조금씩 다른 방식으로  프레임워크의 기능을 호출

고려사항

Wednesday, June 29,

기능을 잘게 쪼개고, 단순하게 만드는 것을 선호

해결책

- Trade-Off : Configurability VS. Learning curve

Wednesday, June 29,

연관된 패턴들

Framelets  forMul.ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica1ons

SmallFunc.ons

Double  ChangeRequest

Test  Based  OnPilot  Applica1ons

FINE-­‐GRAINED  OBJECTS

Wednesday, June 29,

프레임워크에 대한 확신을 심는 방법은?

5.  User  Involvement

Wednesday, June 29,

1. 어플리케이션 팀 개발자들은 자신의 어플리케이션이 성공적으로 개발되길 원함

2. 직접 개발하는 것보다 프레임워크를 사용했을 때, 개발이 더 쉬워진다는 확신을 줄 필요가 있음

3. 프레임워크는 종종 유연성(flexibility)과 효율성(efficiency)을 어느정도 교환함 (유연성 > 효율성)

4. 프레임워크의 목적은 다른 팀에서 성공적으로 사용하는 것

고려사항

Wednesday, June 29,

프레임워크를 사용하는 팀들을 참여시켜라

해결책

Wednesday, June 29,

1. 워크샵

2. 툴 제공

3. 테스트 제공

4. 최적화 하는 방법 교육

5. 튜터리얼 / 문서

사용자를 참여시키기 위해가능한 일 :

Wednesday, June 29,

Framelets  forMul1ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica.ons

SmallFunc1ons

Double  ChangeRequest

Test  Based  OnPilot  Applica1ons

연관된 패턴들

Build  Trust

Wednesday, June 29,

테스트는 어떻게 진행하죠?

6.  Tests  Based  On  Pilot          Applica.ons

Wednesday, June 29,

1. 품질 보증 관점에서 테스트는 매우 중요

2. 프레임워크를 사용하는 모든 어플리케이션에서 버그가

발생함(quickly multiply)

3. 프레임워크의 테스트는 어렵다(추상화)

4. 어플리케이션의 일부분만 커버하고 있으므로, 혼자서

테스트가 불가능

고려사항

Wednesday, June 29,

파일럿 어플리케이션을 기반으로

회귀 테스트(regression test)를 준비해라

해결책

Wednesday, June 29,

연관된 패턴들

Framelets  forMul1ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica.ons

SmallFunc1ons

Double  ChangeRequest

Test  Based  OnPilot  Applica.ons

Wednesday, June 29,

개발이 끝났는데, 변경 요청이 들어와요

7.  Double  Change  Request

Wednesday, June 29,

1. 다른 팀 사람들은 새로 추가된 기능을 구현하길 원하지

않음

2. 프레임워크는 심플하게 유지가 되어야 함

고려사항

Wednesday, June 29,

두 팀 이상이 필요로 하는 기능만 추가 요청을 수락해라

해결책

- 공유지의 비극(The tragedy of the commons)

wikipedia : 개인들의 이익 추구에 의해 전체의 이익이 파괴되어 공멸을 자초

Wednesday, June 29,

1. Be active변경요청을 받으면 한 팀이상에서 이 기능을 유용하게 사용할 수 있는지 알아봐야 함

2. 프레임워크에 추가가 거부된 요청에 대해서 프레임워크 사용자들이 직접 어플리케이션에 특화된 기능을 추가할수 있도록 허용

3. 변경 요청을 수락할 땐, 프레임워크의 설계에 영향이 없어야 함 → 필요하면 리팩토링 테크닉을 적용

변경을 다루는데 유용한 가이드라인 :

Wednesday, June 29,

연관된 패턴들

Framelets  forMul.ple  Use

Budget  Factor  2.5

UserInvolvement

Two  PilotApplica1ons

SmallFunc1ons

Double  ChangeRequest

Test  Based  OnPilot  Applica1ons

Wednesday, June 29,

기획

요구사항 분석

설계

개발

테스트

유지보수

Framelets for Multiple Use

Budget Factor 2.5

Two Pilot Application

Small Functions

UserInvolvement

Tests Based on Pilot Applications

Double Change Request

Wednesday, June 29,

■동시에 개발하면서 발생하는 문제(리스크)에 대해

사전에 이해

■각 문제(리스크)에 대한 패턴들

■단순히 기술이 문제가 아님

■핵심 :

정리

Simplicity  &  Collabora.on

Wednesday, June 29,

funkcode@gmail.com

hJp://funkcode.1story.com

- Thank you for your attention

Wednesday, June 29,