概要: Rebuild.fm #29 を聴いていて思ったコト
今日 Rebuild.fm #29 を聴いていたら、
テスト考 2014 - Hidden in Plain Sight
について言及されていて、それで色々と思ったコトがあるので、それをつらつらと書いてみる。
ぶっちゃけ僕は Web 系の人間で、かつ実務経験も無いので、言ってるコトが微妙な感じではあるんですが、僕が思うに、これからの、プログラミングにおいては、
仕様書としてテストを書く
という風にしていったら良いのではないのかなぁと思います。
というのも、そのサービスの、
- マントラ＝コアバリュー＝核となる信念
- ビジネスモデル＝顧客にどのような価値を提供して対価を得るか
辺りはまあ文書でしか表現できないにしても、
- サービス内のコンポーネントの仕様書
なんて作る必要あるの？ と思うんです。
無論、バグが命に関わる車の制御関連のプログラミングとか、そういうバグってたら人が本当に死ぬ系は、仕様書とかが必須だとは思うんですが、僕の関わってる Web 系なんかだと、仕様書とか作る意味あるのかなーと思うんです。
というか、僕がプログラミングするときに、ライブラリの使い方とか調べる場合、ドキュメントは多少見るにしろ、大体はテストコードを見て使い方調べたり、example code 見たり、あるいは golang とかだと godoc.org で自動生成されたドキュメントを見たり、とかするんですよね。
で、そのときに仕様書というかドキュメントが最重要か、っていうと、それは微妙に違っていて、僕らプログラマにとっては、
どのような メソッド、クラス、モジュールがあるか
より、
どのように そのメソッド、クラス、モジュールを使うか
が重要だと思うんです。
で、その どのように を知るために、僕らはテストコードを見るワケでして、それならば、仕様書とかドキュメントとか充実させるより、
- How to use としてのテストコードを充実させる
というようなのが重要、というかそっちの方が便利だよね、と思うんです。
で、最近の傾向だと、
みたいな、副作用を持つテストコードみたいなのが作られ始めていて、じゃあドキュメントや仕様書の類いも、
How to use としてのテストコード から 自動生成
してやれば良いんじゃないかなぁと僕は思うんです。
無論、その辺り専用のツールというか、まあライブラリが無いとちょっとしんどいとは思うんですが、これからは仕様書とかこだわらずに、
How to use としてのテストコード から 仕様書とかドキュメント を 生成する
という風にしていけば、仕様書やドキュメントとコードが食い違ってるとか、あるいは引き継ぎしたコードの使われ方がわかんねーとか無くなるんじゃね？ とか僕は思います。
あ、でも一応補足しておくと、ビジネスモデルとかコアバリューに関連すうる、
- そのサービスでどのような価値を提供し、その対価を得るか
のドキュメントというか事業案みたいな仕様書っぽいものは要りますよ。当然のコトながら。それは司令官用の羅針盤なんで。
で、ドキュメントが生成しづらい、あるいは生成できない UI/UX なんかについても、ペーパープロトタイピングとか、あるいは専用アプリでの UI/UX のプロトタイピングは、 プログラミングの過程として は必要だと思います。っていうか、そういうのって、あれです、 非コード的 ではあるものの、それは UI/UX のプログラミングそのもの だと僕は思います。
まあ一応、今日、
を聴いていて、思ったことはそんな感じです。まあ、うまく言いたいことを言えているかどうか、が、ちょっと微妙ですが。
まあそんな感じなコトを思ったということで。はい。おわります。
