posted by 방랑군 2012. 1. 10. 03:15

안녕하세요. 코난 김대우 입니다.

이 개발 프레임워크 관련 내용은 http://kingcrap.com 블로그 장현춘님의 허락을 받고 가져온 글이며, 모든 저작권은 장현춘님께 있습니다. 
원본 출처 : http://kingcrap.com/entry/Framework-based-Development-오픈-소스-적용-사례

 

 

 

지난 시간에는 프레임웍 기반 개발이란 어떤 의미가 있으며 이때 사용할 수 있는 범용 개발 프레임웍은 어떤 것들이 시장에 나와 있는지에 대해 살펴보았다.

 

Framework-based Development – 개념 
Framework-based Development – 적용 
Framework-based Development – 종류 
Framework-based Development - 오픈 소스 적용 사례

 

이번 시간에는 주제를 좁혀서 범용 개발 프레임웍 중에서 닷넷 개발자 생태계 내에서 성장하고 발전해가는 오픈 소스 프레임웍의 적용 사례를 살펴보고자 한다. 오픈 소스 프레임웍들을 실제 적용하여 비지니스를 하고 있는 사례들을 살펴봄으로해서 닷넷 개발자 생태계의 건강성을 확인하고 닷넷 오픈 소스 프레임웍의 현재와 미래를 가늠해보는 시간이 되었으면 한다.

 

대부분의 SI 업체들은 SI 프로젝트에서 공통적으로 사용할 표준 개발 프레임웍이라는 것을 가지고 있는데, 대부분 오픈 소스 기반의 범용 프레임웍들을 조합하여 기본적인 기능을 제공하고 이를 기반으로 자사가 가지고 있는 도메인 특화된 노하우를 올리거나 일반 범용 프로임웍이 제공하지 못하는 모니터링이나 툴 최적화 기능 등을 묶어 제공하는 경우가 일반적이다. 아래 그림에서 보듯이 범용 프레임웍들의 조합을 통해 시장에서 입증된 QoS (품질요소)를 제공하고 그 기반위에 고객에게 전달할 가치를 부가적으로 제공하게 된다. 고객에게 전달할 가치가 범용 프레임웍만으로 끝난다면, 이것만 가지고 고객에게 어필(별도의 비용 청구 등)할 수 없을 것이다. 혹은 특정 회사가 개발하여 제공하는 프레임웍이라는 것이 시장의 범용 프레임웍들의 조합만으로도 제공할 수 있는 가치를 전달한다면 고객에게 외면 받을 것은 자명하다.

 

clip_image001_c2817416-14d2-4e0f-94bc-53c5ddef6b13.png

 

국내외를 막론하고 기업이 오픈 소스 기반의 프레임웍을 사용한 경우 일반적으로 그 사실을 외부에 알리는 것을 꺼려하는 경우가 있다. 이런 이유로 Spring.NET의 해외 적용 사례를 보더라도 유럽의 굴지의 온라인 여행사라든가, 어떤 도메인의 유명한 기업 정도만 밝히는 경우가 허다하다. 국내에도 마찬가지여서 외부로 드러나는 적용사례는 극히 드물다. 오늘 소개할 사례를 이전 DevDays 2008과 Open & Interop Day에서 적용 사례 발표를 했던 기업들이다.

 

아래는 이랜드 시스템의 표준 개발 프레임웍에 적용되어 있는 오픈 소스 프레임웍에 대한 내용이며, 황용호 팀장께서 발표하신 슬라이드에서 가져왔다. 이랜드 시스템의 Formular#은 Spring.NET + NHibernate의 조합을 통해 기본 기능을 제공하고 비지니스 특성상 북경 개발 센터와의 원활한 협업을 위해 사용되는 툴들에 대한 add-on 모듈이라든지, 테스팅 자동화와 같은 기능을 제공하고 있다.

 

clip_image002_e70f020d-4f20-4d06-aef8-756326b48961.png

 

예스24에서는 iBATIS.net을 현재 운영 중인 쇼핑몰에 적용한 사례를 최만석 팀장께서 발표하였으며 아래는 그 일부이다.

 

clip_image003_b1d95859-6b74-4086-958a-db9cf23d6b44.png

 

SK C&C에서는 개발 프레임웍인 NEXCORE.NET에 적용된 오픈 소스 프레임웍에 대해 설명을 하셨으며 아래는 이진우 대리께서 발표한 자료에서 발췌했다. NEXCORE.NET은 ASP.NET MVC + Spring.NET + iBATIS.NET 혹은 Entity Framework 등으로 구성되어 있으며 Visual Studio에 통합된 자동화가 인상 깊은 프레임웍이다.

 

clip_image004_bac7af48-1151-41ed-a3ad-9a1cdb315909.png

위에서 언급된 세가지 사례는 발표 자료와 함께 동영상 자료가 DevDays 2008에 게시되어 있으므로 좀 더 상세한 내용을 원하시는 분은 DevDays 2008 싸이트를 참고하시길...

 

그 밖에도 국내 또 다른 SI 업체의 개발 프레임웍에 ASP.NET MVC가 사용되고 있으며, 닷넷 솔루션 파트너사의 일부 솔루션에도 NHibernate가 사용되고 있음을 확인할 수 있었다.

 

마지막으로, 오픈 소스 프레임웍들을 적용하여 사업을 할 경우에 이들에 강제하고 있는 라이선스 정책에 대해서도 관심을 가질 필요가 있다. 오픈 소스는 곧 무료이기에 내 맘대로 가져다 고쳐 쓰면 되지..라는 잘못된 생각에 빠져 마냥 가져다 쓰다가 저작권 위반으로 소송으로 가는 경우가 심심찮게 보고되고 있다. 위에서 언급된 것들 중 가장 많이 사용되는 프레임웍의 라이선스 정책을 보면, Spring.NET과 iBATIS.NET이 Apache License 2.0을 채택하고 있으며, NHibernate가 LGPL을 채택하고 있다. 즉, 이것들 모두 상용 제품 만드는데 사용할 수 있으나 NHibernate가 채택한 LGPL의 경우에는 좀 더 엄격하여, 가져다가 소스를 수정했으면 NHibernate 관련 부분의 소스를 공개하여야 하는 제약이 있다. 물론 이 보다 더 엄격하여 GPL의 경우, 오픈 소스 소프트웨어를 가져다 쓰면, 이와 링크 형태로 엮일 지라도 메모리 상의 영역을 함께 쓰는 모든 소프트웨어의 소스 코드 전부를 공개해야하며 상용 소프트웨어와의 결합을 금지하고 있다. 다만, 이 경우에도 배포만 하지 않고 웹 싸이트에서 서비스 형태로 제공된다면 설령 GPL일 지라도 공개할 의무는 없다.

각종 오픈 소스 소프트웨어의 라이선스 정책에 대한 간단한 설명과 비교자료를 원하시는 분은 예전 정통부와 컴퓨터프로그램보호위원회가 함께 펴 낸 오픈 소스 SW 라이선스 가이드를 참고하시길...

 

아울러 알려지지 않았지만, 시장에서 오픈 소스 프레임웍을 적용하여 프로젝트가 진행되었거나 진행되고 있는 곳이 있다면 가능한 선에서 그 정보를 댓글이나 메일을 통해 공유하여, 오픈 소스를 적용하고자하나 용기가 없어 주저하고 계신 분들께 힘을 실어주시길....

 

[참고링크]

Framework-based Development - 개념

Framework-based Development - 적용

Framework-based Development - 종류

Framework-based Development - 오픈 소스 적용 사례

'PP > Framework' 카테고리의 다른 글

Framework-based Development - 종류  (0) 2012.01.10
Framework-based Development - 적용  (0) 2012.01.10
Framework-based Development - 개념  (0) 2012.01.10
닷넷 관련 개발 프레임워크  (0) 2012.01.10
자료들..  (0) 2012.01.04
posted by 방랑군 2012. 1. 10. 03:14

지난 포스팅에서는 프레임웍 기반 개발이란 무엇인가 살펴보고, 닷넷 개발 생태계 측면에서 오픈 소스 기반의 프레임웍이 제공하는 가치에 대해 알아 보았다. 또한 이후 포스팅에서는 프레임웍 기반 개발의 장점과 적용시 유의사항에 대해 살펴보았다.

Framework-based Development – 개념
Framework-based Development – 적용
Framework-based Development – 종류
Framework-based Development - 오픈 소스 적용 사례

이번 시간에는 프레임웍 기반 개발시 적용할 수 있는 오픈 및 오픈 소스 프레임웍들에는 어떠한 것들이 있는지 살펴보기로 한다.

통상적인 웹 기반 애플리케이션을 개발할 경우 Presentation-Business-Data Tier라는, 일반적으로 얘기하는 3 Tier 아키텍처를 갖게 되는데, 각 Tier에서 사용할 수 있는 범용 개발 프레임웍으로는 아래와 같은 것들이 있다. (필자는 logical은 layer, physical은 tier라는 구분을 좋아하지 않는다. 인접하는 컴포넌트 사이에 수평적으로 서비스를 제공하고 주고 받는 사이를 tier, 한 tier내에서 수직적인 구조를 layer라고 구분하는 것을 좋아한다.)

