특히 많은 사용자들을 위한 경우, API 설계는 어렵습니다. 만약 여러분이 수 백에서 수 천의 사용자들이 사용할  API 를 설계한다면, 미래에 이것이 얼마나 바뀔 것인지, 그리고 변경 사항이 클라이언트 코드를 손상시킬 수 있는지 여부를 고려해야 합니다. 그 이상으로, 여러분은 API 사용자가 여러분에게 어떻게 영향을 미칠지 생각해야 합니다.

만약에 여러분의 API 클래스 중 하나가 내부적으로 자신의 함수들 중에 하나를 사용한다면, 사용자가 여러분의 클래스의 서브클래스를 만들고 오버라이드override 할 수 있으며, 그리고 그것은 재앙이 될 수 있다는 것을 꼭 명심해야 합니다. 몇몇 사용자들이 그 메소드를 서로 다른 의미로 받아들였기 때문에 여러분은 그것을 바꿀 수 없을지도 모릅니다. 메소드 내부 구현에 대한 여러분의 향후 선택은 사용자들이 이를 얼마나 받아들여 줄 수 있느냐에 달려 있습니다.

API 개발자들은 다양한 방법으로 이러한 문제들을 해결하지만, 가장 쉬운 방법은 API 를 봉쇄하는 것입니다. 만약 여러분이 자바 환경에서 작업한다면, 대부분의 클래스와 메소드를 final 로 선언하는 유혹에 빠질 수도 있습니다. C# 환경에서는, 여러분의 클래스와 메소드들을 sealed 로 선언해 버릴 수도 있습니다. 여러분이 어떤 개발 언어를 사용하든 간에, 행위를 오버라이드하거나 이후에 여러분의 선택을 제약하도록 코딩하는 것을 막기 위해 싱글턴 패턴이나 정적 팩토리 메소드를 이용해 API를 제공하고자 할 것입니다. 이 모든 것들이 합리적으로 보입니다만, 진짜로 그렇습니까?

지난 십년 동안, 우리는 점차 단위 테스트가 실전에 매우 중요한 부분이라는 사실을 깨달았지만, 이런 교훈이 업계에 완벽하게 확산되지는 못했습니다. 그 증거는 우리 주위에 널려 있습니다. 타사의 API 를 사용하는 임의의 테스트 안된 클래스에 대한 단위 테스트를 하려고 하면, 여러분은 곤경에 빠질 것입니다. 여러분은 그 코드가 마치 접착체로 붙인 듯이 API 를 사용하고 있다는 것을 알게 될 것입니다. 그것이 API 클래스이고 그래서 여러분의 다른 코드와 API 가 상호작용 한다는 것을 알아챌 수 있도록 하는 방법도 없고, 그래서 테스트를 위한 반환값을 제공할 수 있는 방법도 없습니다.

계속 읽기

프레임워크 문서화 잘하기 자료입니다.  이 글의 모든 저작권은 박선욱 님에게 있습니다. 

 

박선욱님이 마소 9월호에도 기고를 하셨는데, 추후 기고 자료도 공유하도록 하겠습니다.

 

발표 자료 소개
 새로운 프로젝트를 할 때마다 새로운 프레임워크를 접하는 일은 이제 예사가 되었다. 어떻게 새로운 프레임워크를 학습하여 활용할 수 있을까? 역발상으로 프레임워크 문서화 잘하기 패턴을 통해서 우리가 원하는 정보가 어디 있는지 알 수 있다.

때로는 관련 책을 제목만으로 선택할 수 있게 해준다. 또한 프레임워크가 아니더라도 우리 프로젝트에 적용할 수 있는 문서화패턴에 대해서 생각해볼 수 있다.

계속 읽기

JCO에 이어 저희 EVA팀이 6월 23일 오후2시 Framework와 연관된 세미나를 준비했습니다.

NIPA 소프트웨어 공학센터에서, JCO때  제가 발표한 Framework Engineering 외에 별도 2개의 세션을 더 추가해 발표합니다.

장소는 마포구 상암동에 있는 누리꿈 스퀘어 입니다. 약도는 링크를 참조해 주세요.

계속 읽기

Framework 설계시 가장 중요시 여겨야 하는 것이 사용성이다.

사용자들이 쉽게 사용하고, 생산성에 만족하느냐가 Framework의 생존 여부와 연결되어 있기 때문이다. 쉽게 사용할 수 있는 사용 편의성을 일전에 얘기한 적이 있지만,이 못지 않게 중요한 것이  Framework 사용자가  실수를 하기 어렵게  만드는 것이다. 즉  실수하지 않게 성공의 웅덩이를 만들어서 성공할 수 밖에 없게 만들라는 얘기다.

PLoP10으로 인해 Framework 관련 논문을 작성하면서, .NET과 Java Framework를 설계한 대가들의 공통적인 충고를 들을 수 있었다.

계속 읽기

오래 기다리셨습니다!

