如何找到合适的API功能审核人员？
我们正在开发一个提供API接口的产品，以便其他开发者可以使用主产品的一些功能。
这已经实施并记录在案。
但我不确定这是否非常有用，并且文档对于开发人员来说非常清晰。
我们如何找到人来评论这个功能？ 应该是什么样的人？
从某种意义上说，我们正在寻找单个功能/组件的产品负责人。 是否可以？
We are developing a product which provides an API interface, so other developers can use some functionality of main product.
This is already implemented and documented.
But I'm not sure that this is very useful, and documentation is very clear for developers.
How we can find people to review this feature?
What type of person should it be?
In some sense, we're looking for Product Owner for single feature/component. Is it possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
最好找到一个已经为相关语言设计了一些已知框架的程序员。
我认为你的用户认为什么是无关紧要的，因为你不能通过询问任意程序员对框架的看法来判断框架。 他的答案将取决于他的知识水平和个人方法，而 API 是为更广泛的人群设计的（我假设这就是您的情况）。 为了完成这一点，在我公司中使用 VB.NET 的程序员认为 C# 是蹩脚的语言，因为存在一些“问题”，比如你不能在 C# 中编写 Button = "Text" 并让编译器自动为你找到默认属性。 你不希望这样的人来评判你的框架。
即使是具有不同语言经验的设计人员也可能会有所帮助，因为更广泛使用的 API 应该在人们已经熟悉的众所周知的编程模式的帮助下实现。
It would be the best to find a programmer that has already designed some known framework for the language in question.
WHat your users think is irelevent I think, becuase you can't judge about framework by asking arbitrary programmer his toughts about it. His answer will depend upon his level of knowledge and personal methodologies while API is being designed for wider population (I am assuming this is your case). To finish this point, in my firm programmers that use VB.NET think that C# is lame language becuase of 'problems' like you can't write Button = "Text" in C# and let the compiler automatically find default property for you. You don't want such person judging your framework.
Even designers experienced in different languages may be of help because wider used APIs should be implemented with the help of well known programming patterns people are already familar with.
让对您的产品没有经验的人为您的 API 制作一些示例代码或客户端的参考实现。 然后他们就会很好地了解文档的不足之处或 API 需要改进的地方。 这可以是承包商，也可以是新的开发人员（让他们加快速度的好方法）。
Get someone who's not experienced with your product to make some sample code or a reference implementation of a client for your API. Then they'll get a good sense of where the documentation is deficient or the API needs to be improved. This can be a contractor, or a new developer (good way to get them up to speed).
首先，如果您正在开发供其他人使用的 API，我建议您阅读以下书籍： http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321545613
遵循这些规则将在需要进行任何审查之前避免界面出现大量可用性问题。
其次，与一些目标开发人员进行可用性研究，这些开发人员可能会使用此 API，但以前从未见过它。 将他们放在系统前面并给他们一些任务，然后观察他们如何弄清楚如何去做。 他们的痛点会告诉你哪里需要改进。
First, if you're developing an API for use by others, I'd recommend reading a book like: http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321545613
Following those rules will avoid a large number of usability issues with your interface before any review is necessary.
Second, run a usability study with a few target developers, those who're likely to make use of this API, but haven't ever seen it before. Put them in front of the system and give them a few tasks, then watch how they go about figuring out how to do it. Their pain points will tell you where you need to make improvements.
调查您的最终用户并找出哪些用户正在使用您的 API 与您的软件进行交互。 然后，您可以对这些用户进行调查，了解他们对 API 中提供的各种功能以及文档的易用性和清晰度的看法。
Poll your end users and find out which ones are using your API to interact with your software. You can then survey those users and get their opinions about the various features you offer in your API along with the ease of use and clarity of your documentation.
每个 API 都有一些目标受众（即开发与您的产品集成的客户）。 从这个角度来看，最好能从观众那里得到反馈。 您可以建立一些早期访问计划，或者发布一些公共测试版。
如果您没有这样的受众（即您正在为尚未公开的产品开发 API），我建议您进行一些“可用性测试” - 即选择一位具有大约目标受众技能的开发人员并给他一些任务涉及到API的使用。 然后从他那里得到反馈。
Every API has some target audience (i.e. clients developing integrations to your product). From this point of view it would be the best to get the feedback from members of this audience. You can establish i.e. some early access program, or ship some public betas.
If you have no such audience (i.e. you are developing API for a product, which is not yet public), I would suggest to do some king of 'usability testing' - i.e. pick a developer of approximately target audience skill and give him some assignment involving the API usage. Then get a feedback from him.
如果我处于您的位置，我会开始编写示例应用程序，并进行演示以引导人们完成这些步骤或进行其他类似的练习。 它不如从用户那里得到反馈，但它可以解决一些问题。
另一个（可能是坏的）想法是在 elance/guru 网站上花钱，并提出一个您认为代表用户将如何使用 API 的示例应用程序/功能。 为此制定项目，然后作为项目的一部分从开发人员那里获得反馈。
您可能需要能够用您的母语进行交流的人...
顺便说一句，等到所有内容都记录下来并实施可能不是审查它的最佳时机...这样做会好得多实施前审查。
If I were in your shoes I would start writing sample applications and either doing a presentation to walk people though the steps or some other similar exercise. It is not as good as getting feedback from users, but it can shake out some issues.
Another (possibly bad) idea is to spend money on the elance/guru sites and come up with a sample application/functionality you think is representative of how users are going to use the API. Make the project for that and then also get feedback from the developers as part of the project.
You'll probably want people who can communicate in your native tongue...
By the way, waiting until it is all documented and implemented is probably not the best time to review it... it would have been a lot better to do the review before implementation.