例に基づく開発でソフトウェアの明確さを高める

ソフトウェアシステムは、作業しているときに明確で理解しやすいものであるべきだよ。良いソフトウェアは、開発中や使用時に抱くかもしれない質問に答える手助けをしてくれるんだ。でも、普通のドキュメントはあまり効果的じゃない。テキスト文書はすぐに古くなっちゃうし、テストはコードにリンクはしてるけど、システムの動きについてあまり洞察を与えてくれないことが多いんだ。

テストは特定のケースやシステムの挙動を示すときに役立つけど、基本的にはあんまり魅力的でも読みやすくもないんだ。たとえば、システムの面白い部分を作成するテストは、もっと有用性を提供できるよ。単に合格か不合格かだけじゃなくて、テストが後で見ることができるオブジェクトを返すこともできる。これにより、テストがシステムを理解するためのもっとインタラクティブな方法を提供できるんだ。

この記事は、Example-Driven Development（EDD）というソフトウェア開発の新しい方法を紹介してるよ。EDDは、システムの動きを示す例を使うことでTest-Driven Development（TDD）を改善するんだ。例を見ながら、ソフトウェアをもっと理解しやすくできるし、ライブドキュメントにも例を含めて、システムの動作を説明するのに役立つんだ。

#テストにおける例の役割

ユニットテストの話をすると、小さいコードの塊で他のコードが正しく動作しているかチェックするものを指すことが多いんだ。最初、テストはフィクスチャと呼ばれるオブジェクトと一緒に作業する。これらのフィクスチャは共通のセットアップメソッドを使って作られて、テストが終わると大抵は捨てられちゃう。もしテストが通らなかった場合、デバッグツールを通じてしかフィクスチャを見ることができないんだ。

ここにチャンスがあるよ。違うアプローチでは、テストはフィクスチャをチェックするだけじゃなくて、それを返すべきだと言っている。つまり、テストが後のテストに使える例を生成できるってこと。これらの例を組み合わせて、大きなテストシナリオを作ることができるんだ。

どんなテストフレームワークでも、例をサポートするように変更できるよ。たとえば、JExampleというフレームワークでは、テストが返却されて再利用できる例を生成することができる。テストを例を返すように変更すると、コードの繰り返しを減らせて、バグも見つけやすくなる。現実世界のテストは、無駄にコードを繰り返すことが多いんだ。これらのテストを分析することによって、従来のユニットテストを例に変換することが可能なんだ。

例によってテスト同士のつながりが見えるようになるから、コードの繰り返しが減ってバグを見つけるのが簡単になる。でも、例はソフトウェアの開発の仕方をも変えることができるんだ。

#EDDでTDDを強化する

テスト主導開発（TDD）は、開発者にテストを書くことを先にして、その後でテストが必要なコードを書くように促している。でも、このアプローチには課題もあるんだ。一つ大きな疑問は、「何をテストしたいのかをどうやって知るの？」ということ。時には、セットアップや期待する結果は分かるかもしれないけど、必要なチェックが不明瞭で、何を書くべきかを推測することを強いられることが多いんだ。

グリーンテスト（通ったテスト）を持っていたとしても、次にどう進めばいいのかわからないこともある。グリーンテストは過去の機能がまだ動いていることを示してるけど、次の有益なステップを生み出すのに役立つわけじゃない。レッドテスト（失敗したテスト）はデバッグに導いて問題を特定する手助けをしてくれるけど、合格するだけじゃあんまりメリットがないんだ。

Example-Driven Developmentは別の選択肢を提供するよ。テストから始めるんじゃなくて、基本的な例から始めるんだ。例を段階的に作り上げることで、何がその例を面白くするのかを定義する手助けになるんだ。例を開発するにつれて、自分が作る主張も自然に成長していくよ。

EDDでは、簡単な例から始めて徐々に洗練していける。EDDは、コードを反復的に構築して改善することを可能にするんだ。これにより、システムをより理解するために例を開発しながら、その挙動に関する必要な主張もできるようになるんだ。

#EDDにおけるライブプログラミングの活用

