如何避免西西弗斯式搬砖（我已经搜过无数次 URL 正则怎么写了，这是浪费生命

[josherich]

在搬砖日常中，不知道大家是否经常有这样的困扰，为了使用一个函数将整个库引入，造成依赖过多，甚至滥用，以至于 npm 生态形成了一种依赖滥用的习惯，left-pad 事件是这种现象的一个侧面。

有些函数，其功能非常 pure，例如浏览器 URL 的处理函数，通常的做法是在 Stack Overflow 找一些现成的实现。举一个例子，以下代码可以得到一个 URL Query 字典：

function getQueries() {
  let options = {};
  if (window.location.search) {
    options = decodeURIComponent(window.location.search.slice(1))
      .split('&')
      .reduce(function _reduce(a, b) {
        b = b.split('=');
        a[b[0]] = b[1];
        return a;
      }, {});
  }
  return options;
}

按照常识，这是有最佳答案，即一个已解决的问题（当然，目前主流浏览器中可以使用 URLSearchParams，但仍需要 polyfill https://caniuse.com/#feat=urlsearchparams ），而不是一个应在 Stack Overflow 搜索的问题。

出于对代码库透明性的追求，我倾向避免使用细碎的依赖，建立自己的 Util 库。但碰到类似以上举例的新问题时，往往仍需要求助于搜索引擎，而搜索引擎指向的 SO 问答或者博客质量参差不齐，需要自己的甄别。

请问大家是如何解决这一问题，或者有哪些平台已经解决了这个问题？

如果没有，我想这是一个不错的点子。

[LxExExl]

能直接拿来用的存在笔记里
否则搜一下又不会死 反正经常搜 搜起来也挺快的

[doublleft]

很多人想做过这个，我也做过，但是内容太难搞

[josherich]

@LxExExl 对个体确实是这样，但对某个已解决的问题来说，每时每刻都有人都在重复这一搜索，找最优答案的过程。

[josherich]

@doublleft 生产内容是困难的，这是一个 UGC 的常见问题（最近看到 Stack Overflow Documentation 失败的案例 https://meta.stackoverflow.com/questions/354217/sunsetting-documentation，即使有如此优秀的社区加持，依然无法克服这个难题）
因此显然需要一个发现或自动生成的机制，用 github、gist 或 npm 的数据来做启动，Sourcegraph 等工具可以实现代码库的搜索（例如在 React 中搜索 Object.assign https://sourcegraph.com/search?q=repo:github.com/facebook/react+Object.assign&sq= ）。

[LxExExl]

@josherich 但是每个人的问题其实都"不太"一样. 即使是一个函数, 也得"多态"一下, 所以...

[josherich]

@LxExExl 的确，SO 的提问回答模式很好的解决了「问题经常不太一样」，其实 SO 中经常会有问题之间的链接和重定向，也存在大量已经过时的高票回答，需要去阅读回答中的评论，我经常遇到评论中指出此方法已经失效并给出新的方法。显然结构化的需求是存在的，每种编程语言及其生态中都存在很多标准库无法解决，同时又存在标准答案的问题