Tech
追求快速交付导致了技术工程的消亡
工程变得不受重视，过于追求快速交付，忽视了基础的工程实践。
过去的20年里，我们见证了工程如何变得不再受欢迎。开发者们必须快速交付，但请不要打扰他们。
有很多论调认为“编程太复杂了，它不是科学而是艺术形式，所以让我们随意而行吧。”虽然这有一定的道理，但我想提出一个反驳意见。
它从何而来
如果你在技术领域待得足够久，你会看到钟摆总是从一端摆到另一端。你看到的越多，你就越会意识到有趣的事情发生在中间。在细微之处和“视情况而定”的领域。
在2000年之前，学术界主导了计算机科学。他们试图理解“工程”对编程意味着什么。他们借鉴了其他领域的实践，比如将建筑师与实践者区分开来，用严格的规划管理瀑布项目。
这很糟糕，非常糟糕。项目总是延迟，过于复杂，工程师对他们的工作没有动力。
这促成了敏捷宣言的诞生，它不仅改变了我们编程的方式，也改变了我们在科技领域的经营方式。Lean Startup和后来的著名的YC孵化器都强调快速行动、迭代，不用担心规划。
更糟糕的是，工程师们将Donald Knuth的名言“过早优化是万恶之源”重新解读为“先随便做，之后再修复……或者不修。”
我确实认为钟摆摆得太远了，存在一个工程实践的甜蜜点，实际上非常有用。这是纸巾数学和费米问题的领域。
适量的工程
要预测行星在某个日期的位置，建模和计算比等待行星移动更快。这是因为人类有一个捷径。它叫做数学，可以解决大多数线性问题。
但如果我想预测一个复杂系统，比如细胞自动机，我们没有捷径。没有数学——也许永远不会有——能帮助我们绕过整个计算。我们只能运行程序，等待它得到答案。
大多数程序是复杂系统；因此对工程完全抗拒。只需运行它，我们就会看到结果。然而，它们都包含简单的线性问题，如果解决了，这些问题就是理解是否值得构建的捷径。很小的成本可以节省数月的工作。
这些线性问题通常是以下三个之一：
时间：它会在10毫秒还是10天内运行？这是算法复杂性、光速和延迟的领域。
空间：它需要多少内存或磁盘？这是编码、压缩和数据结构的领域。
金钱：最终，我能负担得起吗？欢迎来到优化、云滥用的泥潭，以及为什么我最终住在桥下。
当然，这三者是相关的。你通常可以相互交换时间和空间，而金钱通常可以买到这两者。
费米问题和纸巾数学
让大多数人困扰的一件事是“不知道数字”。没有过去的数据预测未来会非常有压力。但一旦你习惯了捏造数据，你会发现重要的不是数字，而是边界。
一个最著名的费米问题之一，就是在一些求职面试中被用来猜测纽约有多少钢琴调音师。你不会得到正确的数字，但可以肯定的是，这个数字必须在10到10,000之间。如果你知道纽约有800万人口，其中1%拥有钢琴(80,000)，每个调音师每年可以服务100个客户，那么上限约为800，或四舍五入为1,000。尽管这些猜测的边界相差很大，但这可能足以让你不为这个利基市场开发一个每月1欧元的应用程序。
你可以从极其悲观的假设开始，假设可能在p99的范围内。例如，如果你想计算存储一本书内容所需的存储空间，假设一本书有5,000页。大多数书籍的页数少于此，所以如果计算结果是正的，那么你就大可放心。
计算归结为简单的数学：加上和乘以你的假设。没有什么花哨的。但是对于其他计算，你需要知道基准或算法和数据结构的细节。例如，如果你试图估算训练一个LLM模型所需的钱，了解变压器的工作原理会有所帮助。它让你计算所需的内存。我建议将一些备忘单书签保存，以备不时之需。
我通常只做最坏情况的计算，但如果你想做区间计算，你可以使用像guesstimate这样的工具。保留计算结果，因为一旦你开始有了真实数据，你会想要验证假设并更新先验。
fika中的纸巾数学示例
作为一个例子，我将展示我在构建fika时所做的计算，以确定什么是可能的，什么是不可能的，以及什么最终被更新了。
主要假设是一个p99用户(我以自己为模型)总共有约5,000个书签，并且每月生成100个新书签。
根据HTTP Archive的数据，p90网站的重量约为9MB，这非常不幸，因为这使得存储(R2)成本太高。但是如果你深入研究数据，大部分重量来自于图像、CSS、JavaScript和字体。我可以通过使用Readability去除大部分内容，压缩图像，并最终对其进行gzip压缩。这是我在开始项目之前没有想到的需求，但一旦数据摆在桌面上，就变得显而易见了。
我还计算了是否可以负担得起使用Inngest。用户价格太高，直到我发现批处理大多数事件可以将成本降低到可管理的水平。
我还评估了另外两个很棒的供应商。Microlink获取书签的元数据，Browsercat提供托管的Playwright解决方案。不幸的是，他们的定价模型不适合我的用例。我想将座位定价为2美元，这两家供应商会吞噬所有利润。
后来我探索了实现混合搜索。OpenAI当时的定价是每百万个令牌0.10美元，这意味着每用户每月0.60美元。价格太高，但几个月后他们发布了一个新的模型，只需0.02美元。尽管这个价格现在使语义搜索成为可能，但我已经将搜索迁移到客户端。
随着snowflake-arctic-embed-xs的发布，我想看看是否可以将所有书签嵌入内存。这是必要的，因为实施基于磁盘的向量数据库不在范围内。我计算出它需要约350MB，这不太好。但这个领域发展迅速，小模型变得越来越有吸引力，所以我会等一等，看看情况如何发展。
最后，我对构建一个本地优先的应用程序最大的担忧之一是确保用户能够在客户端持有所有数据。我只关注书签，因为这是大部分重量可能去的地方。
- Origin Private File System(OPFS)：为了离线读取书签，我想在用户设备上保存一个副本。保存所有书签，在最坏情况下大约需要3GB。这意味着在Chromium中有80%的存储配额，我可以支持任何存储超过4GB的设备。很好。
- 内存中的全文搜索：我想知道是否可以将所有书签的内容放入内存中，并用orama操作基于BM25的搜索。我对全文搜索数据库的倒排树和其他数据结构知之甚少。但如果我们假设没有开销(不太可能)，将所有书签文本放入内存中大约需要350MB。我没有放弃这种方法，但这绝对是我需要深入研究的东西。我目前正在探索是否使用SQLite+FTS5可以将这些索引放在磁盘上而不是内存中。
目前结果
我收到了第一个200个报名，这证明了一些假设过于悲观。
- ~1000 → ~200故事/月/用户：虽然还早，但显然大多数用户书签较少，并且订阅的提要也很少。仅此一项使每用户成本降至0.02美元，这使得去掉付费墙成为可能，而不会破产。
- 0.36MB → 0.13MB/书签：事实证明，书签可以比我最初想象的压缩得更多。使用WebP，限制大小，去除所有CSS/JS/字体使书签非常轻量。
- 5% → 3%重叠：我的直觉是这个数字会更高。随着越来越多的人加入平台，你书签某个故事的可能性应该会更高。但目前，用户比我想象的更独特。
- 20% → 108%提要/书签：这意味着书签一个故事平均发现1.08个提要。这怎么可能？RSS真的那么流行，以至于网站包含多个提要？不是。这是一个最大的惊
事实证明，系统有反馈循环。一个书签推荐一个提要。提要包含故事。这些故事发现不同的提要。例如，订阅Hacker News是发现许多其他提要的非常快的方法。
结语
在这个帖子之后，我希望鼓励你在烹饪前先检查冰箱。不要害怕做一些基本的计算，这样做不会让别人认为你是一个次等的领导。这不是过度工程，也不是过早优化。这是一种非常基本的对冲形式，成本非常低，而潜在的回报却非常惊人。因为最好的代码永远是从未编写的代码。