KDOC 101: 先にインターフェースを文書化するとやりやすい

この文書のステータス

既存コードなし・知識なしの状態から作るとき、コードを書き出すまでが遅い。そういうときテキストでブレークダウンして書き出したりはするが、コードに踏み出す最初の一歩は重い。

そういうとき、疑似コードでインターフェースを先に書くと早く書き出せることに気づいた。直近の、趣味のゲーム開発ではコードを書き始める前に、こんな感じのを書いた↓。「アイテム合成」に使う「素材」をどう設計するかだ(「素材」というデータ構造はまだできていない)。インターフェースを書く。

Listing 1: 例

material.GetCount("ガラクタ") // => 3
material.IncCount("ガラクタ", 1) // (3 + 1) => 4
material.DeclCount("小さな花", 1) // (2 - 1) => 1

ここからわかるのは、「素材」にはデータ構造としては名前と数量しか必要ないということだ。あとは数量を変化させるインターフェースがあれば事足りる。

ユースケースをコードにすることで必要なデータ構造を決めやすくなった。データ構造ができてしまえばインターフェース通りに作ると出来上がる。頭の中では今までもなんとなくやっていたのだが、テキスト化すると効果が大きいように見える。