인기있는 Framework을 만들고 싶다면..
여러분!! 인기 있는 Framework를 만들고 싶으신 가요? 저 역시 그렇습니다.
인기 있는 Framework를 만들기 위해 Framework Design Guidelines에서 나온 내용(.NET Framework 설계자인 Krzystof Cwalina의 조언)들을 일부 여러분과 공유하고자 합니다.
- 사용성 테스트
- 점진적인 학습 곡선
- 캡슐화의 오해
이번 포스트에서 다룰 주제는 이렇습니다. 자 그럼 하나씩 살펴 보도록 하죠 🙂
사용성 테스트
“출판계에는 책의 판매부수는 그 책에 등장하는 수식의 수와 반비례한다는 말이 있다.” 이 법칙을 Framework 설계자 버전으로 바꾼다면 다음과 같다. “당신의 API를 사용할 고객의 수는 당신의 단순 시나리오에 나오는 new 문장의 수와 반비례한다.”
Krzystof Cwalina 는 Framework를 다 만든 후 사용자에게 피드백을 받기보다는, 가장 일반적으로 사용되는 시나리오를 작성하고, Prototype으로 사용성 테스트를 한후 Framework를 만드길 권하고 있습니다.
왜 이렇게 민감하게 말하나면 Krzystof는 실제 . NET Framework 1.x 의 메뉴얼을 주지 않고 사용성 테스트를 한 결과, 개발자들이 간단한 프로그램도 짜지 못하는 상황을 보게 되었습니다. Framework 설계자로는 매우 큰 충격이겠죠. 그래서 하위 호환성도 포기한체, .NET Framework 1.X를 버리고 2.0을 개발하게 되었고 지금 .NET Frmaewokr의 Base Class Library가 되었습니다. 사용성 때문에 하위 호환성을 버린다는 것은 쉽지 않은데… 뭐 전 버젼이 1.0만 나왔으니 그럴수 있겠죠 🙂
자 여러분이 만든 라이브러리나 프레임워크는 정말 다른 사람이 사용하기 편하게 만들어 졌을까요?
Krzystof의 경험한 예를 보여 드리겠습니다. 아래의 간단한 샘플 코드를 보시죠. 파일으로 부터 데이터를 읽어 오는 코드입니다.
static void Main(string[] args) { StreamReader sr = File.OpenText("MyFile.txt"); string s = sr.ReadLine(); while (s != null) { s = sr.ReadLine(); Console.WriteLine(s); } }
만약 이 코드가 사용성 관점에서 별 문제 없어 보인다면, 아마 여러분은 C/C++로 파일 처리를 많이 해본 개발자라고 생각합니다. 더 이상 어떻게 간단해 질수 있냐고 반문할수도 있지만 이게 복잡하다고 말한 개발자들이 있었습니다.
그들에게 아래와 같은 사용성 피드백을 받았습니다.
static void Main(string[] args) { foreach (string s in File.ReadAllLines("MyFiles.text")) { Console.WriteLine(s); } }
자 더 간단하죠~~ 기존의 우리가 가지고 있는 관습들을 벗어나기 위해서는 전혀 새로운 시선이 필요하고 바로 다른 사람의 피드백을 받아야 된다는 것입니다.
학습 곡선이 점진적으로 증가하는 프레임워크를 구축해라.
인기 있는 프레임워크의 또 한가지의 비결은 이전 버젼의 개발자의 경험을 최대한 존중해, 학습 곡선을 줄여 주는 것입니다. 실제 VB.NET이 나오고 나서 기존 VB와 전혀 다르게 만들어져서 원성을 많이 들었다고 합니다.
위 그림 처럼 마치 MFC를 배우는 것 같이 전혀 새로운 언어를 학습해야 했다며, 원망을 했다고 하네요. 또한 개발자의 기존 경험을 존중하는것 만큼 하나를 학습하면 다른 모듈에서도 쉽게 응용하여 사용할 수 있는 점진적인 학습 곡선을 제공하는 것 역시 중요합니다. 우리가 파일을 제어할 때, Text , Binary, XML 과 같은 파일 형태와 관계없이 하나의 경험을 동등하게 다른 파일 제어에서도 이용할 수있다면 좋은 Framework일 겁니다.
적절한 캡슐화
캡슐화 하면 무엇이 떠오르시나요? 전 자판기를 먼저 떠오르네요. Input과 Output만 알면 내부를 몰라도 되는 정보 은닉(Informatin Hiding)이 가장 먼저 떠오릅니다.
아마 저를 비롯해 많은 개발자들이 캡슐화를 할때, 복잡한 것을 은폐(은닉)하는 것만 신경을 쓰고 있습니다. 하지만 반대로 노출해야 할 것은 적절히 노출해 주는 것 역시 중요합니다. 여러분이 만든 Framework나 Library들이 다른 개발자들이 사용하기 위해서 내부 구조를 파헤쳐야 한다면, 잘 설계된 것은 아니겠죠 🙂 이것 역시 적절한 사용성 피드백을 통해 어느정도 해결 할수 있다고 봅니다. 사용성 피드백만 잘 수렴할수 있다면 굳이 Ralph Johnson이 언급한 3 Example 까지 갈 필요는 없겠죠 🙂
도움이 될만한 강좌들
자 그럼 더 자세한 애기는 거장들의 Framework 강좌와 제가 발표했던 Framework Engineering을 보시길 바랍니다. 모든 것의 해답은 아니지만 도움은 될거라고 생각됩니다. 그리고 .NET을 사용하는 개발자라면 부록으로 Framework Design Studio도 사용해 보세요 . 좋은 도구가 될 것입니다.
ps) 혹시 Framework Design Studio를 Java 버젼으로 만들어 주실 분은 없나요? Java 버젼의 비슷한 툴이라도 알고계시면 알려주시길 바랍니다. 🙂
잘 읽었습니다. 사용성때문에 .NET 1.x 하위 호환성을 버렸군요. 이런 스토리가 숨어있는지 몰랐습니다.
“반대로 노출해야 할 것은 적절히 노출해 주는 것 역시 중요합니다” 아~ 저도 감추는 것에만 신경을 썼네요. 탁~ 머리를 쳐주는 좋은 말이군요.
안녕하세요 ohyecloudy님 🙂
거진 다 Framework Design Guidelines에 나와있는 내용이에요 ㅎㅎㅎ.
나중에 번역판 나오면 한권 사주세요 🙂 ㅋㅋㅋ
개발자 도구를 만들고 나서는 꼭, 개발자들이
어떻게 쓰는지를 봐야죠.
다른 것도 그렇지만
특히 소프트웨어 개발 도구(프레임웍, 라이브러리)는
정말 내가 생각 못한 방법으로 사용하는 경우가 많더군요.
테스트 자동화 시스템을 사용하기 위해 개발자가 이중으로
데이터를 작성하는 경우도 있고,
문서 자동화가 잘 안되어서 개발 막바지에
만들어 놓은 소스들을 통폐합 시키는 경우도 있고…
그래서도 현장을 겪어본 툴과 그렇지 않은 툴은
쓰다보면 차이가 나는 것 같네요.
함께 일했던 .NET 개발자들이 2.0을 접하면서
다시 배워야 한다던 그 좌절의 목소리…
그 이유가 여기 있었군요.
수고하세요~.
안녕하세요 임성현님 🙂
잘 지내시죠 ~~
프레임워크의 내부의 우아한 구조를 가지는 것도 중요하지만
사용하기 편리하게 만드는 것도 중요한 것 같습니다.
만약 두개가 충돌이 나는 상황이라면 어떻게 해야 할까요? 여러가지를 생각해 보게 되네요 🙂
그럼 항상 좋은 일이 가득하세요 🙂
[…] 일반 상위 Application과는 전혀 다른 성격을 가지고 있습니다. 예전 포스트(인기있는 Framework를 만들고 싶다면)에서 언급한 것 처럼 프로그래머가 사용하기 쉽고, 학습시간도 짧아야 […]
안녕하세요.. 오랜만에 들러봅니다. 번역은 잘 되가시는지요.. 좋은 글 읽고 갑니다. 책이 어서 나왔으면 하네요.
안녕하세요 즈믄님 충성!!
이번달 중순에 작업이 완료될 예정입니다.
그때 바로 콜 할게요!! 신경써주셔서 감사합니다. 하시는 번역 작업은 잘 되시는지:)
궁금하네요..
[…] 우리 설계자들이 추상화 또는 캡슐화를 할때 종종 하는 실수가 있습니다. 바로 너무 과도한 추상화/캡슐화는 하는 것이지요. 노출해야 할 것은 적절히 노출해 주는 것 역시 중요합니다. […]
[…] 일반 상위 Application과는 전혀 다른 성격을 가지고 있습니다. 예전 포스트(인기있는 Framework를 만들고 싶다면)에서 언급한 것 처럼 프로그래머가 사용하기 쉽고, 학습시간도 짧아야 […]
[…] 정말 인기있는 프레임워크를 만드는게 목표인데, Domain 특화된 용어들을 잔뜩 적어 놓으면 그 분야의 전문가가 아닌 사람은 접근할 수 없는 성역을 만들게 된 것입니다. 사실 많은 프레임워크 설계자가 가지는 큰 우입니다. 내가 그분야의 전문가이니 다들 이렇게 하면 알겠지… .NET 프레임워크의 설계자인 Krzysztof Cwalina 의 실패 경험을 통해 나온 정말 값진 격언입니다. […]
Software Safety에서 이 항목을 퍼감댓글:
인기있는 Framework을 만들고 싶지 않은 사람은 없을 것이다…나 또한 그러하고, 항상 사용성을 극대화시킬 수 있는 방법을 고민하는데, 이 내용이 도움이 될 것이라 생각한다.