对大多数网店来说，Drupal Commerce 都是错误的答案。这并不是在批评这个项目，它十五年来一直工程扎实。这只是在陈述大多数网店的样子：几百个 SKU、一种货币、面向消费者的客户，最后刷一次卡。对这种形态的生意来说，托管型平台在每一个重要的维度上都会胜出，争论还没开始就已经结束了。 但确实存在一小部分商家，他们的账算下来完全相反，而且这是一批利润可观的商家。无法用变体网格表达的可配置产品。带有议定价目表的贸易账户。目录本身就是编辑内容。由 ERP 掌握库存与价格，而网站只是一个展示面。在这些生意里，托管型平台并不便宜，它是一笔长期缴纳的税，以应用、变通做法和"这里不许改"的形式支付。 本文要说清楚那条界线究竟落在哪里，并给出...
英国企业
关于英国企业的文章、指南和教程，为开发者和企业提供实用知识与技巧。并附真实项目中的具体案例。
Drupal 12 定于 2026年12月7日那一周发布，而 Drupal 10 在 2026年12月9日走到生命周期终点。这两个日期就写在 Drupal 核心发布计划的同一页上，相隔不过两行，可是绝大多数正在运行 Drupal 10 站点的人两个都没注意到。新大版本的第一个 alpha 已经在 2026年9月2日打上标签，所以这次发布的形状现在是记录在案的事实，不再是猜测。 这场撞车就是全部故事。一个大版本发布，对站点所有者来说通常并不紧急，因为你可以在旧的大版本上坐一两年，等生态跟上来。这一次不同，旧的大版本在新版本发布的同一周停止收到安全公告，于是一个技术事件变成了一个带着合规锋刃的截止日期。...
“Drupal 很慢”这个名声，绝大部分来自主机托管，而它几乎总是一个采购决定，而不是软件问题。站点被认真地做了出来，然后上线在一个按“几个 PHP 文件的宣传册站点”定价的套餐上。结果就是：一套带着正经渲染管线的内容管理系统，跑在一个自己改不了的内存上限里，跑在一个自己控制不了的操作码缓存上，还没有一个能运行自身工具的命令行。 人们心里拿来对比的是 WordPress，而这个对比是错的。WordPress 几乎在任何环境下都能凑合跑，是因为它的市场份额逼着主机商把它做成几乎在任何环境下都能凑合跑。Drupal 的前提不同：它假定你有较新的 PHP、较新的数据库、真正的缓存后端、一个命令行，以及一套把代码库当成构建产物而不是当成“可...
开发者入职通常是按入职培训花了几天来衡量的，而那是问题的另一头。真正重要的数字是另一个：一个新来的工程师要过多久，才能改动某个东西，并且有把握自己没有弄坏别的地方。在大多数团队里，这个数字是以月计的，而不是以天计的。 延迟很少出在人身上。它出在系统里有多少部分只存在于别人的脑子里，以及前两周里有多大一部分时间，是靠一次次打断别人，一点一点把这些东西挖出来的。 唯一值得追踪的指标：从入职到他们的第一次改动进入生产环境，需要多久。 不是第一次提交，提交可以只是改一个错别字，而是一次有意义并且真正上线的改动。如果这个时间超过一周，障碍几乎从来都不是能力。而是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。...
可用性 SLA 看上去像一句承诺，实际运作起来却更像一份退款政策。供应商很清楚这一点。客户往往并不清楚，于是在签署服务级别协议时以为自己买到了可用性，而真正买到的，只是万一没拿到时的一点折扣。 这不一定是笔糟糕的交易。它只是与大多数人以为自己在签的那笔交易不同，而这个差别恰恰在系统宕机、有人追问合同究竟怎么写的那一刻显现出来。 三个九听上去接近完美，却允许每月 43 分钟的停机。 四个九允许四分钟。如果你的业务能吸收工作日下午 43 分钟的中断，99.9% 就足够了，不必为更高的数字付费。如果吸收不了，再多的九也帮不上忙，因为协议给你的是一笔积分，而不是阻止这次中断。 可用性 SLA 用分钟兑现的承诺百分比把一个非常大的区间压缩成看...
软件源代码托管，也就是把源代码交给中立的第三方保管（英文称为 software escrow），回应的是一种完全合理的担忧：为你构建并运维关键系统的供应商倒闭了，而你手上留下的，是一个自己离不开、却又维护不了的东西。托管协议把源代码存放在第三方那里，一旦真的发生这种情况，第三方就把它交付给你。 这种担忧是站得住脚的。问题在于这项工具经常被误解，而两者之间的落差催生出一类协议：每年都在花钱，真到需要它的那一天却帮不上忙。 签字之前应该先问的那个不舒服的问题： 如果明天就把代码交到你手上，你这边真的有人跑得起来吗？一份没有构建说明、没有基础设施定义、没有它所调用的第三方服务凭据、也没有数据的源代码托管，不是业务连续性方案。那只是一个文件...
在固定价格合同和按工时计费之间做选择，通常被描述成一次关于风险的选择。这个说法本身没错，但紧接着就被处理错了，因为双方都默认风险会消失，而不是只从一方转到另一方身上。 风险不会消失。在固定价格的安排里，供应商承担估算出错的风险，并把这份风险提前算进报出的数字里。在按工时计费的安排里，承担风险的是客户。真正的问题从来不是哪一种方式能消除不确定性，而是哪一方更有条件去管理它，以及为转移风险付出的代价值不值得。 能预判哪种方式管用的检验： 你能不能把“完成”写下来，写到两个人对是否已经达到这个状态能给出一致判断的细致程度？如果能，固定价格是你可以用的选项，而且多半是合理的。如果写不出来，固定价格合同并不会消除模糊，它只是把将来每一次分歧从...
在小团队里，灾难恢复通常只剩下一份从来没人打开过的文档里的一行字：备份已经开启。这句话本身没错，却算不上任何问题的答案，因为它既没有说明真正出事时找回来的数据会有多旧，也没有说明恢复一次要花多长时间，更没有说明到今天为止究竟有没有人完整地做过一次恢复。 拥有备份和真的能恢复之间存在一段明显的距离，大多数故障正是在这段距离里升级成事故。一份存在、内容也够新、却从来没有被还原过的备份，本质上仍然只是一个假设；而你第一次去验证这个假设的时刻，恰好是发现它其实是错的最糟糕的时刻。 两个数字能把意见变成计划。 你能承受丢多少数据，又能承受停多久？这就是你的恢复点目标和恢复时间目标。只要业务一侧没有人把这两个数字说出口，关于备份频率的一切技术争...
软件 RFP，也就是需求建议书，本来的作用是让不同的供应商变得可以互相比较。可现实中大多数文件恰好起了反作用：它们把解决方案写得足够细，细到把答案的空间捆死，却偏偏漏掉了任何人报价时都需要的那些信息。结果就是五份报价，彼此相差一个数量级，形式上每一份都回应了要求，但没有任何两份在测量同一件事。 常见的解释是供应商在打太极。偶尔确实如此。但更常见的情况是，文件要了一个从它自身内容里根本推不出来的数字，于是每家供应商都用各自不同的假设去填补空白。假设不同，价格自然不同，这里并不存在诚不诚实的问题。 判断你的 RFP 是否有效的检验方法： 两家不同的供应商读完之后，能不能得出实质上相同的范围？如果文件里只写了“用户管理”，没有说明有多少种...
软件维护成本，就是那个把一个成功项目在十八个月之后变成一场难堪谈话的数字。开发阶段有预算、有审批、也如期交付了。可上线之后会发生什么，被一句「支持服务」轻轻带过，然后配上一个有人凭感觉给出的金额，而那个金额几乎每一次都太小。 原因出在结构上，不是谁不上心。开发有一个可以定价的范围。维护没有范围，因为决定它的是还没有发生的事情：某个依赖库爆出漏洞，某个供应商改掉了自己的接口，某个用户碰上了当初谁都没想到的情形。 人人都在引用的经验法则是每年按开发成本的 15 到 20 个百分点计算，而它之所以危险，恰恰是因为它离正确答案不远。 它对的次数多到让人放心，错的时候又总是朝同一个方向错：它低估了缺陷集中冒出来的第一年，而在有合规义务或者外部...