전통적으로 프리젠테이션 티어 구현 기술로는 ASP.NET이 있었고 이는 널리 알려진 바대로 Page Controller를 구현한 일종의 MVC 프레임웍이다. 프리젠테이션 티어의 가장 큰 관심사는 사용자의 요구를 어떻게 효과적으로 처리할 것인가에 관한 것으로 MVC가 그 핵심이다. 엔터프라이즈 솔루션 아키텍처 디자인 패턴이라는 p&p가 제공하는 가이드에 Page Controller의 최상위 클래스가 복잡한 분기문으로 가득차게 되면 Front Controller를 고민하라고 했듯이, 일반적으로 Front Controller는 Page Controller 보다 좀더 복잡한 애플리케이션 구축에 활용하는 패턴이다. Front Controller 패턴으로 구현한 ASP.NET 기반의 MVC 프레임웍이 바로 ASP.NET MVC 프레임웍이며 현재 베타상태이다. ASP.NET MVC 이전에 시장에는 Castle Project에서 오픈 소스 기반으로 MonoRail을 만들어 배포하고 있었으며, 자바에서 포팅된 Maverick.NET이라는 것도 있었다. 그외 MVC의 View 부분을 치환할 수 있는 다양한 엔진들이 등장하였는데, 그 중에는 자바 template engine인 Velocity의 닷넷 버전인 NVelocity, MonoRail을 위한 View Engine인 Brail, Rails의 view engine으로 널리 쓰이는 Haml의 닷넷 버전인 NHaml 등이 있다. 향후 프리젠테이션 티어의 구현 기술로 가장 주목을 받을 것은 ASP.NET MVC임에는 이론의 여지가 없어 보인다.

비지니스 티어의 가장 큰 관심사는 객체 라이프싸이클 관리이다. 사용자의 요구에 대해서 비지니스 도메인을 구현한 객체들을 얼마나 효과적으로 생성하고 관리하며, 프레임웍과 도메인 구현 엔티티 사이의 의존성을 줄여 향후 유지보수 측면에서 IT 부서의 부담을 줄여 줄 수 있는지가 관심사이며 여기에 핵심 키워드는 Dependency Injection, AOP 라 볼 수 있다. 전통적으로 일반 닷넷 객체 (PONO – Plain Old NET Object)로 원하는 비지니스 기능을 구현했으며 이때는 닷넷 프레임웍이 제공하는 기본적인 객체 생성 및 GC 매커니즘에 의존하고 개발자의 스킬에 의해 메모리 관리 등을 처리하였다. 하지만, 근래에 DI 기능을 기본으로 탑재한 컨테이너들이 수도 없이 출현하였고 가장 대표적인 것들이 위 그림에 나와 있다. Unity는 마이크로소프트 P&P 팀이 제공하는 것으로 Enterprise Library의 객체 라이프싸이클 관리 기능을 제공하는 ObjectBuilder의 Wrapper 클래스들로 구현되어 있으며 현재 Silverlight 지원하는 버전까지 제공되고 있다. 그 밖에 자바 진영의 대표적인 DI 컨테이너인 Spring이 포팅된 Spring.NET이 많은 개발자의 관심을 끌고 있으며 실제로 국내외 닷넷 프로젝트에 적극 활용되고 있다. DI 기본 기능에 프리젠테이션 티어와 데이타 티어의 각종 프레임웍에 대한 편리한 Wrapper 기능을 제공하는 것으로 정평이 나 있다. StructureMap은 Jeremy D. Miller가  만들어 유지보수하고 있으며 닷넷 진영의 가장 오래된 DI 컨테이너이다. Windsor 컨테이너는 Castle Project의 산물이며, NInject는 빠른 DI 기능 제공을 내세우며 근래에 등장한 컨테이너로서 실버라이트 및 .NET Compact Framework 지원 버전까지 제공한다. 많은 비지니스 티어 관련 프레임웍 중에서 전 세계적으로 가장 많이 사용되고 있는 것은 StructureMap으로 알려져 있으나 향후에는 Unity 아니면 Spring.NET이 대세가 되지 않을까하고 조심스럽게 점쳐 본다. 이유는 Enterprise Library의 DI 기능은 위에서 언급된 DI 컨테이너들 거의 모두를 사용하여 제공될 수 있으나 기본적으로는 Unity가 포함되어 있다. 따라서 이전부터 Enterprise Library를 써 오면서 ObjectBuilder에 익숙한 사람들은 많은 고민없이 Unity를 선택할 것으로 판단된다. Unity (Objectbuilder)는 시장에서 어느 정도 검증되었고 피드백도 좋다. Spring.NET은 자바 진영의 de-facto standard DI 컨테이너이며 이의 명성을 바탕으로 닷넷 진영에서도 빠르게 세를 넓히고 있다.

데이터 티어는 기본적으로 ORM (Object-Relational Mapping)을 제공하며 이 티어에는 Object와 RDB 사이의 Impedence Mismatch를 해결하는 다양한 기술들이 제공되고 있다. 전통적으로는 ADO.NET API를 사용하여 DAO 패턴을 적용하여 ORM을 처리하였고 지금도 가장 많이 쓰이고 있는 방식이 아닐까 생각된다. .NET Framework 3.5부터 등장한 LINQ (to SQL, Entity, Object, XML)는 개발자들로 하여금 SQL에 대한 두려움을 어느 정도 상쇄시켜 줄 수 있는 획기적인 DSL 방식의 해결책이다. Entity Framework은 마이크로소프트가 내놓은 진정한 의미의 ORM이라고 할 수 있으며 객체와 데이터베이스 테이블 사이의 다대다 매핑을 지원하며 둘 사이에 의존성을 갖지 않고 독자적으로 변경을 가할 수 있도록 고안된 추상화 레벨을 한 단계 끌어올린 ORM이다. NHibernate와 iBATIS.net은 자바 진영의 ORM 시장을 양분하고 있는 오픈 소스 기반의 대표적인 ORM 툴이며 이것들의 닷넷 버전이다. NHibernate와 iBATIS.net은 현재 국내외 프로젝트에서 주목을 받으며 적용된 사례가 있으며, 각각 고유한 장점이 있기에 적용하고자 하는 필요에 가장 잘 부합하는 것을 선택하는 것이 필요하다. SubSonic은 Rob Coney가 만든 오픈 소스 ORM으로 Rails의 scaffolding 기능까지 제공하고 있다. 또한 SubSonic은 .NET Framework 3.5 SP1에서 제공되는 ASP.NET Dynamic Data에 Scaffolding 기능을 제공하며 .NET Framework에 포함되었다. 하지만 여전히 SubSonic은 오픈 소스로 제공되고 있다. ActiveRecord는 역시 Castle Project의 ORM 관련 산물이다. ORM  툴들은 여기 예시된 것 이외에 상용을 포함하여 훨씬 많은 것들이 시장에 나와 있으며, 이 많은 프레임웍 중에서 LINQ, NHibernate, iBATIS.NET이 가장 주목을 많이 받을 것으로 기대된다. LINQ to NHibernate도 이미 시장에 나와 있듯이 핵심 기능은 NHibernate나 iBATIS.net을 쓰되 개발자 인터페이스 부분은 LINQ가 담당할 가능성도 있다.

참고로, Castle Project를 진행했던 Hamilton Verissimo와 SubSonic을 만든 Rob Conery 모두 마이크로소프트 직원이 되었지만, 현재 이들은 여전히 오픈 소스 프레임웍 개발에 전념하고 있다.

정리하면 다음과 같은 조합이 가장 현실적인 대안이 되지 않을까 한다. 
ASP.NET MVC + { Unity, Spring.NET } + { LINQ, NHibernate, iBATIS.net }

이들 프레임웍들은 서로의 존재를 모르고 시장에 나온 경우가 많다. 따라서 이들 프레임웍들을 효과적으로 연동하기 위한 약간의 수고 필요한데, 대부분의 경우 특히 유명한 프레임웍들은 서로에 대해 연동하는 Wrapper를 자체적으로 제공하거나 MVCContrib과 같이 별도의 프로젝트에서 인접 티어의 프레임웍 연동 기능을 제공하고 있다. 예를 들면, MVCContrib은 ASP.NET MVC와 인접한 다양한 DI 컨테이너들 즉, Unity, Spring.NET, Windsor 등에 대한 연동 모듈을 제공하고 있으며, Spring.NET 자체적으로는 NHibernate에 대한 Wrapper를 제공하고 있다.

시장에서 가장 많이 사용하는 범용 프레임웍들을 조합하여 하나의 예로서 Billy McCafferty가 제시하는 것으로 Sharp Architecture가 있다.

그림에서 보듯이 Billy는 다양한 시도를 진행했다. 처음에 ASP.NET MVC + Spring.NET + NHibernate의 조합을 제시했다가 DI 기능만을 위해 Spring.NET을 쓰는 것이 비효율적이라 생각되어 Spring.NET을 빼고 DI 기능을 손수 PONO 형태로 구현했었다. 이후 NInject라는 가벼운 DI 컨테이너를 다시 도입한 빌드를 선보였고, 근래에는 NInject 대신에 Windsor 컨테이너를 조합한 빌드를 제시하고 있다. 따라서 Sharp Architecture 싸이트에 가보면 다양한 조합의 빌드를 다운받아 테스트해 볼 수 있다.

여기에서 언급된 다양한 프레임웍 및 관련 자료에 대한 링크는 다음과 같다.

마이크로소프트 제공

Patterns & Practices

http://www.microsoft.com/practices

CodePlex

http://www.codeplex.com

ASP.NET MVC

http://www.asp.net/mvc

ASP.NET MVC Contrib

http://www.codeplex.com/MVCContrib

Scott Guthrie Blog

http://weblogs.asp.net/scottgu/

Unity Application Block

http://www.codeplex.com/unity

Enterprise Library

http://www.codeplex.com/entlib

 오픈 소스 프레임워크

Sharp Architecture

http://code.google.com/p/sharp-architecture/

Castle Project (MonoRail, Windsor, ActiveRecord)

http://www.castleproject.org/

Ninject (DI)

http://ninject.org

Spring.NET (DI)

http://springframework.net

StructureMap (DI)

http://structuremap.sourceforge.net/Default.htm

S2Container.NET (DI)

http://s2container.net.seasar.org/en/index.html

autofac (DI)

http://code.google.com/p/autofac/

compactcontainer (DI for compact framework)

http://code.google.com/p/compactcontainer/

LinFu (DI)

http://code.google.com/p/linfu/

NHibernate (ORM)

http://www.hibernate.org/343.html

iBATIS.NET (ORM)

http://ibatis.apache.org/

SubSonic (ORM)

http://subsonicproject.com

