我的工作往往涉及使用其他地方的工具和库，而不是提供这些东西供外部消费。但是对于我们内部的工作，“文档”意味着提供简明扼要地列举其他人使用的功能的信息。根据习惯，我们倾向于生成看起来像UNIX手册页的内容，但我不会说我们认为这是最终的格式。
当谈到我们使用的（主要是.NET）库和工具时，这个级别的信息似乎非常稀疏，即使对于IDE中的“F1”类型帮助也是如此。
我们在评估准确，简洁的API（和类似的）参考资料方面是不寻常的吗？其他人容易找到吗？或者您在教程，演练和视频中找到了更多价值？
我认为这些东西将是第一个也是最容易制作的材料，因为它只是强制要求进行受控的开发和发布过程。
目前，这种恶化的一个很好的例子就是ASP.NET MVC，但我并不是说它特别引人注目，只是典型的。
答案 0 :(得分：1)
忘记MVC，我希望MS能够为常规.Net库生成合适的文档。只要我记得，Microsoft文档几乎无法使用;接近废话。
每隔一段时间我就不小心碰到了F1，然后开始浏览MSDN文档。并且，一如既往，几分钟后我意识到谷歌更快。
例如，只需查看找到日期时间字符串格式字符所需的时间。
我认为这个事实已经延续到大多数第三方供应商。
答案 1 :(得分：0)
不同类型的文档适合（和必要）用于不同的用途。
当您需要广泛的技术使用范围时，视频可以为您提供10,000英尺的功能视图。但这些很少显示API使用的可读示例。
当您需要使用该技术整理基本项目时，一步一步的教程是好的。但这些并没有向您展示异国情况或最佳做法;它们只显示了使用该技术的一种情况。
当您需要学习使用该技术设计解决方案的最佳实践，或者与其他技术集成的方法时，面向任务的文档是最佳的。
如果您对该技术非常熟悉，但只需要方法签名等参考，则 API文档是合适的。这些可以集成到IDE中。
总是缺乏有效的文档。 ASP.NET MVC可能是一个例子，但它在Java世界中并没有好多少。是的，Javadoc参考资料可在线获取，但许多条目都是微不足道的或占位符文本。 API参考文档通常不足以解释 best 如何在应用程序设计的上下文中使用每个给定的类和方法。