|
|
发表于 2023-3-10 13:48:15
|
显示全部楼层
|
文档的目的, 在于让之前没了解的人学习掌握, 所以关键在于guide docs, 而不是reference docs. 对于已经熟悉的人来说, reference docs就很足够了, 但是不熟悉的人, 或者想要快速上手的人, 他需要的是通过文档了解一个库的优点、缺点、适用场景、FAQ等. 当前开源项目的文档普遍不行, 这是开源的一个弊端. 我就是通过网上搜索别人的各种博客, 完整地看完了MP的官方文档, 搞不清楚看源码后, 才得以流畅使用它. 如果我是这个库的用户, 这和理想的状态相去甚远MP确实没有限制原本的方式, 但是它只是在某一种场景下能大幅提高效率. 如果只在某种场景下能提高效率(或者给出正确结果), 其他场景则非常麻烦或者没有正确的结果, 只能使用原生MyBatis, 那么使用MP的理由何在呢? 所以“强制的架构”是指它只在某种数据架构下能发挥其预期的效果我只是一个普通用户, 两周前我从来没听说过这个库. 如果不是项目统一要求, 我也不会用它. 但是我既然用它, 我习惯性地里里外外都了解清楚. 说实话, 如果MP的维护者看到这些, 他们应该会感到高兴, 有第一手的真实的用户反馈. 大厂的产品们都在用尽方法收集用户反馈. 很多人用了, 并没有去系统地看过官方文档, 也没有去探索过各种可能性, 都没有时间或者精力去发表自己遇到的问题. 或许有人发过一些千篇一律的博客, 抄几段简单情况的代码, 又有什么用呢? 我提到的问题, github的issue中都有人提过, 不过有些被忽略了, 有些人提个问题还战战兢兢, 生怕自己是小白, 惊动了大神. 我提了这些, 后面有人如果也有类似的情况, 他就会知道, 自己的项目是否适合MP, 提前避免哪些问题, 该怎么去解决. 所以我这个文章对于用户和维护者都是有利的, 并非一无是处 |
|