'PP > Framework' 카테고리의 다른 글

Framework-based Development - 오픈 소스 적용 사례  (0) 2012.01.10
Framework-based Development - 적용  (0) 2012.01.10
Framework-based Development - 개념  (0) 2012.01.10
닷넷 관련 개발 프레임워크  (0) 2012.01.10
자료들..  (0) 2012.01.04
posted by 방랑군 2012. 1. 10. 03:13

안녕하세요. 코난 김대우 입니다.

이 개발 프레임워크 관련 내용은 http://kingcrap.com 블로그 장현춘님의 허락을 받고 가져온 글이며, 모든 저작권은 장현춘님께 있습니다. 
원본 출처 : http://kingcrap.com/entry/Framework-based-Development-적용


    
지난 포스팅에서는 프레임웍 기반 개발이라는 것이 개발자 영역에서의 자연스런 진화의 산물이며, 시장에 널려 있는 수많은 프레임웍 가운데 자사의 현실에 적합한 프레임웍들의 조합을 통해 프로젝트 전체를 관통하는 뼈대를 만들어 좀 더 나은 애플리케이션을 만드는 기법임을 알 수 있었다. 또한 이때 조합의 대상이 될 즉, candidate 프레임웍들로는 가급적 닷넷 개발 생태계의 산물인 오픈 프레임웍을 선정함이 바람직함을 얘기한 바 있다.

 

Framework-based Development – 개념 
Framework-based Development – 적용 
Framework-based Development – 종류 
Framework-based Development - 오픈 소스 적용 사례

 

이번 시간에는 프레임웍 기반 개발이라는 것이 일반적으로 어떠한 장점이 있는지, 그러한 것을 적용할 때 어떤 방법을 쓰는 것이 좋은지 살펴보도록 하자.

 

개발 프레임웍을 프로젝트에 도입하는 순간 기본적으로 프로젝트의 복잡성은 증가한다. 낯선 프레임웍에 대한 두려움과 새롭게 배워야하는 부담이 개발자들을 짓누르기도 한다. 라이브러리성 프레임웍의 경우 단순히 사용 방식을 익혀야 하는 수고가 더 든다는 정도에 그칠 수 있지만, 개발 프레임웍 즉, 애플리케이션의 컨트롤을 좌우하는 소위 Dependency Injection 등을 제공하는 컨테이너 형태의 프레임웍을 도입하게 되면 문제는 훨씬 복잡한 양상을 띈다. 늘 익숙한 방식의 직접 호출이 아닌 중간에 프레임웍이 위치하여 간접 호출이 일어난다는 것은 기본이고, 라이브러리를 사용할 경우 내가 주체가 되어 예측가능한 시간에 객체를 생성하고 예측가능한 방식으로 객체의 라이프싸이클을 관리할 수 있는 것과는 달리, DI 기능의 프레임웍을 도입할 경우 주객이 전도된다. 이것을 Inversion of Control이라고 부른다. 즉, 일단 DI 컨테이너로 넘어간 컨트롤은 내가 짠 코드와 무관하게 잘 짜여진 프레임웍의 규칙에 의거하여 진행하며 내가 짠 코드는 프레임웍이 정한 룰에 의해 필요시 불리어 객체가 생성되고 관리되며 소멸된다. 흔히 말하는 라이브러리성 프레임웍이 아닌 개발 프레임웍들을 도입하게 되면 일정정도 Inversion of Control이 일어나게 된다. 이 또한 처음 프레임웍을 접할 때 익숙치 않은 경험이 되며 직관적이지 않고 수많은 설정과 장치들을 파악하는 수고들이 번거롭게 느껴지기도 한다. 이렇듯 언뜻 보기에 프로젝트의 복잡성을 증가시키고 참여 인력들에게 낯선 것에 대한 두려움과 학습의 번거로움을 선사하는 프레임웍을 도입하면 어떠한 장점이 있을까 ?

 

clip_image001_98a7a532-42e5-4a33-8d9e-498de0cf28d8.png

오픈 프레임웍의 경우 시장에서 수많은 프로젝트라는 담금질을 거치면서 scalability, managebility, maintainability, performance 등등의 비기능적 요구사항들은 일정수준 이상의 수준에 도달하게 되고, 프레임웍이 제공하는 정형화된 호출 패턴을 준수하게 되어 코드가 일관성 있게 작성 유지되는 장점이 있다. 또한 프로젝트 규모가 커질수록 참여하는 조직이 다양해지고 참여 인력의 기술 수준 또한 다양할 수 밖에 없는데, 이처럼 다양한 수준의 개발자들에게 각종 품질 요소와 관련된 것들을 맡기는 것이 아니라 대부분을 프레임웍에게 맡겨 처리하게 함으로써 일정 수준 이상의 품질을 보장할 수 있게 된다. 반제품화된 프레임웍의 특성상 개발 기간 및 비용을 절감할 수 있으며, 참여 인력의 만족도 또한 증가하게 된다. 언뜻 이해되지 않는 대목일 수도 있으나 처음 프레임웍을 접하고 낯설었지만 개발에 적용하면서 익숙해져 결국 프로젝트가 끝날 무렵에는 이 큰 프로젝트에 시장에서 de-facto standard로 받아들여지는 프레임웍을 적용하여 개발했다는 자신감을 갖게되며, 또한 개인 이력서에도 멋지게 한 줄 올릴 수 있다. 닷넷에서는 아직 낯선 풍경이겠으나 자바 진영의 구인란을 보면 예를 들어, Struts+Spring+Hibernate 경험자 우대 등의 구체적인 프레임웍 경험을 중시하는 구인 광고를 흔히 볼 수 있다.

 

잠시 쉬어가는 코너로 오픈 프레임웍에 대해 거부감이 있는 독자를 위해 예전에 겪었던 경험을 잠시 써 보면... 
대략 4년 전쯤, 대법원이 국내 굴지의 SI 업체가 개발중이었던 시스템에 대해 Architecture Assessment를 한국 썬에 요청한 적이 있었다. 썬은 호주의 아키텍트 두 명과 국내 컨설턴트 두명(그중 하나 필자)을 파견하여 SI 업체가 개발 중인 시스템을 분석하고 참여자들과의 인터뷰를 통해 보고서를 제출하였다. 많은 지적 사항 가운데 프레임웍 관련된 부분만을 언급하면... 
SI 업체가 만들어 유지 보수하며 다년간 많은 프로젝트에서 사용하고 있는 자체 개발 프레임웍을 쓰지 말고 가급적 오픈 소스 기반의 프레임웍을 쓸 것을 추천하였다. 아이러니한 것은 그 당시 썬은 자사 상용 프레임웍인 Sun One Application Framework (“JATO”)를 팔고 있을 때였는데, 썬 직원이 아무런 주저없이 자사 솔루션이 아닌 오픈 소스 프레임웍을 추천하고 돌아간 것이다.....

 

시장에서 널리 쓰이는 프레임웍들을 조합하여 프로젝트의 전체 뼈대를 만들고자 할 경우 어떤 접근 방식을 취하는 것이 좋을까 ? 프로젝트가 시작되면 기본적으로 통합팀을 중심으로 각종 가이드가 만들어지고 참여 인력에 대한 각종 교육이 진행된다. 가령 단순하게는 naming convetion에서 방법론이라든지 신기술이라든지 적용할 프레임웍에 이르기까지... 
낯설지만 시장에서 각광받는 프레임웍들을 조합하여 진행할 때, 참여 인력 모두가 프레임웍에 대해 전문가가 될 필요는 없다. 아니 그럴 수도 없다. 많은 경우 함께 공부해가면서 책에 나와 있는 예제 중심으로 코드를 만드는데, 시일도 오래 걸리거니와 자칫 사소한(?) 것에 발목잡혀 낭패를 볼 수도 있다. 추천하는 것은 가급적 프로젝트 진행하는 팀 내에는 해당 프레임웍에 대한 전문가가 최소 한명이 있어야 한다. 이유는 프레임웍이라는 것이 개발 생태계에서 진화를 하면서 소위 “By Design”이라는 형태의 제약이나 의도된 설계가 있기 마련이다. 참여 인력 모두가 이런 것까지 학습할 시간적 여유가 없으며 누군가는 이러한 것들을 고려하여 개발자들이 사용할 가이드를 만들어 배포하여야 한다. 개발자에게 배포되는 가이드는 많은 것들을 고려하여 작성되었겠지만 실제 개발자에게 전달할 메시지는 아주 단순한 형태이어야 한다. 가령 개발 3단계, 첫째 맡고 있는 Use Case에서 추출한 명사로부터 대문자로 시작하는 클래스를 만들되 통합팀에서 배포한 BaseXXX를 상속받아 작성하고 둘째 반드시 XXX() 메소드를 오버라이드한다. 셋째 컴파일 한 후 특정 위치에 복사한 후 주어진 설정 파일에 등록하면 된다. 사용할 수 있는 소스 코드 탬플릿 양식과 샘플은 형상 관리 도구의 특정 branch에 있으니 참고하라는 식의... 물론 개발자들이 개발 과정에서의 갖게 되는 의문을 풀어주고 이해를 돕기위해 아키텍처 문서나 프레임웍 동작 원리 등을 제공하여 프로젝트를 거치면서 개발자들의 자연스런 성장을 돕는 것도 필요하다.

 

