工具与资源about.sourcegraph.com
一位前谷歌员工的开发工具指南
An ex-Googler’s guide to dev tools
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章由前 Google 工程师撰写，系统梳理了 Google 内部开发工具（如代码搜索、Blaze/Bazel、代码评审、监控等）与开源界对应工具的对照，帮助离开 Google 的工程师在外部世界找到替代品。文章在 2020 和 2022 两次登上 HN 首页，作者后来还补充了对行业变化的观察。
为什么经久不衰：它把 Google 内部工具链与开源替代品一一对应，是理解大型工程基础设施演进和开发者工具生态的经典参考。
HN 评论精选
Google 内部工具并非全面领先，部分已显陈旧，只是惯性使其延续。
也许关键在于"很多年前"。我现在在 Google 工作，之前在 Square，总体上我更偏好 Square 的开源和现成工具。有些东西确实 Google 更好（代码搜索和 Blaze 明显更强），但很多监控和 CI 工具显得陈旧、堆满难以理解的杂物。比如 Gerrit，每个变更居然有 3 种不同的 ID，而且不知为何所有工作流状态都用 [-2, 2] 范围内的整数表示。这些工具当年可能很出色（也更简单），但世界已经前进了，我们却被熟悉的东西束缚着。
tdeck查看英文原文
> Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting impression on me. Perhaps the operative phrase being "Many years ago". I currently work at Google, previously I worked at Square. Of the two, I generally prefer the OSS and off-the-shelf tooling at Square. Some things really are better at Google (code search and Blaze are definitely a big improvement over what we had), but many of our monitoring and CI tools feel antiquated and cluttered with inscrutable debris. Or take Gerrit, where each change has 3 different IDs and the developers decided that every workflow status should be expressed as an integer in the range [-2, 2] for some reason [1]. They were probably amazing (and much simpler) tools back in the day, but the world has moved and we're somewhat constrained by what's familiar. [1]: https://gerrit-review.googlesource.com/Documentation/images/user-review-ui-change-complex-reply-dialogue.png
Monorepo + 代码搜索让 API 作者能看到所有用法，这是 Google 开发效率的核心优势。
（Google 员工）文章对工具的描述很到位。有一点可能不明显：对 API 作者来说，代码搜索加上 monorepo 和 Google 代码库这个相对封闭的宇宙，能立即看到一个库的所有使用场景——知道什么有效什么无效，从而支持高效重构；写客户端时也能快速从其他客户端代码中学会正确用法。如果开源世界也能做到类似的事（跨仓库索引依赖某库的代码），就能实现类似的系统性改进，可惜除了少数利基场景外似乎不现实。
burakemir查看英文原文
(Googler here) The article is a good description of the tools, and I was not aware of the blaze clones plz and pants. One thing that is maybe not obvious: For an API author, code search in combination with a monorepo and the somewhat hermetic universe which is Google's code base provides immediate access to all uses of a library. You can see what worked well and what didn't, and it enables effective refactorings. That also means when writing a client, you can quickly figure out from other client code how stuff is supposed to be used. All this makes code search such an effective tool in Google's development environment (in the broader sense). If anything like this were possible for open source (indexing code that depends on a library/API, across subrepos in any version control system, in a way that gets near complete coverage), it would enable similar possibilities of systematic improvement. Alas, it does not seem realistic except in a few niches where the number of clients is bounded and code owners are willing and able to follow a protocol (approve changes to their code that unblock such global improvements.)
Google 的日志处理和 Dremel 查询系统规模惊人、体验出色。
对我来说，日志处理系统和 Dremel 是我工程师生涯中见过的最惊艳的工具。数百万台机器每天产生数万亿条日志，而 Dremel 无需索引就能在几分钟内（简单查询几秒内）对这些记录执行任意查询。
summerlight查看英文原文
For me, logs processing system and Dremel were probably the most marvelous tools that I've ever seen in my SWE career. Millions of machines are producing trillions of logs records everyday. Then Dremel runs some arbitrary query over those records in an order of minutes (seconds for simple queries), without indexing.
作者回顾：代码搜索和开发工具已从 Google 特有走向主流。
（作者）补充一些世界的变化：1. 代码搜索更主流了，以前销售主要靠怀念它的前 Googler，现在更多来自 struggling with 大代码库的团队；2. 开发工具投资持续加速；3. Bazel 采用率增长，今天我会加上 monorepo 工具一类；4. Kubernetes 仍是容器编排霸主，但 serverless 和托管服务在增长。
beyang查看英文原文
Author of the post here. Thought it might be of interest to call out some observations about how the world has changed since I wrote this: 1. Code search is more mainstream. It used to be most of Sourcegraph's sales came from ex-Googlers missing code search, but nowadays, most of our new revenue originates from dev teams just struggling with the challenge of big codebases. 2. Investment in dev tools has only accelerated. A lot of pandemic beneficiaries (virtual events, tele-medicine, at-home exercise equipment, crypto) are now reversing, but dev tools growth continues to be strong. 3. Bazel adoption has grown. Were I writing the post today, I would have had a category for monorepo tooling that included companies like EngFlow and Turborepo. 4. Kubernetes is still dominant for container orchestration, but serverless and managed services seem to be gaining more adoption. Classic tension between customer focus and open standards—will be interesting to see how we trade off dev-ex vs proprietary platform dependency. Since this post was first published, we've also made a lot of advances at Sourcegraph and are looking for people who want to play around with some new experimental search and code intel features. Come say hi in our Discord! https://discord.gg/SSCBGByJeu
历次讨论
同类还值得读
直接在浏览器中启动 Linux 内核
Boot a linux kernel right inside your browser.
Fabrice Bellard 的 JSLinux 页面，用 JavaScript 在浏览器里启动一个 Linux 内核，并提供一个可交互的终端环境。
工具与资源上首页 5 次 · 2011–2025bellard.orgHacker News 未公开功能与行为清单（2018）
A List of Hacker News's Undocumented Features and Behaviors (2018)
数据科学家 Max Woolf 整理的 Hacker News 未公开功能与行为清单，涵盖投票机制、排名算法、账号惩罚等社区运作细节。
工具与资源上首页 5 次 · 2019–2025github.comMapSCII：在终端中用盲文和 ASCII 渲染地图
MapSCII – Braille and ASCII map renderer for the console
MapSCII 是一个在命令行终端里渲染地图的开源工具，用盲文字符和 ASCII 字符把地理数据画成可交互浏览的字符地图。
工具与资源上首页 5 次 · 2017–2025github.com顶尖大学的免费在线课程
Free Online Courses from Top Universities
Open Culture 整理的一份免费在线课程合集，汇集了全球顶尖大学（如 MIT、斯坦福、耶鲁等）向公众开放的网络课程资源，涵盖音频、视频等多种形式。
工具与资源上首页 5 次 · 2010–2022openculture.com淘气字符串：容易引发用户输入问题的字符串清单
Naughty Strings: A list of strings likely to cause issues as user-input data
一个 GitHub 仓库，收录了大量容易让程序出问题的用户输入字符串，如特殊字符、emoji、SQL 注入片段、系统命令等，供开发者用于测试输入处理逻辑。
工具与资源上首页 4 次 · 2015–2020github.com