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