잠시 또 사례를 들면, 프레임웍에 대한 전문 인력이 없이 개발자들이 학습과 개발을 병행하며 프로젝트를 진행할때 발생했던 사례로써 역시 굴지의 국내 또 다른 SI 업체의 자바 솔루션 개발 경우이다.    
그룹사 전체에 특정 LOB 애플리케이션을 공급하는 SI 업체는 새 버전에 이전과 달리 Struts이라는 자바 진영의 그 당시 de-facto standard로 통했던, 현재에도 가장 많이 쓰이는 MVC 프레임웍이기도 한 프레임웍을 도입하기로 하고 참여 인력 내에서 책을 구입하여 개발과 학습을 병행하였는데, 아키텍처 자문을 해주는 과정에서 한가지 단순하지만 중요한 실수를 발견할 수 있었다. Struts이 관리(?)되고 있는 Apache 재단의 홈페이지에도 나와 있는 아주 단순한 원칙, “Action” 클래스는 같은 URI 요청에 대해 singleton으로 동작한다는 사실을 모르고 클래스를 작성하였던 것이다. 하여 개인이 테스트 할때는 별 탈이 없었지만 동시에 요청이 들어오면 thread-safe하지 않은 행동을 보이고 있었던 것.... Struts의 히스토리를 보면 원래는 singleton이 아니었는데 중간에 왜 singleton으로 바꾸게 되었는지 설명해 놓은 대목이 있다. 이런 것을 모든 개발자가 알 필요는 없지만 최소한 한 사람 누군가는 알고 이를 고려한 가이드나 설계가 제시되고 이를 통해 쓸데없이 시간과 정력이 낭비되는 것을 막아야 한다.

 

이런 유사한 사례는 신기술 혹은 새로운 프레임웍을 적용할 경우 흔히 볼 수 있다. 
다음 시간에는 현재 닷넷 개발 생태계내에서 만들어지고 발전되어 가고 있는 오픈 프레임웍들을 살펴보고 어떠한 것들이 시장에서 각광을 받고 있는지 함께 알아보는 시간이 되었으면 한다.

 

clip_image002_f4c091c4-816c-4caf-bda4-f38c530cb7b1.png

또한 참고로 예전 포스팅에서 정리했던 닷넷 개발 프레임웍 리스트를 보는 것도 도움이 될 것으로 생각한다.

 

[참고링크]

Framework-based Development - 개념

Framework-based Development - 적용

Framework-based Development - 종류

Framework-based Development - 오픈 소스 적용 사례

 


'PP > Framework' 카테고리의 다른 글

Framework-based Development - 오픈 소스 적용 사례  (0) 2012.01.10
Framework-based Development - 종류  (0) 2012.01.10
Framework-based Development - 개념  (0) 2012.01.10
닷넷 관련 개발 프레임워크  (0) 2012.01.10
자료들..  (0) 2012.01.04
posted by 방랑군 2012. 1. 10. 03:09

출처 :   http://www.sqler.com/bDevelopmentFramework/375059 

안녕하세요. 코난 김대우 입니다.

이 개발 프레임워크 관련 내용은 http://kingcrap.com 블로그 장현춘님의 허락을 받고 가져온 글이며, 모든 저작권은 장현춘님께 있습니다. 
원본 출처 : http://kingcrap.com/entry/Framework-based-Development 

 

 

프레임웍 기반 개발이라는 것은 말 그대로 엔터프라이즈 애플리케이션을 개발함에 있어서 기존에 만들어진 프레임웍의 조합을 통해 좀 더 빼르고 견고하게 원하는 결과물을 만들어 내는 것을 말하며, 이는 어느 특정 벤더의 개발 방법론도 아니고 개발 영역에서 자연스럽게 발전하여 체득된 개발 방식이다. SI 경험이 많은 대부분의 기업에게는 기업용 애플리케이션 개발에 있어서 경험으로 부터 다듬어져 프레임웍의 형태를 띄는 것들을 가지고 있다. 추상화 혹은 모듈화 정도의 차이가 있을 뿐, 혹은 대외적으로 홍보하는 이름이 있고 없을 뿐 대부분의 개발이 프레임웍 기반으로 진행되고 있다고 봐도 무방하다.

 

향후 몇 번에 걸쳐 프레임웍 기반 개발에 대해 살펴보기로 하자

Framework-based Development – 개념 
Framework-based Development – 적용 
Framework-based Development – 종류 
Framework-based Development - 오픈 소스 적용 사례

 

clip_image001_473d7c64-904a-4ce9-85ee-1d6a9b41885b.png

이처럼 많은 개발사 혹은 개발자들이 경험으로부터 선호하게 되는 프레임웍이라 것은 선조 프로그래머들의 지혜를 재활용하는 많은 방법 중에서 가장 개발자에게 직관적이고 현실적인 재사용 수단이다. 즉, 남들이 만들어 시장에서 다양한 곳에 적용되어 능력을 검증 받은 코드셋을 가져다 내 환경에, 나의 프로젝트에 맞게 약간의 변형을 가하고 설정을 변경하여 재사용할 수 있는 잘 만들어진 클래스 집합인 것이다. 프레임웍을 분류하는 방식은 프레임웍의 정의만큼이나 다양하나 일반적으로 블랙 박스 vs 화이트 박스 혹은 라이브러리성 vs 개발 프레임웍(컨트롤) 혹은 아주 간단하고 자주 쓰이는 오픈 (오픈 소스) vs 상용 프레임웍 등이 있다.

 

프레임웍 기반 개발이라는 것은 상용이든 오픈이든 용도에 맞는 가장 적절한 프레임웍들의 조합을 통해 전체 프로젝트를 관통하여 사용될 뼈대를 완성하고 개발자들로 하여금 비지니스 로직을 구현하여 이 뼈대가 제시하는 Contract에 맞게끔 개발하도록 만드는 정형화된 개발 방식이다. 이렇게 시장에서 검증된 프레임웍들의 조합을 통해 자연스럽게 흔히 얘기하는 비기능적 요구사항 (소위 QoS 요소)들을 달성하고 개발자들은 주어진 도메인에 집중하여 고객에게 전달할 가치 (기능적 요구 사항 포함)를 창출하도록 만드는 것이다. 이를 통해 개발자들의 창의성과 생산성을 기반 프레임웍 개발에 쓰여 낭비하지 않도록 하며 좀 더 나은 고객 가치를 전달하는데 사용케하자는 것이다.

 

여기서 생각해 볼 문제는 과연 어떤 프레임웍들을 조합의 대상으로 삼을 것인가 하는 점이다. 이 점에서 많은 부분 동의하지 못하는 분들도 있을 것 같은데, 필자는 가급적 오픈 (혹은 오픈 소스) 기반의 범용 개발 프레임웍들을 조합하길 권장하는 바이다. 흔히 말하는 범용 개발 프레임웍은 말 그대로 도메인에 특화된 로직을 품고 있지 않아서 대부분의 프로젝트에 쓰일 수 있는 기본 기능을 담고 있는 것들이다.

가령 로깅, 에러 처리등의 라이브러리들을 포함하여 객체 라이프 싸이클 관리, 모니터링 혹은 다른 레이어와의 인터페이스 모듈 등등 모든 프로젝트에서 항상 고민하는 것들이 포함된다. 세상에는 이미 나 혹은 내가 속한 팀, 더 나아가 우리 회사가 만들어 자랑스럽게 내세우는 프레임웍 보다 더 훨씬 더 잘 만들어 공개되어 우리 회사가 10년 아니 우리 회사가 망할때 까지 수행해도 다 못할 만큼의 전세계 수많은 프로젝트에서 다양한 환경에서 검증되어 발전해가는 즉, 닷넷의 개발 생태계 내에서 태어나 성장하는 뛰어난 범용 개발 프레임웍들이 널려 있다. 이제는 이러한 것들을 함께 공유하고 이러한 개발 생태계내에 우리도 일원으로 참여하여 생태계를 키우고 그로 인한 열매를 함께 향유하는 것이 필요하다.

 

오해하지 말 것은 필자가 범용 개발 프레임웍이라고 칭하는 부분이다. 도메인에 특화된 비지니스 프레임웍들을 여전히 상용으로 판매되고 있다. 가령 금융 패키지 혹은 코어 뱅킹, 제조 패키지 등등 도메인에 특화되어 있기에 닷넷에 대한 개발 노하우가 있다고 누구나 만들 수 있는 것도 아니며 도메인 지식이 풍부해야 진입할 수 있는 영역이기에 개발 생태계가 관장하기에는 아직 닷넷 개발 생태계가 성장하기 못한 면이 있다. 하지만 마음만 먹으면 누구나 만들 수 있는 범용 개발 프레임웍은 사정이 다르다. 전세계가 유사한 기능을 하는 비슷비슷한 프레임웍이 나타나는 이유는 간단하다. “난 쟤들 거 이런 이런 점이 맘에 안들어...” 이거다. 이렇게 만들어진 것이 대중의 사랑을 받게 되면 개발 프레임웍에 있어 de-facto standard로 자리잡아 칭송을 받게 되는 것이다.

 

고객이 입장에서 보면 오픈을 써야하는 이유는 더 극명하다. 벤더 종속적인 프레임웍을 도입하였을 경우 기반이 되는 .NET의 발전에 맞추어 유지보수해야 하는 문제며, 소스 코드를 포함한 소유권 문제 등도 있고, 프레임웍 개발사가 증명할 수 있는 각종 QoS 수준과 전세계 닷넷 개발 생태계가 증명할 수 있는 수준과의 신뢰성 등 고객은 이미 오픈 혹은 오픈 소스에 대해 많은 것을 알고 있다. 개발자들의 자유로운 접근과 사용, 그리고 그 과정에서 주고 받는 Q&A 및 피드백을 통해 오픈 프레임웍은 자연스럽게 생태계속에 편입되어 발전하게 되는 것이다.

 

다음 시간에는 현재 우리가 사용할 수 있는 프레임웍들에는 어떤 것이 있고 어떤 점을 고려하여 선정하여야 하는지 더 나아가 적용할 때 고민해야 할 부분등에 대해 함께 알아보도록 하자.

 

clip_image002_4b15f2f2-fd45-40a1-b9f7-146ed7230ce0.png

 

 

[참고링크] 

Framework-based Development - 개념

Framework-based Development - 적용

Framework-based Development - 종류

Framework-based Development - 오픈 소스 적용 사례

  

'PP > Framework' 카테고리의 다른 글

