認知負荷の最小化の概要
ユーザーは、ライブラリを使用する前に、その機能と抽象化についてのメンタルモデルを迅速かつ正確に構築する必要があります。 これを達成するための最善の方法は、ユーザーが遭遇する複雑さの量を最小限に抑えることです。
認知負荷を最小化するための戦略には、以下のようなものがあります。
- 簡潔さ (Simplicity): 既存の Kotlin の型や構造を再利用して冗長性を避け、最小限のコンポーネントで最大限の機能を提供する API を目指します。可能な限り、少数のコアとなる抽象化を作成し、その上に付加的な機能を構築してください。
- 可読性 (Readability): コードの意図を明確にするために、API を宣言的なスタイルで記述します。新しい名前を考案することがどうしても必要な場合を除き、抽象化の名前は問題ドメインから直接選択してください。基本的なデータ型は、その本来の目的に合わせて使用します。コア機能とオプション機能を明確に区別してください。
- 一貫性 (Consistency): API のあらゆる設計側面において、単一かつ明確なアプローチを維持します。オブジェクト指向か関数型かに関わらず、命名規則、エラー処理戦略、およびパターンを統一してください。
- 予測可能性 (Predictability): 「最小驚きの原則」 (principle of least surprise) に従うようにライブラリを設計します。デフォルトの設定が最も一般的なユースケースに一致するようにし、ユーザーが最もシンプルで短いコードでタスクを完了できるようにします。一貫性と予測可能性を維持するため、ライブラリの拡張は明確に指定された方法でのみ許可してください。
- デバッグのしやすさ (Debuggability): 情報の抽出やネストされた関数呼び出しのナビゲーションを容易にすることで、ユーザーのトラブルシューティングを支援するようにします。例外がスローされる際、例外の型と内容の両方が根本的な問題と一致し、問題を効果的に診断して解決するために必要なすべての詳細を提供する必要があります。ドメインオブジェクトの状態をキャプチャして出力したり、中間表現を表示したりできるようにすべきです。
- テストのしやすさ (Testability): ライブラリ自体、およびそれを使用するコードが、容易にテスト可能であることを確認してください。
以下のセクションでは、Kotlin でこれらの戦略を実装する方法について詳しく説明します。
次のステップ
これらの戦略を詳細に検討するために、まずは次のセクションで「簡潔さ」について学ぶことから始めることができます。