忘记 MVC，我希望 MS 能够为常规 .Net 库生成像样的文档。 从我记事起，微软的文档就几乎无法使用； 近乎垃圾。
我时常会不小心按下 F1 并浏览 MSDN 文档。 和往常一样，几分钟后我意识到谷歌更快。
作为示例，只需看看找到日期时间字符串格式字符需要多长时间。
我认为大多数第三方供应商都遵循这一事实。
Forget MVC, I would like MS to produce decent documentation just for the regular .Net libraries. For as long as I can remember Microsoft documentation has been barely usable; bordering on crap.
Every so often I accidentally hit F1 and go spelunking through the MSDN documentation. And, as always, after a couple minutes I realize that google is faster.
As an example, just see how long it takes you to locate the datetime string format characters.
I think this fact has carried on to most third party vendors.
始终缺乏有效的文档。 ASP.NET MVC 可能就是一个例子，但它在 Java 世界中也好不了多少。 是的，Javadoc 参考资料可以在线获取，但许多条目都是琐碎的文本或占位符文本。 一般来说，API 参考文档不足以解释如何在应用程序设计的上下文中最好使用每个给定的类和方法。
Different types of documentation are appropriate (and necessary) for different usage.
When you need the broad scope of how to use a technology, a video can give you the 10,000ft view of its capabilities. But these rarely show readable examples of API usage.
When you need to put together a basic project using that technology, a step-by-step tutorial is good. But these don't show you exotic cases or best practices; they show only one scenario of using the technology.
When you need to learn best practices for designing a solution with that technology, or ways to integrate with other technology, then task-oriented documentation is best.
When you're mostly familiar with the technology but you just need a reference for method signatures and such, then API docs are appropriate. These may be integrated into an IDE.
There is always a dearth of effective documentation. ASP.NET MVC may be one example, but it's not much better in the Java world. Yes, Javadoc reference material is available online, but many entries are trivial or placeholder text. API reference docs in general are inadequate to explain how best to use each given class and method in the context of application design.
发布评论
评论（2）
忘记 MVC，我希望 MS 能够为常规 .Net 库生成像样的文档。 从我记事起，微软的文档就几乎无法使用； 近乎垃圾。
我时常会不小心按下 F1 并浏览 MSDN 文档。 和往常一样，几分钟后我意识到谷歌更快。
作为示例，只需看看找到日期时间字符串格式字符需要多长时间。
我认为大多数第三方供应商都遵循这一事实。
Forget MVC, I would like MS to produce decent documentation just for the regular .Net libraries. For as long as I can remember Microsoft documentation has been barely usable; bordering on crap.
Every so often I accidentally hit F1 and go spelunking through the MSDN documentation. And, as always, after a couple minutes I realize that google is faster.
As an example, just see how long it takes you to locate the datetime string format characters.
I think this fact has carried on to most third party vendors.
不同类型的文档适合（且必要）不同的用途。
当您需要广泛了解如何使用某项技术时，视频可以为您提供 10,000 英尺范围内的功能视图。 但这些很少显示 API 使用的可读示例。
当您需要使用该技术构建一个基本项目时，分步教程会很好。 但这些并没有向您展示奇异的案例或最佳实践；而是向您展示一些特殊的案例或最佳实践。 它们仅展示了使用该技术的一种场景。
当您需要学习使用该技术设计解决方案的最佳实践或与其他技术集成的方法时，面向任务的文档是最好的选择。
当您非常熟悉该技术，但只需要方法签名等参考时，API 文档就适合。 这些可能会集成到 IDE 中。
始终缺乏有效的文档。 ASP.NET MVC 可能就是一个例子，但它在 Java 世界中也好不了多少。 是的，Javadoc 参考资料可以在线获取，但许多条目都是琐碎的文本或占位符文本。 一般来说，API 参考文档不足以解释如何在应用程序设计的上下文中最好使用每个给定的类和方法。
Different types of documentation are appropriate (and necessary) for different usage.
When you need the broad scope of how to use a technology, a video can give you the 10,000ft view of its capabilities. But these rarely show readable examples of API usage.
When you need to put together a basic project using that technology, a step-by-step tutorial is good. But these don't show you exotic cases or best practices; they show only one scenario of using the technology.
When you need to learn best practices for designing a solution with that technology, or ways to integrate with other technology, then task-oriented documentation is best.
When you're mostly familiar with the technology but you just need a reference for method signatures and such, then API docs are appropriate. These may be integrated into an IDE.
There is always a dearth of effective documentation. ASP.NET MVC may be one example, but it's not much better in the Java world. Yes, Javadoc reference material is available online, but many entries are trivial or placeholder text. API reference docs in general are inadequate to explain how best to use each given class and method in the context of application design.