Framework-based Development - 종류  (0) 2012.01.10
Framework-based Development - 적용  (0) 2012.01.10
닷넷 관련 개발 프레임워크  (0) 2012.01.10
자료들..  (0) 2012.01.04
프레임워크를 이해하기 위한 패턴 언어  (0) 2012.01.04
posted by 방랑군 2012. 1. 10. 03:09

출처 :  http://www.sqler.com/bDevelopmentFramework/375007 

안녕하세요. 코난 김대우 입니다.

이 개발 프레임워크 관련 내용은 http://kingcrap.com 블로그 장현춘님의 허락을 받고 가져온 글이며, 모든 저작권은 장현춘님께 있습니다.
원본 출처 : http://kingcrap.com/entry/닷넷-관련-개발-프레임웍-Beta

일부 내용에 변경이 있는 부분은 명시 후 수정합니다.

 

 

 

닷넷 프로젝트에서 사용할 수 있는 프레임웍을 한눈에 볼 수 있도록 정리해보자 
프레임웍을 구분하는 방법은 여러가지이나 간단하게 티어별로 구분하도록 한다. 

프리젠테이션 티어 (웹) 
1. ASP.NET MVC - ASP.NET 기반의 MVC 프레임웍. 마이크로소프트 제공 
2. MonoRail - 오픈 소스 Castle 프로젝트에서 만든 Rail와 유사한 MVC 웹 프로임웍 
3. Maverick.NET - 자바 Maverick의 닷넷 버전으로 오픈 소스 MVC 웹 프레임웍, 업데이트 안됨 
4. DotNetNuke - 포털 프레임웍에 가까움. 오픈 소스 

비지니스 티어 (DI Container) 
1. Spring.NET - 오픈 소스. 자바 Spring의 닷넷 버전. 대표적인 DI Container. 
2. ObjectBuilder - Enterprise Library(EntLib)에 들어 있으며, EntLib, Composite UI Application Block 등에 사용된 DI Container 
3. Unity - Enterprise Library 4.0 버전에 사용될 DI Container로 ObjectBuilder 후속작. EL과 별개로 사용될 수 있도록 별도 프로젝트로 진행중이며 Codeplex에 현재 2008년 2월 CTP 공개. 
4. Windsor Container - 오픈 소스 Castle 프로젝트 일환 
5. StructureMap - 닷넷에서 가장 오래된 DI Container. Jeremy D. Miller가 만들고 유지보수하고 있는 오픈 소스 프레임웍
6. NInject - "Lightning-fast dependency injection for .net"을 표방한 오픈 소스 DI Container. 닷넷 프레임웍 3.5 및 Compact Framework 3.5 지원, Silverlight 지원 등이 특징

데이터 티어 
1. ADO.NET 
2. LINQ to SQL - .NET Framework 3.5 이상의 기본 기능(2011년 5월 현재 4.0). 엔티티와 테이블의 1:1 매핑. VS2008 이상 툴 지원 
3. ADO.NET Entity Framework (LINQ to Entity) 
4. NHibernate - 자바 Hibernate의 닷넷 버전. 오픈 소스 
5. iBatis.NET - 자바 iBatis의 닷넷 버전. 오픈 소스 
6. Active Record - 오픈 소스 Castle 프로젝트의 일환. Active Record 패턴을 구현. NHibernate 기반이나 Configuration을 XML이 아닌 Attribute을 이용 
7. LLBLGen Pro - 상용. 
8. WilsonORMapper - 상용. 
9. LightSpeed - 상용. 
10. Codus - 상용. 
11. Sooda - 폴란드에서 만든 오픈 소스 ORM 으로 폴란드에서는 구직시 도움되는 기술. 
12. SubSonic - 오픈 소스 ORM. ASP.NET 3.5 Extension에 포함된 ASP.NET Dynamic Data 기능 구현에 사용됨.
13. NConstruct - 상용 / 무료, NHibernate 용 코드 자동 생성(HBM, Entity 등), VS용 project 파일 생성 등

All-in-one
1. DotNetNuke - 복잡한 웹 싸이트 구축, CMS에 까깝다고 할 수 있음
2. Oxite - ASP.NET MVC를 사용, 블로그 엔진, Mix Online 싸이트 운영

기타 범용 프레임웍 (혹은 라이브러리) 
1. Enterprise Library - MS patterns and practices(PnP) 팀이 Codeplex를 통해 제공. 캐싱, 로깅, 암호화 등등 
2. NVelocity - 템플릿 엔진. 진전이 없어 Castle 프로젝트에서 별도 진행 
3. NUnit - 단위 테스트 
4. NAnt - 빌드 
5. log4net - 로깅 

6. CruiseControl.NET - 통합 빌드, ThoughtWorks에서 개발한 오픈 소스 

'PP > Framework' 카테고리의 다른 글

Framework-based Development - 적용  (0) 2012.01.10
Framework-based Development - 개념  (0) 2012.01.10
자료들..  (0) 2012.01.04
프레임워크를 이해하기 위한 패턴 언어  (0) 2012.01.04
프레임워크 리팩토링 정리  (0) 2012.01.04
posted by 방랑군 2012. 1. 4. 13:38
posted by 방랑군 2012. 1. 4. 13:37

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


캐즘(chasm)

  • 캐즘 : 활발히 활용되기전의 과도기 시점, 정체 또는 후퇴되는것처럼 느껴지는 진행 단절 현상
  • 프레임워크 학습시 캐즘
    • 프레임워크는 도메인 문제 해결을 위한 코드구조, 디자인이 포함
    • 일반적 App 개발과는 다르게 도메인 문제를 프레임워크 구조에서 해결해야함

프레임워크 구현시 주의사항

  • Hot spots와 Frozen spots를 구분할것
  • 공통적인 부분은 프레임워크 내부에서
  • 가변적인 부분은 App마다 달라지므로, 초기화 부분의 파라미터 등을통해 기능 접근을 할 수 있도록 구현
  • 가변적인 부분을 프레임워크 내에 모두 포함할 수 없다면, 가상함수의 특징인 훅 메스드 형태로 제공하여 커스트마이징 할 수 있도록 구현

라이브러리 vs 프레임워크

  • 라이브러리 : App에서 구현하기 위해 라이브러리 호출
  • 프레임워크 : 프레임워크에서 의도하는 구조로 App이 흐름

프레임워크 이해를 위한 패턴언어

  • 1) 프레임워크 선택하기
  • 2) 프레임워크를 이용한 프로젝트 레퍼런스 만들기
  • 3) 프레임워크 발전시키기
  • 4) 프레임워크 학습
  • 5) 사용 경험의 보전 방법
  • 6) 애플리케이션 도메인의 이해
  • 7) 프레임워크 아키텍처의 이해
  • 8) 프레임워크 내부 디자인의 이해
  • 9) 프레임워크 코드의 이해

1) 프레임워크 선택하기

  • 도메인 분석작업
  • 프레임워크 기능 분석작업
  • App 개발기간과 배우는 비용도 고려햐야함.
  • 화이트박스/블랙박스/그레이박스 프레임워크
    • 화이트박스 : hot spots의 커스트마이징을 위해 상속과 동적바인딩을 사용, 프레임워크 개발은 쉽지만 App 개발자가 프레임워크 내부를 잘 알아야
    • 블랙박스 : hot spots의 커스트마이징을 위해 인터페이스를 사용. App 개발자는 인터페이스를 구현하고 프레임워크에 던져줌. 프레임워크 개발시 인터페이스 미리 정해둬야함
    • 그레이박스 : 일반적인 방법. 화이트+블랙 적절히..
  • 예제) 루비 온 레일즈 : App 구현기간이 짧아야 할 경우 미리 충분히 갖춰진 프레임워크

사용자 삽입 이미지


2) 프레임워크를 이용한 프로젝트 레퍼런스 만들기

  • 프레임워크 : 도메인에 특화된 문제를 해결하는 뼈대
  • 적당한 예제단위로 레퍼런스를 구축한다면 효율성이 높음

3) 프레임워크 발전시키기

  • 프레임워크 개발자는
    • 도메인 적용되고 나타나는 문제를 해결하여 다시 프레임워크에 반영해야
    • 변경되는 HW, OS에 맞게 발전시켜야
    • 소프트웨어 전문가 겸 도메인 전문가여야 함.

4) 프레임워크 학습

  • App는 시작지점이 존재하지만, 프레임워크는 시작점이 없다.
  • 프레임워크 분석 방법
    • Top-down(하향식) : 추상화 레벨에서 분석 시작 (큰 그림 잡고 -> 목적을 파악하고 -> 구현부에서 파악)
    • Bottom-up(상향식) : 세부구현에서 분석 시작
    • 대체로 하향식이 분석이 편함 (반드시는 아님)

5) 사용 경험의 보전 방법

  • 프레임워크로 App에 적용 반복하다 보면, 사용법/주의사항/노하우 등이 쌓임. 이런것들은 보존해야함.
  • 프레임워크 사용경험을 문서화시키고, 실전코드들을 레퍼런스나 케이스로 정리할것

6) 애플리케이션 도메인의 이해

  • 프레임워크가 App에서 구현할 문제를 해결할 수 있는 범위 파악하는 것이 중요

7) 프레임워크 아키텍처의 이해

  • 프레임워크 기반 App는 프레임워크 의도에 따라 App 구조가 바뀐다. --> 프레임워크는 App에 직접적 영향 미침
  • 프레임워크 구조를 파악하면 구현체 재사용이 용이하고, 컴포넌트 관계를 이해하기 좋다 --> 빠르고 정확한 프레임워크 사용 가능
  • 프레임워크 아키텍처를 구성하는 패턴들을 도식화 --> 구조 파악에 도움이 됨
  • 문서화시 필요하면 리버스 엔지니어링 툴의 도움을 받을것