Glamorous Toolkitは、EDDをサポートする柔軟な開発環境なんだ。これにより、ユーザーが理解しやすいソフトウェアを作成できるんだ。目標は、技術的かつビジネス的な側面について簡単に答えを提供できるソフトウェアを作ることなんだ。

この環境では、ソフトウェア開発のプロセスがインタラクティブ。まず例から始めて、それを洗練させることで、例を探求しやすくするカスタムツールを作成することができるんだ。各テストケースが例を返すことで、開発プロセスがサポートされるんだ。

たとえば、異なる通貨での価格を管理するシステムを作りたいとする。100ユーロや10ドルみたいな金額を保持するクラスがあるんだ。今、これらの商品の価格を固定価格や割引価格として追加したい。

TDDを使うと、具体的な価格を指定し評価するテストメソッドを書くことになるけど、EDDでは価格の条件を定義してそれを返す例を作るんだ。必要なコードをすぐにプロトタイプして、さらに探求して洗練できるシンプルなインスタンスから始めるんだ。

例を形作ることで、私たちは作業しているオブジェクトに関する質問に答えるのを助けてくれるさまざまなメソッドやツールを作ることができるんだ。

#カスタムツールと可変開発

可変開発は、開発中に小さな分析ツールを追加して例を豊かにすることを可能にするんだ。これにより、例を扱うときに、ユーティリティやカスタムビューで強化できるんだ。

たとえば、Ludoのようなゲームでは、ゲームの現在の状態や行われた動き、時間の経過に伴うゲームの進行状況を表示するビューを作成できるんだ。これらのビューは、システム内のオブジェクトに関する特定の情報を提供するためにデザインされるんだ。

Ludoゲームでは、プレイヤーの動きやゲームボードの現在の状態など、さまざまな側面をチェックできるんだ。このアイデアは、開発中にカスタムビューがシステムの挙動を明確にする手助けをすることなんだ。

#ソフトウェアを説明可能にする

例を使うことの一番ワクワクする点の一つは、それがライブドキュメントに組み込まれることができるってことなんだ。情報をより理解しやすく提示できるようになるんだ。これにより、継続的な学習をサポートする魅力的なドキュメントを作ることができる。

たとえば、ドキュメントページでゲームの仕組みを説明することができるんだ。動きやルール、インタラクションの例を提供することができる。例やライブスニペットをドキュメントに組み込むことで、ユーザーは実際の文脈で全てがどのように結びついているかを見ることができるんだ。

ゲームのルールに加えて、ライブドキュメントはプログラミングの概念やアルゴリズムを説明するのにも役立つんだ。関連する例を提供することで、ユーザーがプログラムやレイアウトアルゴリズムの動作をインタラクティブに探求できるようにするんだ。

#様々な環境でのEDDの応用

EDDは多くのプログラミング環境で適用できるよ。これを実現するには、テストが例を返すことをサポートするテストフレームワークが必要なんだ。テスト内で例を再利用しやすくなければならないんだ。テストランナーは、テストがオブジェクトを生成することを認識して、それらのオブジェクトを楽にナビゲートできるようにする必要があるんだ。

コードをプロトタイプするインタラクティブなシェルを持つことも、体験を向上させるんだ。こうすることで、開発者は厳格な構造に従わずに、使える例につながるコードスニペットを試すことができるんだ。

最後に、可変開発を可能にするツールを持つことで、プロセスが本当に向上するんだ。これにより、作業するオブジェクトに基づいてツールを適応させ、その能力を動的に拡張することができるんだ。

#結論

要するに、EDDは開発を新しい見方で見るための手段を提供するんだ。プロセスを伝統的なテストの代わりに例を中心にすることで、テスト可能でありながら、さらに明確で魅力的なソフトウェアを作ることができるんだ。このアプローチは、ソフトウェアシステムをより良く説明することも可能にして、ユーザーがそれを追いやすく、理解しやすくなるんだ。ドキュメントが開発プロセスの自然な結果として常に更新されると、ソフトウェアの全体的な品質が向上するんだ。

EDDを使うことで、効果的かつ明確な方法でソフトウェアを構築する新たな可能性が開かれ、最終的には理解しやすく、保守しやすいシステムにつながるんだ。