モールド可能な開発:ソフトウェアの洞察を簡素化する
モールド開発がカスタムツールでソフトウェアの理解をどう変えるかを学ぼう。
― 1 分で読む
モールド開発は、ソフトウェアを理解しやすくするのを助けるんだ。開発者がソフトウェアに関する特定の質問に答えられるカスタムツールを作れるようにすることで、これを実現してる。このアプローチは、ユーザーがソフトウェアの内部の仕組みをインタラクティブに探索できる、より説明可能なシステムを生み出す。
はじめに:モールド開発の概要
ソフトウェアシステムには、開発者も普通のユーザーも助ける知識がたくさん詰まってる。でも、その知識にアクセスするのは結構難しいんだ。ソースコードや実行中のシステムとかの典型的なリソースは、明確な答えを提供してくれないことが多い。ドキュメントも古かったり、不完全だったりするし。
ソフトウェア分析ツールも役に立つけど、通常は各システムがユニークだから、あまりうまくいかないことが多い。しばしば、開発者はシステムが何をしているのか、どう機能しているのかを理解するのに多くの時間を費やしてる。これはソフトウェア開発における大きなコストなんだ。
この状況を改善するために、モールド開発は自分自身の質問に答えられるシステムを作り出す。カスタムツールを簡単に追加できるようにすることで、ユーザーが探索できるダイナミックなソフトウェアモデルを作り出す。これらのツールには、インスペクタ、コードエディタ、デバッガ、ノートブックなどの機能が含まれることがある。
例えば、ルドーみたいなゲームでは、単にソースコードを見るんじゃなくて、開発者がゲームに関する特定の質問をするためのカスタムビューを作って、簡単に答えを得ることができる。実際に行われた動きを視覚化したり、現在のゲーム状態を見たり、ゲームをより理解しやすくインタラクションできる。
モールド開発パターン
モールド開発は、一緒に働く一連のパターンに分けられる。これらのパターンは、こういったシステムを作成するためのフレームワークを提供する。
ツールパターン
これらのパターンは、簡単に作成して使用できるカスタムツールを構築することに焦点を当ててる。
モールドツール
既存のツールが特定のドメインのニーズに合わない場合、モールドツールを開発することができる。複雑なプラグインを作る代わりに、モールドツールは実行時にカスタマイズを可能にする。例えば、テストランナーは一般的な命名規約やアノテーションに基づいてテストケースを自動的に特定できるから、ドメインに特化したテストを実行するのが楽になる。
コンテクストプレイグラウンド
モールドツールを使用するとき、コンテクストプレイグラウンドはソフトウェアエンティティをインタラクティブに探る方法を提供する。この環境では、ユーザーは異なるツールに切り替えることなく、小さなコードスニペットを書いたりテストしたりできる。例えば、Pythonアプリケーションでは、プレイグラウンドを使ってユーザーがオブジェクトのライブインスタンスを操作したり、アイデアをテストしたりできる。
カスタムビュー
カスタムビューは、ドメイン情報を効果的に提示するのを助ける。重要な詳細を強調しない一般的なビューではなく、開発者は特化したビューを作成できる。ルドーゲームを例にすると、各プレイヤーの動きを示すカスタムビューを作ることで、ゲームの現在の状態を理解しやすくする。
カスタム検索
複雑なドメインモデルでは、エンティティ間のナビゲーションが面倒になることがある。カスタム検索機能を使えば、ユーザーは異なる基準に基づいてエンティティをすばやく見つけられる。例えば、アドレス帳アプリケーション内では、特定の連絡先や住所を検索できて、効率が上がる。
カスタムアクション
繰り返しのタスクに対して、カスタムアクションは実行を簡素化する。同じコードスニペットを繰り返し実行するのではなく、開発者はモールドツール内で共通のアクションを1つのボタンクリックにまとめることができる。これによってプロセスが合理化され、エラーの可能性が減る。
組み合わされたナラティブ
ソフトウェアシステムを説明するのは時に難しいことがある。組み合わされたナラティブは、さまざまなビューを結合して一貫したストーリーを作り、特定の機能や問題を理解するのを助ける。複数のステップを通じて、ユーザーはシステムをナビゲートしたり、問題をトラブルシュートする方法を効果的に見ることができる。
モデリングパターン
これらのパターンは、ドメインエンティティをよりよく構造化して理解やクエリを向上させることに焦点を当てている。
モールドオブジェクト
モールドオブジェクトは、開発者がインタビューできるドメインエンティティのライブインスタンスだ。伝統的なテキストエディタでコードを書く代わりに、開発者はライブオブジェクトとインタラクションして質問をし、洞察を得ることができる。この探索プロセスを通じて、理解を深めるカスタムツールを作成できる。
例示オブジェクト
例示オブジェクトは、システムの特定の状態や振る舞いを示す具体的なインスタンスだ。テストやドキュメントに役立ち、開発者が機能をすぐに参照したり、デモしたりするのを可能にする。
モールドデータラッパー
既存のデータで作業する際、モールドデータラッパーを適用することで、データの管理が容易になる。生のデータ構造を扱うのではなく、開発者はドメインの概念をよりよく表す専用クラスでデータをラップできる。これによって、データの解釈を反映したカスタムビューやアクションを作成することができる。
コレクションラッパー
モールドデータラッパーと似て、コレクションラッパーはドメインオブジェクトのグループを扱う。これにより、コレクションにカスタムツールを適用でき、ナビゲーションや探索の能力が向上する。
プロセスパターン
プロセスパターンは、モールド開発に関わるタスクを整理し管理する方法をガイドする。
プロジェクトダイアリー
プロジェクトダイアリーを保持することで、進捗、決定、実験を追跡するのを助ける。プロジェクトが完了した後にドキュメントを作成するのではなく、開発者はライブノートブックを使って自分の旅を記録できる。このアプローチは、将来の開発努力を向上させる変更や決定の履歴を維持することを可能にする。
ツール構築
モールド開発を始める前に、基本的なツールを設定する必要があるかもしれない。特定のフォーマット用のパーサーや他のシステムへのブリッジなどが含まれることがある。最初にこれらのツールに投資することで、実際の開発プロセスを迅速化できる。
ブラインドスポット
システムの「ブラインドスポット」を特定することは重要だ。これらは、利害関係者が理解したり監視したりするのが難しい領域だ。これらのブラインドスポットに焦点を当てることで、開発者は洞察を提供するツールを作成し、利害関係者がモールド開発の価値を見るのを助けることができる。
シンプルビュー
カスタムビューを開発する際、シンプルに始めることが鍵だ。必要な情報を伝えるビューを作ることで、効率が上がる。後でより複雑さが必要になったら、拡張を行える。
捨てる分析ツール
時には、評価やバグ調査中に、迅速なカスタムツールが役立つことがある。こういった捨てるツールは、再利用可能なコンポーネントが必要ない特定の問題に対して即座に洞察を提供するために開発できる。
結論
モールド開発は、ソフトウェアシステムをより説明可能で探索しやすくする方法を提供する。プロセスを理解しやすいパターンに分解することで、開発者はプロジェクト内の特定のニーズに対処することに集中できる。ユーザーのニーズに適応するカスタムツールでこれらのシステムを継続的に進化させることで、ソフトウェアは技術的な利害関係者と非技術的な利害関係者の両方にとってよりアクセスしやすくなる。
タイトル: Moldable Development Patterns
概要: Moldable development supports decision-making by making software systems explainable. This is done by making it cheap to add numerous custom tools to your software, turning it into a live, explorable domain model. Based on several years of experience of applying moldable development to both open-source and industrial systems, we have identified several mutually supporting patterns to explain how moldable development works in practice. This paper targets (i) readers curious to learn about moldable development, (ii) current users of the Glamorous Toolkit moldable IDE wanting to learn best practices, and (iii) developers interested in applying moldable development using other platforms and technology.
著者: Oscar Nierstrasz, Tudor Gîrba
最終更新: 2024-09-27 00:00:00
言語: English
ソースURL: https://arxiv.org/abs/2409.18811
ソースPDF: https://arxiv.org/pdf/2409.18811
ライセンス: https://creativecommons.org/licenses/by-sa/4.0/
変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。
オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。
参照リンク
- https://www.micahsmith.com/blog/2021/02/sharing-a-preprint-using-acmart/
- https://www.europlop.net
- https://gtoolkit.com
- https://pharo.org
- https://web.archive.org/web/20240523010248/
- https://www.jetbrains.com/help/idea/customizing-views.html
- https://web.archive.org/web/20240413225707/
- https://www.jetbrains.com/help/writerside/custom-search-service.html
- https://web.archive.org/web/20240916005104/
- https://en.wikipedia.org/wiki/Narrative
- https://api.github.com/orgs/feenkcom
- https://www.lifeware.ch
- https://web.archive.org/web/20231213144857/
- https://book.gtoolkit.com/adding-simple-list-views-for-ludo-players--3g9kpmxty3fj9eev3ucmqkztc
- https://hillside.net/plop/2013/papers/proceedings/papers/cunningham.pdf
- https://web.archive.org/web/20240917092258/
- https://en.wikipedia.org/wiki/Zettelkasten
- https://web.archive.org/web/20240820082136/
- https://docs.jupyter.org/en/latest/
- https://docs.jupyter.org/
- https://roamresearch.com
- https://lepiter.io/feenk/steering-agile-architecture-by-example--th-e2p6aps2brbby94deek31xqxh/
- https://web.archive.org/web/20240430071604/
- https://jupyterbook.org/en/stable/interactive/interactive.html
- https://xkcd.com/1319/