8) 프레임워크 내부 디자인의 이해

  • App이 도메인 문제를 유연하게 풀어나가기 위해서는 프레임워크 내부 디자인이 확장성 있고 유연한지에 달렸음.
  • 프레임워크가 복잡하다고 느끼는 것은 내부 디자인이 복잡해서임. 프레임워크 이해를 잘하면 사용도 잘할수 있음.
  • 내부 디자인 살펴볼때는
    • 디자인 패턴 선행학습 필요
    • 화이트박스인지 블랙박스인지 파악할것
    • Hot spots, Frozen spots 파악할것
    • 구성하는 컴포넌트 관계를 파악할것

9) 프레임워크 코드의 이해

  • 프레임워크 개발자는 경험이 많고 높은 프로그래밍 실력이 대부분
  • 프레임워크 개발자의 코드는 후배들의 본보기가 되므로 잘 짜라


posted by 방랑군 2012. 1. 4. 13:36

본 내용은 월간 마소 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(데이터 종속성 그래프)
 
posted by 방랑군 2012. 1. 4. 13:36

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


프레임워크

  • 한번 만들면 쉽게 바꿀 수 없이 모든 사람들이 사용
  • semi-complete application : 반쯤 완성된 애플리케이션

프레임워크 vs 라이브러리

  • 라이브러리 : 내부 control flow를 가지지 않은 소스들의 단순 집합
  • 프레임워크 : 컴포넌트간의 관계를 고려한 오버라이딩 가능한 control flow 제공

5가지 속성

  • 1. 조직 (Organization)
  • 2. 계획 (Planning)
  • 3. 아키텍처 (Architecture)
  • 4. 설계 (Design)
  • 5. 개발 (Development)
  • 6. 그밖에 : 산출물 가독성, 문서화, 네이밍룰, 프레임워크 매뉴얼

1. 조직

  • 조직을 먼저 구성하지 마라
    • 1) 비지니스 파악 : 도메인 전문가 or 구성원 전체가 모여서
    • 2) 관련된 프로세스 정제
    • 3) 프로세스에 맞게 IT 조직 구성
  • 방향 결정 : 고객 중심? 기술 중심?
    • 고객중심 : 시나리오에 초점
    • 기술중심 : 오래동안 사용가능하도록 아키텍처에 초점

2. 계획 (2가지 프레임워크 개발방식)

  • 땅콩버터 : 특징을 중심으로 골고루 구현하는 Bottom-UP 방식. 기능중심의 팀이 필요
  • 마천루 : 시나리오 중심으로 구현, 특정모듈에만 집중적인 개발이 됨

3. 아키텍처

  • 아키텍처 타입, API, 실행, 의존성을 고려해 Layering을 구축
  • 의존성 분석을 위해 xDepend 같은 툴을 사용

4. 설계

  • 메인 시나리오에 부합되는 코드 샘플 만들기 -> 객체 모델 정의
  • 프레임워크 설계 (디자인 스튜디오 등의 툴을 사용)
  • 큰 조직일 경우 일치성이 중요
  • ATAM과 같은 아키텍처 평가툴 이용해 품질 강화

5. 개발

  • 조직이 작다면 프레임워크 개발도 간단해야 함
  • 80/20룰을 적용해 효율성 고려
posted by 방랑군 2012. 1. 4. 13:35

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


생산성의 향상

  • 프로그램에서의 생산성 향상 방안 : 코드의 재사용
    • Function, Procedure 개념 지원 언어의 출현, 이후 객체지향 언어가 출현
    • 컴포넌트 사용 : 재사용을 높이고 검증된 코드를 사용하게됨 --> SW 품질이 높아지고 개발비용/유지비용이 낮아짐
  • 컴포넌트 재활용과 디자인 재활용
    • 객체지향 프로그램에서는..
      • 클래스 : 기능을 모듈화 & 추상화 지원
      • 추상클래스 : 객체간 프로토콜 일치 가능
      • 동적바인딩 : 프로시저 호출 지연 바인딩(Late-binding)
      • 클래스 상속 : 서브클래스에서 기능을 추가/보완
      • 다형성 : 객체의 기능을 교체
  • 랄프존슨이 말한 프레임워크
    • 추상클래스들의 집합과 상호 협조하는 클래스들의 인스턴스 동작방법으로 이루어진 재사용 가능한 디자인
  • 예제) 윈도우 애플리케이션용 프레임워크
    • 화면의 로직처리
    • 윈도우 그리는 컴포넌트
    • 통신 컴포넌트
    • 내부 정보 처리하는 도큐먼트 컴포넌트
    • 등등등..

라이브러리 대신 프레임워크 사용하는 이유

  • 라이브러리
    • 정의 : 해결하고자 하는 도메인 문제와 상관없이 재사용할 컴포넌트의 집합
    • 사용시 : 제공하는 메소드의 기능을 정확히 알고 있어야 함 (목적, 인자, 결과값)
  • 프레임워크
    • 정의 : 해결하고자 하는 도메인 문제에 특화된 인스턴스들이 함께 동작되는 컴포넌트 집합과 디자인
    • 사용시 : 필요한 지점에서 적절히 삽입하고 쉬운 사용, 세부적인 부분은 몰라도 됨
    • 프레임워크 = 반제품(Semi-Complete Application) : 적은 비용으로 App 만들기 위해 절반정도는 구현되어 있는 수준
  • 예제 : 신뢰성 있는 메시징, 트랜젝션 개발시
    • 라이브러리 : 각 라이브러리별 메소드를 알고, 개발해야 됨
    • 프레임워크 : WCF 쓰면 내부의 세부사항은 몰라도 기능 흐름만 파악하면 되며, 코드가 주어듬

좋은 프레임워크와 효과적인 사용법

  • 일반적인 프레임워크 사용방법
    • 1) 클래스의 서브클래스 생성
    • 2) 생성된 객체의 내부환경을 설정
    • 3) 프레임워크가 제시하는 표준 방법으로 App에 적용
  • 좋은 프레임워크의 요소
    • 효율성(Effectiveness) : 개발자에게 효율적이여야, 개발 속도를 빠르게 해야, 개발비용을 줄여야 함
    • 확장성(Extensibility) : 특정 도메인의 App 개발시 개발항목을 포괄하는 확장성을 가져야 함 (App이 삼각형 윈도우를 지원해야 한다는 식의 무리한 확장성은 포함 안해도 됨)
    • 적용규모(Coverage) : 구현사항을 어느 범위까지 적용할지?
    • 평이성(Simplicity)와 이해도(Understandability) : 교육이 쉬워야, 너무 복잡하거나 추상적이면 안됨
    • 통합성(Framework Intergration) : 다른 프레임워크나 라이브러리와 상호소통이 잘되면 좋다
    • 품질(Qualities) : 능률성,적용성,표준성.. 필수항목은 아닌듯

프레임워크 도입시 고려할 점

  • 필요이상으로 복잡해지고 코드나 객체가 커지면 안됨
  • 랄프존슨 : "원할하게 일할 수 있을 만큼 이 프레임워크가 쉽게 느껴지는가?"
  • 프레임워크 도입시 더 비효율적이 될거 같으면 때려치워라! (개발비용, 교육, 문서화 작업 등...)

프레임워크 만들기

  • 추상 개념을 먼저 생각하기는 어렵다.. 먼저 구현해 보자
  • 먼저 구현 -> 문제 해결 방법을 작은 집합으로 나눔 -> 구현체 중 컨텍스트를 인자화해 변경할 수 있도록 수정
  • 도메인 전문가가 만들때 : Up-Front 디자인 방식
  • 코딩 전문가가 만들때
    • 반복적인 구현을 통해 코드를 개선해 나감
    • 반복 개발시 Hot Spots과 Frozen Spots를 잘 구분해서 다음번 개발시 잘 구성하자
    • App이 다 만들어지면 이전 프레임워크와 비교하여 재사용성 부분을 반영
  • 구현클래스에서 추상클래스 유추하기
    • 구현클래스에서 일반적인 부분들을 뽑아서 추상클래스 만들기
    • 1) 공통 기능의 구현클래스 준비
    • 2) 구현 클래스의 공통 기능을 하나의 메소드로 옮긴다.
    • 3) 옮겨진 구현 클래스의 멤버로 있는 메소드의 이름을 동일하게
    • 4) 이름을 변경한 메소드의 인자, 리턴값을 동일하게 일반화
    • 5) 해당 메소드를 분리하거나 병합할 필요시 리팩토링
    • 6) 같은 메소드명이지만 다른 구현이라면 추상클래스에서 메소드명을 반영
    • 7) 구현 클래스의 메소드 내용이 같다면 수퍼클래스로 구현을 옮김
  • 상향식 설계
    • 하향식 : 구현 클래스 먼저 만들고 이를 바탕으로 추상클래스 만듬
    • 상향식보다 쉽다.
    • R = I + J = AX + AY = A(X + Y) --> 여기서 A는 공통부분
    • 필요한 설계 원칙
      • 의존 관계 역전 원칙(The Dependency Inversion Principle)
      • 인터페이스 분리 원칙(The Interface Segregation Principle)
      • 리스코프 치환 원칙(The Liskov Substitution Principle)
      • 단일 책임 원칙(The Single Responsibility Principle)
      • 개방 폐쇄 원칙(The Open-Closed Principle)

프레임워크 개발의 9 단계

  • http://st-www.cs.illinois.edu/users/droberts/evolve.html
  • 시간축에 따라 동시에 진행할 수도 있다.
  • 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 : 언어도구 패턴
사용자 삽입 이미지


참고사이트


posted by 방랑군 2012. 1. 4. 13:35

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


은닉과 캡슐화

  • 은닉 ≠ 캡슐화
  • 은닉
    • 접근 지정자로 구현
    • 접근 지정자로 멤버를 숨기고, 멤버를 제어할 수 있는 인터페이스 노출하는 것
    • 객체를 인터페이스를 통해 노출시켜 동적 바인딩할 수 있게함
  • 캡슐화
    • class로 구현
    • 멤버와 데이터를 class라는 키워드로 묶는 것
    • 그냥 함수의 리턴값을 사용하게 되면 절차적 프로그램이 됨
    • class로 묶으면 데이터의 흐름을 메소드와 데이터로 묶어서 결합도를 낮춰줌

