프로토콜을 만드는 자세

프로토콜을 만드는 경우는 라이브러리와 비슷하다고 생각한다. 적어도 내가 대학원에서 배운 프로토콜들을 생각할 때 ((나는 전기 컴퓨터 공학부 대학원에서 이동통신망을 전공했다. 거기에서 PHY 바로 윗부터 MAC 단까지의 여러 가지 프로토콜과 TCP를 다뤘다. 여기서 많은 수의 프로토콜을 분석하고, 향상시킬 수 있는 부분을 제안하거나, 시뮬레이션 하거나 하다 졸업했다)) 이 둘을 만드는 자세는 꽤나 비슷한 거 같다. 그런 점에서 Coders At Work의 한 구절(좀 길지만) – Joshua Bloch 와의 인터뷰 – 를 인용해보겠다. 각종 강조는 내가 남긴 것(볼드;이탤릭;밑줄)

Seibel: What is your proces for desiging software? Do you fire up Emacs and start writing code and then move it around until it looks right? Or do you sit down on your couch with a pad of paper?

Bloch: I gave a talk called “How to Design a Good API and Why It Matters” at OOPSLA a couple years ago, and serveral versions of it are floating around the Web. It does a pretty good job explaining how I go about it.

The most important thing is to know what you’re trying to build: what problem you’re trying to solve. The importance of requirements analysis can’t be overstated.

(중략)

Coming up with a good set of use cases is the most important thing you can do at this stage. Once you have that, you have a benchmark against which you can measure any possible solution. (중략)

The worst thing that you can do – and I’ve seen this happen – is you get a bunch of smart guys into a room to work for six months and write a 247-page system specification before they really understand what it is they’re trying to build. (중략)

So get those use cases and then write a skeletal API. It should be really, really short. The whole thing should, usually, fit on a page. (중략)

The whole idea is to stay agile at this stage, to flesh the API out just enough that you can take the use cases and code them up with this nascent API to see if it it’s up to the task. It’s just amazing there are obvious in hindsight but when you’re designing the API, even with the use cases in mind, you get them wrong. (중략)

As your confidence in the API increases, then you flesh it out. But the fundamental rule is, write the code that uses the API before you write the code that implements it. Because otherwise you may be wasting you time writing implmentation code that won’t get used. In fact, write the code that uses the API before you even flesh out the spec, because otherwise you may be wasting your time writing detailed spece for something that’s fundamentally broken. That’s how I go about designing stuff.

간단히 해석+요약 하자면, “뭔가를 디자인 할 때 어떻게 하는가”라는 질문에 대해, Bloch 자신이 2년 전에 했던 강연 ((여기서 해당 제목의 PDF나 acm 포탈을 따라가면 볼 수 있다)) 을 보라며 이런 말을 한다.

1. 좋은 디자인을 하려면 요구 사항을 분석해서 use-case 를 만들어야 한다.
2. 이 use-case 를 염두에 둔 채로 간단한 뼈대로 API 명세를 만든다.
3. 그리고 이 초기 API를 코딩한다. 다만 충분히 기민하게 이를 수정한다.
4. 충분히 자신감이 쌓이면 이를 내놓는다.

하지만 가장 중요한 원칙은 “API를 쓰는 코드를 API 보다 먼저 작성하라” 라는 것. 심지어 이 API 명세를 작성하기보다도 먼저…

Bottom line

현실은 시궁창. 6개월 넘게 진행된 명세라는게 1주 구현하면서 내포된 모호성 때문에 상당 수가 뒤집힌 새 명세가 되더라. 그리고 이 명세는 구현 가능할 정도로 안정적인지 난 모르겠다. 명세 내부에서도 서로 모순인게 나오는데… 완성은 언제?