プロトタイプは2回作りたい
最近難しい設計をすることがあってプロトタイプによる実現可能性の検討を行った。
そこでは次の2段階のプロトタイプを作った。
- つながりを確認して自分が納得するためのプロトタイプ
- ちゃんと考えてみんなが納得するためのプロトタイプ
プロトタイプを2回作ることで不確実性が下がって手戻りなく本実装を進めることができた。 自分にはこの方法が合っていたのでまとめておく。
1回目は繋がるかどうかだけを確認する
1回目のプロトタイプは自分の中で実装のイメージを付けるために行う。
そのためには既存の処理を拡張するにしろ新規の処理を追加するにしろ、繋がるかどうかの確認をするとよい。
具体的には、様々な関数を呼ぶ一連の処理があるときに処理のボトムから関数の引数だけを求める形に変更して、その引数を満たすことができるかどうかを確かめていった。
funcA -> funcB -> funcC と依存があるときに funcC の引数を変えて funcB がその引数を渡すことができるか、funcB の引数を変えて… といった調子。
繋がるかどうかだけを気にしているので、テストが落ちまくっていても気にしないし、コードがどれだけ適当でも気にしない。 自分が実装できそうなイメージが掴めればオッケー。 1回目のプロトタイプは速度を重視するとよい。
実装のイメージが付いたら、あとはそのイメージをどうやってきれいに実装するかを考える必要がある。
2回目はちゃんと考えて本実装はあとはやるだけ状態にする
2回目のプロトタイプは自分なりにちゃんと考えたあとにレビューを受けて本実装に入る前にレビュアーを含めてやることの共通認識を作っておくために行う。
プロトタイプと言いながら本実装と同じぐらいの本気度で命名や処理の流れを考える。 ただしテストは書かなくてもよいと言うのが本実装との違い。
この時点でレビューを受けることでソースコードレベルで議論を行うことができる。 具体的には、この命名はおかしいんじゃない？とか新しい概念がいっぱい登場して難しいですねといったフィードバックを受けて、よりシンプルで既存のコードとも雰囲気の揃ったものに変更することができた。
2回目のプロトタイプが完成した時点で本実装は「あとはやるだけ」になる。 自分もレビュアーもこのあとの本実装で何が実装されるのかがわかっているのでレビュアーの負担も減るはず。
考え方としてはこの記事とかなり近いと思う。タイトルも寄せました🙏