상속과 구성

  • 구현상속 : 부모것을 자식이 사용, 부모클래스를 잘 알고 상속받아야 함
  • 인터페이스 상속 : 인터페이스만 재사용

프레임워크의 구축

  • 조건
    • 확장이 가능해야 함.
    • 기능을 쉽게 대체시켜야 함.
    • 도메인 문제에 대해 추상적이고 필수 구현이 되어 있어야 함.
    • 간단하고 문서화가 잘 되어 있어야 하며 이해하기 쉬워야 함
    • 프레임워크의 작은 부분 전체를 재사용할 수 있어야 함.
  • 커뮤니케이션 중요
    • 프레임워크 개발자에게는 App 개발자가 고객임
    • 도메인 전문가나 해당 App 개발자의 조언 필요
  • 하향식 디자인
    • 도메인 분석 -> 추상화 -> 프레임워크 구현 -> App 구현하여 테스트
  • 상향식 디자인
    • App 구현 -> 계속 구현 -> 반복되거나 비슷한놈은 재사용되므로 프레임워크에 포함
    • 일반적인 개발 방법임

프레임워크의 발전

  • 프레임워크 = 반제품(Semi-Complete Application) : 적은 비용으로 App 만들기 위해 절반정도는 구현되어 있는 수준
  • 랄프존슨의 9가지 패턴을 사용하여 발전할것

사용자 삽입 이미지


1) 세가지 애플리케이션 패턴

  • 재사용 부분을 파악하는 일이 중요함 -> 미리 예측이 힘듬
  • 3개 이상의 App을 만들어서 재사용 모듈 파악
  • App과 프레임워크 동시 개발시
    • 일정 Fix시 : 다수의 팀이 나눠서 개발 -> 프레임워크 개발팀 산출물 기다리기 힘드므로 파일럿 프로젝트로 간략하게 살펴봐라
    • 인원 Fix시 : 단일팀이 개발
  • 다수의 App으로 코드를 일반화 할 수록 프레임워크 기능과 품질이 좋아짐. 초기버전이라 불안정하다는 우려도 없앨수 있음 (Pilot Application Pattern)

2) 화이트박스 패턴

  • 두번째 애플리케이션 개발시 시작하면 됨.
  • 첫번째 애플리케이션 만든 후 초기버전 프레임워크 기능을 확장시 "상속"을 사용하라
  • 상속 : 코드를 쉽게 재사용할 수 있게 해줌, 인터페이스를 사용하라. 없으면 구현클래스에서 유추하여 만들어라. 상속을 이용하여 기능 확장 구현을 반복한다.

3) 컴포넌트 라이브러리 패턴

  • 도메인에 특화된 문제의 해결방법이 프레임워크에 들어가지 않아야 함.
  • 재사용하지 않는 클래스는 프레임워크에 넣지않고, 애플리케이션의 구현클래스에 위치
  • 프레임워크의 재사용않는 클래스를 계속 리펙토링

4) 핫 스팟 패턴

  • 화이트박스 패턴으로 계속 추가하고, 컴포넌트 라이브러리 패턴으로 계속 제거 --> 기존 클래스와 추가될 클래스의 관계를 정의하면서 확장하여 중복을 막자
  • 핫 스팟 : 코드 변화가 활발한 부분
  • 화이트박스 패턴으로 자꾸 확장되는 놈은 데코레이션 패턴같은 놈을 사용하여 구현 가능.

5) 플러그러블 오브젝트 패턴

  • 구현클래스의 소소한 변경이 많으면 --> 프레임워크 커짐 --> 복잡도 증가 --> 프레임워크 사용 어려움
  • 객체 생성시 다양성 구분에 필요한 인자 사용 --> 객체가 인자에 따라 행동하게 개발
  • 인자 : 상수, 심볼, 클래스 래퍼런스, 인스턴스 변수, 함수 포인터, 함수자.....

6) 파인-그레인드 패턴

  • 간단한 API가 복잡한 API보다 사용하기 쉽다 --> Small Objects Pattern
  • 객체는 커질수록 --> 중복기능 많아짐, 중복코드 많아짐, 도메인 문제를 다룰려고 하는 경향이 있음. --> 리팩토링 대상임

7) 블랙박스 패턴

  • 애플리케이션은 요구변경에 유연해야 함 --> 클래스의 확장에는 열려있고, 수정에는 닫혀 있어야 함. --> 상속보다는 구성을 사용

8) 비주얼 빌더 패턴과 언어 도구 패턴

  • 비주얼 빌더 패턴 : 프레임워크 정리한 문서, 프레임워크 사용을 도와주는 툴 제공할것
  • 언어 도구 패턴 : 애플리케이션 점검 툴, 디버깅 툴 제공할 것 
posted by 방랑군 2012. 1. 4. 13:34

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


'PP > Framework' 카테고리의 다른 글

프레임워크 개발의 이해와 시작  (0) 2012.01.04
프레임워크 구축과 발전  (0) 2012.01.04
프레임워크 엔지니어링  (0) 2012.01.04
C#용 Open Source 조사  (0) 2012.01.04
프레임워크 개발 정리  (0) 2012.01.04
posted by 방랑군 2012. 1. 4. 13:34
본 내용은 월간 마소 2009년 02/03월호에 실린 내용을 정리한 것입니다.
불펌을 금지하며, 문제시 삭제하겠습니다.
원문 출처는 아래와 같습니다.



더글라스 슈미츠 (POSA2 저자)의 프레임워크 정의

  • 프레임워크는 도메인 기반의 지식으로 구성된 객체 구조와 기능을 가지고 있는 "반쯤 완성된 애플리케이션"이다.

고려할 6가지 사항

  • 조직 (가장 강력한 설계 툴)
  • 계획 (프레임워크를 올바르게 구축하기 위한 계획)
  • 아키텍처 (오랫동안 사용할 수 있는 품질 좋은 프레임워크를 만들기 위한 고려사항들)
  • 설계 (품질을 보장하기 위해 고려할 사항들)
  • 개발 (프레임워크를 만들기 위해 팀플레이 시 고려해야 되는 사항들)
  • 그 외에 고려해야 되는 것들 (가독성, 문서화)

조직

  • 콘웨이의 법칙
    • 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 4단계의 컴파일러를 얻을것이다.
    • 팀 구조 ==> 소프트웨어 구조
    • 따라서 팀 구성전에 도메인 전문가 or 구성원 전체가 모여 프로세스 정제후에, 프로세스에 맞춰서 팀을 구성
  • 조직 구조에 따른 설계방법
    • 프레임워크 개발팀은 작고, 사용팀은 많다면 ==> 모든 요구사항 수렴 불가 ==> 80/20룰에 의거, 많이 쓰는 부분에 집중
    • 프레임워크 개발팀이 크다면 ==> 요구사항을 많이 들어줌 ==> 모듈간의 일관성 유지에 초점 ==> 프로토타입을 많이 만들고 피드백 받아야
  • 조직의 문화를 고려
  • 고객 중심의 회사 : End-2-End 시나리오 추출후, 시나리오 잘 지원하는 프레임워크 설계해야
  • 기술 중심의 회사 : 기술 변화를 쉽게 수용하도록 프레임워크 설계해야
  • 조직의 의사결정 매커니즘 고려
  • 개별적 맨 파워 중시하는 회사 : 빠른 의사 결정을 지원하도록 설계
  • 계층적인 조직구조의 회사 : 이질적인 의사 표현방법을 통합하고 상호 운용하는데 초점

계획

  • 땅콩버터
    • Bottom-Up
    • Feature들이 중심되어 S/W 만듬. 땅콩버터처럼 Feature들이 점진적으로 골고루 퍼지고 진화함
    • 새로운 소프트웨어 만들때, 하위 레벨의 프레임워크 만들때, 저수준의 라이브러리 개발시
    • 단점 : 고객요구 많고, 시나리오가 자주 새로워지면.. Feature별로 구성된 조직간 협업을 해야하고.. 시끄러워짐..
  • 마천루
    • 시나리오가 마천루처럼 높게 솟아 SW 기능 구현의 기준이 됨. 기준이 있다는 건 좋은거임..
    • Top-Down
    • 다양한 고객이 사용하는 상위레벨 애플리케이션 개발시
    • 단점 : 시나리오 기준이라 일괄적인 구조로 설계가 힘듬. 시나리오 수정시 속수무책.
  • 마일스톤 = 땅콩버터 + 마천루
    • 인프라 구축 초기에는 땅콩버터, 인프라 구축된 후 땅콩버터 유지하되 점진적으로 마천루 혼합
    • MS의 예 : 10개의 기능이 필요하면 2개 구현 --> 배포후 피드백 받음 --> 기존2개 수정, 새로운 2개 추가.....

