API インターフェイスを提供する製品を開発しているため、他の開発者は主要な製品の一部の機能を使用できます。
これはすでに実装され、文書化されています。
しかし、これが非常に役立つかどうかはわかりません。ドキュメントは開発者にとって非常に明確です。
この機能をレビューする人をどのように見つけることができますか? それはどのようなタイプの人であるべきですか?
ある意味では、単一の機能/コンポーネントのプロダクト オーナーを探しています。出来ますか?
API インターフェイスを提供する製品を開発しているため、他の開発者は主要な製品の一部の機能を使用できます。
これはすでに実装され、文書化されています。
しかし、これが非常に役立つかどうかはわかりません。ドキュメントは開発者にとって非常に明確です。
この機能をレビューする人をどのように見つけることができますか? それはどのようなタイプの人であるべきですか?
ある意味では、単一の機能/コンポーネントのプロダクト オーナーを探しています。出来ますか?
まず、他の人が使用する API を開発している場合は、次のような本を読むことをお勧めします。
これらのルールに従うことで、レビューが必要になる前に、インターフェースに関する多数のユーザビリティの問題を回避できます。
次に、少数の対象開発者 (この API を使用する可能性が高いが、これまで見たことがない開発者) を対象に、ユーザビリティ調査を実行します。それらをシステムの前に置き、いくつかのタスクを与えてから、彼らがどのようにそれを行うかを理解する方法を観察します. 彼らの問題点は、どこを改善する必要があるかを教えてくれます。
エンド ユーザーを調査して、API を使用してソフトウェアを操作しているエンド ユーザーを特定します。次に、これらのユーザーに調査を行い、API で提供するさまざまな機能と、ドキュメントの使いやすさと明確さについて意見を得ることができます。
API のクライアントのサンプル コードまたは参照実装を作成するために、製品の経験がない人に依頼してください。そうすることで、ドキュメントのどこが不十分であるか、API を改善する必要があるかを把握できます。これは請負業者でも新しい開発者でもかまいません (彼らを最新の状態にするには良い方法です)。
すべての API には対象ユーザー (つまり、製品への統合を開発しているクライアント) がいます。この観点から、この聴衆のメンバーからフィードバックを得ることが最善です。アーリー アクセス プログラムを確立したり、パブリック ベータ版を出荷したりできます。
そのようなオーディエンスがいない場合 (つまり、まだ公開されていない製品の API を開発している場合) は、「ユーザビリティ テスト」の王様を行うことをお勧めします。つまり、ターゲット オーディエンス スキルに近い開発者を選び、彼に割り当てを与えます。 API の使用を含む。次に、彼からフィードバックをもらいます。
問題の言語の既知のフレームワークをすでに設計しているプログラマーを見つけるのが最善です。
あなたのユーザーが何を考えているかは無関係だと思います。なぜなら、任意のプログラマーにフレームワークについての意見を聞いてフレームワークについて判断することはできないからです。彼の答えは、API がより多くの人々のために設計されている間、彼の知識レベルと個人的な方法論に依存します (私はこれがあなたのケースであると仮定しています)。この点を締めくくるために、私の会社で VB.NET を使用するプログラマーは、C# で Button = "Text" を記述できず、コンパイラーにデフォルト プロパティを自動的に見つけさせるなどの「問題」があるため、C# は不十分な言語であると考えています。そのような人にあなたのフレームワークを判断してほしくありません。
さまざまな言語で経験を積んだ設計者でさえ、人々がすでに慣れ親しんでいるよく知られたプログラミング パターンの助けを借りて、より広く使用されている API を実装する必要があるため、役立つ場合があります。