요즘 소프트웨어가 갈수록 거대해지면서 소프트웨어 통제에 대해 많은 애기를 들을수 있습니다. 그리고 소프트웨어 통제를 들어보신 분이라면, xDepend 라는 툴은 한번쯤 들어보셨을 겁니다.
이번 post는 아키텍쳐 설계시 dependency는 무엇이고 어떠한 종류가 있는지 설명하고, dependency를 관리할때 유용한 Layering과 xdepend 툴에 대해서 소개해 보는 시간을 가지겠습니다.
의존성 (dependency)을 어떻게 관리하느냐에 따라 여러분이 가진 시스템이 쉽게 확장가능한지 (변화에 쉽게 대처 가능한지)를 파악할 수 있으며, 이러한 추세를 반영하여 요즘 쉽게 패키징 할수 있는 단위로 시스템을 구축하는 것에 대해 많은 연구가 진행되어지고 있습니다.
Framework Design Guideline의 저자인 Krzysztof Cwalina의 TechED 2007 Framework Engineering 온라인 세션을 듣고 토론회를 가졌습니다.
편역을 하기전에 Framework 에 관해 배경지식을 쌓고, Paper Meeting 행사를 위한 가이드라인을 만들고 공유하기 위한 목적도 있었습니다.
Krzysztof Cwalina는 실제 .NET Framework를 설계한 분으로, 그의 경험을 책을 통해서 공유했을 뿐만 아니라, FxCop 이라는 툴을 이용해 VS.NET 내부 개발자들의 코드 품질을 검증하는 시스템을 외부로 공개하고 알린 분이기도 합니다.
Framework Engineering은 TechED2007 Europe 에서 발표한 세션으로 원래 일반인에게는 비공개이나, 고맙게도 자신의 블로그를 통해 공유해 주시고 계십니다.
아키텍트가 되기 위해서 우리에게는 어떠한 덕목이 필요할까요?
2007년 10월에 소프트웨어 아키텍쳐 이론과 실제 (Software Architecture in Practice)의 저자인 Rick Kazman이 한국을 방문해 ATAM에 대한 강연을 하였습니다.
세미나가 마친후 어떤 분이 “당신과 같이 휼룡한 아키텍트가 되기 위해서는 어떠한 소양과 지식이 필요한지 설명해 주시겠습니까?” 라는
질문을 했고, 이에 대한 멋진 답변을 해 주셨는데 제가 알고 있는 지식을 덧 붙여 여러분과 함께 공유하고자 합니다.
제 1회 Paper Meeting에 여러분을 초대합니다.
기존의 단방향 세미나에서 탈피해, 새로운 형태의 모임을 만들었습니다.
하나의 Paper를 선택하시시면, 여러분과 동일한 Paper를 선택하신 분들과 조를 나누어 토론/지식 공유 모임을 하고
맨마지막 조별 10분식 자신의 조가 나누었던 애기들을 마인드 맵 형태로 정리해서 나누는 유익한 세미나 입니다.
좀더 자세한 정보및 등록은 http://www.onoffmix.com/e/only2u4u/149 에서 얻으실수 있습니다.
소프트웨어의 현재 상태를 모니터링하거나, 오류시 원인을 파악하기 위해 Log를 남기실 겁니다. 많은 분이 Log4J , Log4NET을 이용하십니다.
하루에 쌓이는 엄청난 로그양때문에, 골치 아프신 경험이 있다면 이 논문을 꼭 읽어 보시길 바랍니다.
이 패턴은 Logging 데이터의 Overflow를 막기 위해 우리가 어떻게 해야되는지 접근 법을 설명하고, Log4XXX(.NET, Java …) 의 내부기능과 비교하여 설명을 합니다.
호환성 (Compatibility) 이라는 말을 들어보셨나요?
- .NET 3.0 버젼 Framework에서 .NET 2.0으로 구현했던 Application이 돌아가지 않는다면?
- JDK 1.6버젼에서 JDK 1.4 Framework 기반의 Application이 돌아가지 않는다면?
새로 나온 제품이 아무리 좋은 기능이 많이 추가 되어 있더라도..예전 제품과 호환이 되지 않는다면, 그 제품은 잘 팔리지 않을 겁니다. 이번 POST 를 통해 우리가 Product 또는 Framework을 만들때 고려해야 되는 호환성과 여러가지 종류에 대해서 공유하고자 합니다.
혹시 소프트웨어를 만드실때, 땅콩버터 방식으로 만드시지는 않나요?
땅콩 버터라는 것은 Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스를 말합니다.
Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들때 주로 사용하는 방법입니다.
이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올수 있는 장점이 있습니다. 마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저수준의 Library를 개발할때는 이러한 방식이 선호 됩니다.
만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야하고, 다양한 시나리오를 요구하는 경우인데도, Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 국내의 많은 회사들이 이러한 구조를 가지고 있는데요. 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될뿐만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제등이 발생됩니다.
여러분에게 좋은 소식을 하나 전해드리고자 합니다.
POSA2에 이어 또 하나의 명서인 Framework Design Guidelines 2nd Edition의 편역을 위한 모임을 가졌습니다.
이 책은 Framework를 잘 설계하기 위한 Guideline을 제공하는 서적으로 Microsoft의 .NET Framework 설계팀들이 직접 집필한 서적입니다. Framework을 처음 설계하는 개발자에게는 매우 유용한 서적이 될듯 합니다.
현재 http://fdg.springnote.com 에서 작업을 시도하고 있으면, 저희 스터디시 만들어진 가치있는 공유물들을 여러분과 함께 나눌 생각입니다.
Architecture 101 