아키텍처

  • 프레임워크 구축하여 여러팀이 사용중에.. 아키텍쳐를 변경하는것은 매우 힘듬. 첨부터 잘 만들어야 함.
  • 타입들
    • Primitive : 기본 데이타 타입 (Int32, String...), 모든 데이타의 가장 하단부에 위치하므로 변경에 따른 영향이 큼
    • Library (Component) : 풍부한 행위와 정책을 가진 타입(EventLog, Debug...). 쉽게 확장 가능. Component 구축시 매개변수로 Library를 받지 마라 의존성 생긴다.
    • Abstraction (Interface) : 추상클래스로 프레임워크의 확장성과 유연성을 제공. 프레임워크가 반완성이라는 말은 Template Method 패턴과 같은 Abstraction을 많이 사용한다는 얘기.
  • 의존성 종류
    • API Depenency (Surface Depenency) : 컴포넌트 A와 B간에 파라미터나 리턴값 등으로 사용시 의존성
    • Implementation Depenency : 내부적으로 다른 컴포넌트 사용시. 다른 컴포넌트가 없으면 돌지도 않음.
    • Circular Depenency : A가 B를 의존하고, B가 A를 의존. 가장 나쁜 경우임.
  • 의존성과 악연
    • 컴포넌트는 재사용의 단위보다는 "같이 배포되고 같이 진화하는 타입들의 집합의 단위".
    • 닷넷&자바 : 초기에 배포한 프레임워크에 라이브러리 기능 추가하지 않고, 베이스 클래스 라이브러리로 명명, 추후 별도의 라이브러리 추가
    • 의존성을 줄이려면 "계층화" 사용할것 ==> 연관된 컴포넌트는 하나의 레이어로 묶음 ==> 다른 레이어의 변화의 충격 완화됨
    • 참고 - Dependency를 관리하는 방법 :http://arload.wordpress.com/2008/12/07/ ··· gment%2F
  • Circular Depenency는 꼭 피하자
    • 상위레이어에서 하위레이어를 호출할 수는 있어도..
    • 하위 레이어가 상위레이어를 호출하면 안됨!!!! ==> 직/간접적으로 Circular Depenency 만들어진다.
    • ex) GUI --> 통신모듈 --> 오류시 try catch 문에서 MessageBox 표시 --> GUI 의존성..
    • 위의 경우 MessageBox로 보내지 말고.. Message Manager를 구성해서 의존성을 끊어라. 또는 Listener를 사용하여 IoC 구성하라
  • Dependency 깨는 IoC
  • Dependency 확인 도구 xDepend
    • JDepend의 닷넷버전. 상용 (초기버전은 무료)
    • 종속성을 그래프/다이어그램으로 보여줌. Circular Dependency 찾는 기능
    • CQL(Code Query Language)
    • http://www.ndepend.com 
  • 추가사항 : Visual Studio 2010의 의존성 다이어그램

  • 호환성 (Compatibility)
    • .net 3.0에서 .net 2.0으로 구현한 애플리케이션 안돌아가면 큰 문제. 기존2.0은 BCL(Base Class Library)라고 하고, WPF/WCF/WF 등을 추가함.
    • 정책적 or 급변하는 IT환경에 따라 호환성을 버릴 수도 있다. 이때는 마이그레이션 패스를 제공하라.
    • 버전간 호환성 (Cross-Version ~) : 동일한 제품의 다른버전에서 만든 코드의 호환성
    • 하위 호환성 (Backward ~) & 상위 호환성 (Forward ~) : 보통 하위호환성을 지원함..
    • 타제품간 호환성 (Cross-Redist ~) : 오라클 쿼리문을 MSSQL에서..
    • 바이너리 호환성 (Binary ~) : 예전 버전으로 만든 바이너리가 새버전에서도 컴파일 없이 잘 작동..
    • 소스 호환성 (Source ~) : 서로다른 버전이지만 소스코드 그대로 사용
    • API 호환성 : 서로다른 버전의 API간 호환성.


설계 (Design)

  • 메인시나리오 작성 ==> 시나리오에 부합되는 코드샘플 작성 ==> 개발자들에게 피드백하여 정제 ==> 객체 모델 정의
  • 프레임워크 디자인 스튜디오
    • 소개 : http://arload.wordpress.com/2008/10/11/introduceframework-design-studio/
    • Home : http://code.msdn.microsoft.com/fds
    • 사용법 : Add Assembly 사용하여 dll 또는 exe 추가 ==> Add Comment를 사용하여 사용자로부터 의견받음 ==> 수정 ==> Select Assembles to Compare를 사용하여 이전 버전과 비교 (빨:제거, 녹:추가, 회:상속)

  • 현실적인 프레임워크 구축하기
    • 모든 요구사항을 수용할 수 없다. ex) 빠른전송과 높은보안수준을 함께하기 구현하기 힘듬
    • 사용자 피드백을 취합해 가장 많이 요구하는 기능들을 우선순위로 정할것
    • Three Example Application을 구축/리팩토링하면서 안정화된 프레임워크 만들것.
  • 품질을 측정
    • 품질기준 사이의 균형 조절이 필요 (ex: 빠른전송 vs 높은보안)
    • ATAM : Architecture Tradeoff Analysis Method
    • 사용자들 모아놓고 품질속성(기능성, 신뢰성, 사용성...) 등에 대한 투표를 진행하라
  • 동일함의 힘
사용자 삽입 이미지

    • StyleCop
사용자 삽입 이미지



개발 (Development)

  • Feature 전담팀을 구성
    • 하나의 시스템 ==> 여러개의 Product Unit으로 나눔 ==> 각 PU에서 여러개의 기능(Feature)을 나눔\
    • 각 Feature가 완성시 기능/테스트까지 검증된 모듈을 얻음.
  • Quality Gate 구성 : Feature별 구현 완료의 기준이 필요함
    • 기능 스펙(Functional Specification)
    • 개발자 설계 스펙(Developer Design Specification)
    • 테스트 계획 (Test Plan))
    • 위협 모델 (Threat Model)
    • API Review
    • 아키텍쳐 리뷰 (Architectural Review)
    • 의존성 관리 (Dependency Management)
    • 정적 분석 (Static Analysis)
    • 코드 커버리지 (Code Coverage)
    • Testing (Unit and Integration Tests)
    • 0개의 Bug
    • 성능 (Performance)
  • 그외 고려사항
    • 네이밍룰
      • 파스칼 표기법 : PascalCasing - 첨에 대문자
      • 카멜 표기법 : camelCasing - 첨에 소문자
      • Uderscore 표기법 : SCREAMING_CAPS - 중간에 밑줄
      • 헝가리안 표기법 : sHungarian - 변수의 특성을 앞에
    • 약어 자제 : JLT(뭔 소리냐?), HTML(이건 다 아는거니까 봐줌)
    • 직관적 단어 : Count(일반적으로는 이거), NumberOfElement (XML에서는 이게 좋을것이다)
    • 상식에 맞게 : IFoo 는 당연히 인터페이스라고 누구나 생각한다.


프레임워크 매뉴얼 구축

  • 문서 로드맵(Documentation Roadmap) : 문서의 전체 구성 설명
  • 프레임워크 전체개요(Framework Overview) : 개요 및 도메인을 설명, 기능의 범위
  • 실례과 조리법들 (Cookbook & Recipes) : 특정 문제를 프레임워크로 해결하는 방안
  • 단계적인 예제들(Graded Example) : 어플리케이션 구축 방법 설명
  • 확장 포인트(Customizable Points) : 확장하는 위치 및 내부동작
  • 그밖에 : 문서에 소스코드를 제공하라. 에러발생시의 가이드라인 제시해라. 목차.

사용자 삽입 이미지


좋은 프레임워크란..

  • 쉽게 배워야
  • 문서 없이도 쉽게 사용해야
  • 실수하지 않도록 직관적이여야 (실패하기 힘들도록..)
  • 프레임워크 사용하면 코드가 읽기 쉬워야 (유지보수성도 좋아짐)
  • 확장이 쉬워야
  • 사용자를 고려해야..

'PP > Framework' 카테고리의 다른 글

프레임워크 구축과 발전  (0) 2012.01.04
애플리케이션과 프레임워크 동시 개발  (0) 2012.01.04
C#용 Open Source 조사  (0) 2012.01.04
프레임워크 개발 정리  (0) 2012.01.04
Spring.NET 프레임워크 활용 가이드  (0) 2012.01.04
posted by 방랑군 2012. 1. 4. 13:27
출처 :http://kimstar.pe.kr/blog/191?category=33

1-1. IoC Container


1-2. IoC, DI 정리


1-3. IoC Container 개인적인 평가

  • 잘 모르겠음. 많이 쓰는걸 쓰고 싶음.
  • 투표 : http://www.dominicpettifer.co.uk/?showResults=True 
  • StructureMap 이 오래되고 꾸준히 업데이트 되는거 같아서 좋음
  • MS가 Unity 미는거 같음
  • 자바에서는 Spring 이 대세라는것 같음.
  • 결승전 : Spring.NET vs Unity
  • 최종 : Spring.NET

2-1. ORM


2-2. ORM 개인적인 평가

  • iBatis 는 쉬워서 좋아보임. (근데... ORM 맞나?)
  • 그냥 LINQ 쓸까?
  • 결승전 : iBatis vs LINQ
  • 추가사항 : iBatis가 mybatis로 바뀌었다.
  • 최종 : LINQ, mybatis.NET iBatis.NET 

3-1. Unit Testing


4-1. Logger




 

뭐가 좋을까나....

사용자 삽입 이미지 
posted by 방랑군 2012. 1. 4. 13:27

출처 : http://kimstar.pe.kr/blog/190?category=33

프레임워크의 정의

  • 더글라스 슈미츠 (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팀 이상 원할때 추가하라.

프레임워크 리팩토링

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



사용자 삽입 이미지

 

'PP > Framework' 카테고리의 다른 글

프레임워크 구축과 발전  (0) 2012.01.04
애플리케이션과 프레임워크 동시 개발  (0) 2012.01.04
프레임워크 엔지니어링  (0) 2012.01.04
C#용 Open Source 조사  (0) 2012.01.04
Spring.NET 프레임워크 활용 가이드  (0) 2012.01.04
posted by 방랑군 2012. 1. 4. 13:24
얼마전에 전병선님의 CBD책을 열심히 봤었는데..
이분의 Spring.NET 자료가 있길래 예제를 따라해 봤습니다.
역시 직접 실습해보니 DI와 AOP 개념이 더 잘 들어오네요..

슬라이드나 pdf 파일이 필요하신 분은 아래의 링크를 참고하세요..



아래 첨부한 예제는 Visual Studio 2008 에서 실행하였습니다.

'PP > Framework' 카테고리의 다른 글

프레임워크 구축과 발전  (0) 2012.01.04
애플리케이션과 프레임워크 동시 개발  (0) 2012.01.04
프레임워크 엔지니어링  (0) 2012.01.04
C#용 Open Source 조사  (0) 2012.01.04
프레임워크 개발 정리  (0) 2012.01.04