HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    编程与软件工程danluu.com编辑精选

    单体版本库(Monorepo)的优势

    Advantages of monolithic version control

    3次上首页
    7年跨度
    473累计得分
    342条评论

    2015 — 2022,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    Dan Luu 的这篇文章论述了单体版本控制(monorepo)的优势:项目可以按最合理的方式组织,而不受版本控制系统强加的结构限制,同时还能减少依赖管理的开销。文章以 Google、Facebook、Microsoft 等大公司的实践为例,说明 monorepo 在大规模开发中的可行性。

    为什么经久不衰:monorepo 与多仓库之争至今仍是工程团队的热门话题,这篇文章提供了经过大公司实践检验的论据,多年后仍具参考价值。

    关键词 monorepo版本控制Git软件工程

    HN 评论精选

    Subversion 的子目录独立 checkout 能力实现了 monorepo 的灵活组织,令人怀念。

    这是我最怀念 Subversion 的地方——SVN 里仓库的子目录可以单独 checkout。我们公司 SVN 顶层按部门分目录,server 部门下有 payments、reports 等。比如一个程序员只需 checkout /server/payments/cc_storage 和 /server/reports/quarterly_tax,查看历史时只看到影响这些目录的提交,体验上就像独立仓库。而负责整个支付系统的程序员 checkout /server/payments 就能自动获得其下所有子项目。

    tzs查看英文原文

    > With a monorepo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way. Using a single repo also reduces overhead from managing dependencies. This is the major thing I miss about Subversion, and the fact that in Subversion a subdirectory in a repository can be checked out on its own. At the top level of our Subversion tree, there were 'web', 'it', and 'server' directories, reflecting the departments in the company (at least those departments that dealt with source code). In the 'server' directory, there were things like 'payments', 'reports', and 'support', for things like payment processing, reporting, and stuff to help the customer support people. So lets say we had programmer in the server department working on the credit card storage system, and on a script to make a quarterly tax report. That programmer would just have to check out /server/payments/cc_storage and /server/reports/quarterly_tax from the company Subversion repository. When he checks the history in either of those, he only sees commits that affected those directories or their subdirectories. It really is like they are separate repositories. Suppose another programmer is working on the whole payment system. He can check out /server/payments, and automatically gets cc_storage under that, but also order_processor, paypal_callback, cc_updater, and subscription_biller. I was in charge of the whole server department. So I could check out /server and have a copy of everything we did. The other programmers would usually save work in progress to a personal development branch, and so every morning I could update from the server, and then see what everyone had done the day before. I could do a quick review to check the less experienced programmer's work, and it also gave me what I needed to write a short note to my manager letting him know what the server department was up to and who we were progressing.

    连 Google 自己的对外项目也用多仓库,说明两种模式各有适用场景。

    反方论据是:Google 发起的外部项目如 Golang 和 Android 用的却是多仓库加 gerrit 的模式。两种模式各有利弊——你是想要一个不断变动、总得 rebase/merge 的巨型仓库,还是多个仓库加同步麻烦?两种都做过的我并不确定哪个更好,可能非常取决于具体项目。

    zdw查看英文原文

    The argument against this is that other external-to-Google-but-started-by-Google projects like Golang and Android use the multirepo model, with gerrit. There are pros and cons to each - do you want to have a hugely churning "I always have to rebase/merge" repo under you, or multiple repos and trouble keeping them in sync? Having done both, I'm not sure which is better - it's probably very project specific.

    monorepo 并非新潮概念,而是大公司历史遗留加工具投入的结果,多仓库配好工具同样可行。

    我觉得有点好笑,monorepo 现在竟成了新潮事物。很多开发者是 git 出现后入行的,忘了不久前我们用 monorepo 是因为别无选择——多仓库的工具当时根本不存在。微软、Google、Facebook 正因赶上了那个年代,才构建了大量工具让 monorepo 可行。但如果有同样先进的工具支持,多仓库也有很多优点,扩展性也不错。

    shados查看英文原文

    I always find it a bit funny how monorepos are now this big exotic new age thing. "Monorepos are the future!". That very well may be, but I think we're at a point where the majority of developers started after git came out (since the industry experienced explosive growth just in the last few years). They kind of forget (or didn't know) that it's not that long ago we did monorepos because we HAD to. The tooling to do a system in multi-repos was just not there. It wasn't practical. Companies like Microsoft, Google and Facebook predates the days where building your company on top of 3000 repos was practical, and they certainly were not going to convert everything if they could help it. Thus, they built an enormous amount of tooling to make it work. It certainly has benefits (and tradeoffs). With similarly advanced tooling to support you, multiple repos also has a lot of very nice properties and scale quite nicely. To each their own.

    monorepo 好坏取决于版本控制工具能否高效处理部分检出,Perforce 与 Git 用户结论相反但都合理。

    很简单:monorepo 让你总能拿到需要的一切,外加一堆不需要的东西。是否划算取决于'拿不到所需东西'的代价是否大于'多拿一堆无用东西'的代价。只要系统能高效地选取小子集,后者的代价几乎为零。Perforce 擅长这个,Git 不擅长。所以用 Perforce 的人觉得 monorepo 好,用 Git 的人不觉得,而且双方都对。

    lisper查看英文原文

    It's very simple: with a monorepo you always have access to everything you need, together with a ton of stuff you don't. Whether or not this is advantageous boils down to whether the cost of not having access to something you need is greater than the cost of having access to a bunch of stuff you don't. As long as your system is reasonably efficient at letting you select small subsets of everything you could potentially have access to, the cost of having access to a bunch of stuff you don't need is essentially zero. Perforce is good at that. Git isn't. So people who use Perforce tend to think that monorepos are good and people who use git don't. And they're both right.

    历次讨论

    同类还值得读

    1. 开源应用架构

      The Architecture of Open Source Applications

      《开源软件架构》(AOSA)是一本在线免费书,邀请知名开源项目的作者亲自剖析其内部设计,涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。

      编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选
    2. 编程语言简史:简短、不完整且多半错误

      A Brief, Incomplete, and Mostly Wrong History of Programming Languages

      一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章,用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。

      编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.com
    3. SQLite 是如何测试的

      How SQLite is tested

      SQLite 官方文档页,系统介绍 SQLite 的测试体系:多种测试方法(TCL 测试、模糊测试、回归测试、静态分析等)和海量测试用例,展示了这个小型开源项目如何靠极致测试获得…

      编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选
    4. 高级编程语言(2009)

      Advanced programming languages (2009)

      Matt Might 的经典文章,按用途推荐“高级编程语言”:如果追求就业就选主流语言,如果追求表达力、学术研究或创业,则推荐 Haskell、OCaml、Scala 等函数式语…

      编程与软件工程上首页 8 次 · 2009–2022matt.might.net
    5. 我的 Forth 与栈机器经历

      Yosefk - My history with Forth & stack machines

      作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程:既赞叹其简洁优雅、代码量小、可自举的优点,也坦率指出栈操作在实际编程中的痛苦,以及 Forth 社区文化中的问题。

      编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。