드디어 Framework Design Guidelines 2nd Edition의 1차 번역이 완료되었음을 알려드립니다.

참으로 오랜 기간동안 번역되었습니다. 사실 더 일찍 번역될수 있었지만, 저를 제외한 몇몇 분들이 취업, 개인사등의 문제로 예상외로 아주 오랜 시간이 걸렸습니다. 거기다 저의 PLoP 욕심도 한 몫 했습니다.

정말 이 책을 기다리시는 많은 분에게 죄송하고, 특히 지앤선 가족 분에게 많이 미안하네요.

죄송한 말씀이지만 1차 번역이 완료되었다고 해도, 전 아직 저를 못믿습니다…

POSA 시리즈 만큼 설계의 명서이고  몇 안되는 Framework  서적중 하나이기 때문에,  잘못 오역 하거나 너무 어렵게 번역되면 (사실 충분히 어려운 내용이죠 .)  미치는 파급 효과가 엄청나기  때문이지요.

계속 읽기

여러분!! 인기 있는 Framework를 만들고 싶으신 가요? 저 역시 그렇습니다.

인기 있는 Framework를 만들기 위해 Framework Design Guidelines에서  나온 내용(.NET Framework 설계자인 Krzystof Cwalina의 조언)들을 일부 여러분과 공유하고자 합니다.

  • 사용성 테스트
  • 점진적인 학습 곡선
  • 캡슐화의 오해

이번 포스트에서 다룰 주제는 이렇습니다. 자 그럼 하나씩 살펴 보도록 하죠 :)

계속 읽기

Framework Design Guidelines 2nd Edition일반적으로 알고 있는 것 과 달리, Namespace의 주 목적은 이름을 가진 타입들의 충돌을 해결하고자 하는 것이 아니다

Namespace의 주 목적은  응집력 있고, 쉽게 찾을수 있으며, 쉽게 이해할 수 있는 계층구조로 타입들을 구성하는 것이다.

하나의 프레임워크 안에 타입 이름의 충돌은 조잡한 디자인을 나타낸다고 생각한다.

동일한 이름을 가진 타입들은 더 나은 통합을 위해  라이브러리의 특정 부분들을  합치거나, 코드의 읽기와 검색을 향상시키기 위해서 새로운 이름을 할당하는 것이 좋다.

출처 – Framework Design Guidelines 2nd Edition.

계속 읽기

예전에 Framework’s Day에 발표했던 Framework Engineering 의 동영상 강좌를 지난 토요일날 찍었습니다.

Framework 구축시 여러분이 겪을 시행 착오를 조금이나마 줄일 수 있길 바라며 강좌를 공유합니다.

이 강좌에 대한 내용은 저의 머리에서 나온 것이 아니라, .NET Framework의 설계자인 Krzysztof Cwalina의 강좌와 현재 저희가 번역하고 있는 Framework Design Guideline 2nd 추가해 정리한 것입니다.

이 발표의 전체적인 내용은 아래와 같습니다.

계속 읽기

2월 기고에 이은 Framework Engineering Part II를 여러분에게 공개합니다.

Part I에 대한 글에 대한 평이 없어서?  과연 좋은 글을 썼는가 다시 의문을 가집니다.  :(

.NET 진영은 Java 진영보다직접 Framework를 구축하는 일 보다는, 사용하는 일이 더 많으니 그러겠지 하고 혼자 생각하고 있습니다.  :)

여기서 소개한 툴들과 거의 일대일 대칭이 되는 툴들이 Java 진영에도 있으니  Technic 적인 측면보다, Framework를 구축할때 어떠한 것들을 고려해야 되는지 경험과 프로세스 측면에서 저희들의 부족한 글을 이해해 주시길 부탁드립니다.

많이 부족한 지식이지만 조금이나마 다른 분들에게 도움이 되는 글이였으면 좋겠네요 :)

이번 글은 지난호에 이어 아래의 주제들중 아키텍쳐에 다 못다한 애기부터 다루었습니다.

계속 읽기

마소 1월호 주제인 Application과 Framework 동시 개발하기에 이어, 2월호에는 Framework 설계시 실제 필요한 Engineering 기법들에 대해 기고했습니다. 물론 결코 저의 머리에서 나온 것은 아닙니다. :)

이 글은 .NET Framework를 설계한 Krzysztof Cwalina의 TechED 강의 내용과 저의 지식을 덧분인 글입니다.

Krzysztof Cwalina의 강좌를 보시고 싶으신 분은 여기를 클릭하시길 바랍니다.

12월호 있었던  세미나와 지금까지 블로그에 기고한 Post들을 모은 내용이기 때문에, 저의 블로그 독자 분들(?)에게는 미안하네요 :)

이번 글은  크게 6가지 주제들을 다룹니다.

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

이중 조직, 계획, 아키텍쳐에 대한 내용을 2월호에 다루었습니다.

계속 읽기