オブラブクリコン 2008
昨日はオブジェクト倶楽部クリスマスイベント2007にスタッフとして参加してきました。
今回は「オブジェクト指向」に回帰する、という会で、いろいろと面白い視点を得ることができました。スピーカーの方々も、本当にありがとうございました。また、highly motivatedな参加者の皆様と一緒にイベントを行えたこと、これまた嬉しかったです。LTはもう皆さん職人の域に達してらっしゃいますね。すげえ。今後ともどうぞよろしくお願いします。
で、感想です。
遠からず資料が公開されると思いますので、議事録的なものではありません。
平鍋さん
お話の中でも特に、オブジェクト指向の再定義、と題したあたりが印象的でした(受付スタッフやってたので前半は聞けなかった)。オブジェクト指向の要素技術がどうとかいうよりも、それがなぜ必要なのか、何の為にあるのか、という観点からの再定義はたいへん美味しゅうございました。
その中で、『オブジェクト指向再定義 2/2』のスライド「継承・インターフェースは、Mockを作りやすくする技術。TDDの為の技術。」という観点には心から同意です。うん。DIもそうなんですが、プロダクションコードに手を入れないでコラボレータを差し替えることができるというのは、それがないときにどんだけテストを書きづらいか、という逆パターンを考えると重要度が実感できますよね。
だから動的言語のほうが(ry とかいいたくなるんですが、それはまた別の話。
酒匂さん
形式仕様記述についてお話をいただきました。そこからDesign by Contractの話にも。不勉強なためこういった分野のお話を聞くのは始めてだったのですが、いろいろと刺激を受けました。
こちらも詳細は資料に当たってくださいませ。
結論
形式仕様記述っていうのは「書いたこと、考えたことを『ムダにしない』技術」
- いますぐ試してみよう
- 形式手法はコミュニケーションを助ける
- 「仕様が曖昧だ」「要求が定まらない」はコミュニケーションの問題。
- 他者との対話/自分との対話の基礎を固めて「本質的に考えるべきこと」に時間を割こう
形式手法とは？
ソフトウェア開発に置いて、ある側面の『仕様』を厳密に記述し、開発行程で利用する手段の__総称__
モデルベースとモデル検査
- モデルベース
- 情報の構造や状態から他の状態への変化をモデル化(今回の話はこっち)。曖昧さの除去，専用言語*1の利用によるコンパクトな記述、仕様の「実行」
- モデル検査
- 振舞のモデル化、全状態空間を生成し自動検査
仕様書の位置づけ
- 「仕様」は課題と設計をつなぐもの
- 「問題の解決(課題)」が「問題の解法(設計)」どのように結びつけられるか
- 仕様記述が満たすべき性質
- 課題
- 目的
- 前提
- 依存
でも大抵満たされていない、と言うか難しいよね。
で、仕様の完全性を検証する、という段で脊髄反射的に「そこでRSp(ry」と言いそうになるんですが、仕様を検証するためにプロダクションコードを作る、というのはちょっと本末転倒っぽい。
どちらかと言えば検証済みの仕様に対して作られたプロダクションコードを、その検証済みの仕様で検証する*2、というのがRSpecのアプローチですよね。
このへんはRSpecネタと絡めていろいろ話したいなぁ。こういうのをうだうだ話せる同僚がいっぱい居るのは幸せなことだと思う。
じゃあ「検証済みの仕様」とやらはどう作るんだ?
形式仕様記述言語、ようするに仕様を記述する為のDSLがある、と。仕様が仕様としてちゃんと動くか、を検証する。詳細はスライド参照。ちなみに現在ではそういった形式仕様記述言語と実行エンジンは無償で使えるとのこと。
あと面白かった観点では
「形式仕様には"行間"が存在しない」間違ってるのが明確になるからお互いがその間違いに立ち向かえる。問題vs私たち。
日本語の仕様の誤りを指摘すると喧嘩になりやすい。母国語だと自分のもっとメンタルなものを仮託するらしい。確かに思い当たるところがありますね。なんか不思議。
以上、繰り返しのエクスキューズになりますが、上記はあくまで私の感想です。資料が公開されたらそちらにも当たってくださいね。
