HackerTube English?
子领域索引

软件边界与变化

从一次代码改动或故障出发，追踪规则、状态和调用者之间的依赖。

从一个问题开始

一个模块究竟答应了调用者什么？ →想换掉一个模块，却发现别处依赖它碰巧返回的顺序。从「接口写了什么」往前走一步：哪些决定本该藏在里面，又有哪些行为已经被人当成承诺？切开代码，就切开了依赖吗？ →从一条要发邮件的规则开始。先把判断和执行分开，再检查分层、对象和抽象：改动一条业务规则时，哪些地方还是必须一起改？一条记录能同时回答「现在」和「当时」吗？ →两次查询得到了不同答案。先问你在读哪个时刻的值，再问谁能修改它。保存历史与协调写入解决的是不同的问题。坏掉一个部件，谁还能继续工作？ →一个进程出了错，其余请求是否必须等待？把故障传播和性能瓶颈分开看，再追踪操作系统与服务管理者各自能控制的边界。我已经出拳了，迟到的输入还能改写哪一帧？ →从《时空幻境》的倒带，走到格斗游戏的回滚，再看《光环：致远星》中的一枚手榴弹。三次屏幕上的动作，分别要求我们记住过去、修订预测和等待主机裁决。线上只失败过一次，怎样把故障变成能重放的测试？ →设想一笔已确认的转账在主节点切换后查不到了。沿着六段工程讲解，把事故拆成可以保存的输入、可以删减的操作和必须成立的性质，再检验修复是否真的触达故障。这一款卖完以后，工作室还有时间做下一款吗？ →旧作收入何时到账，谁为下一部作品找到玩家，帮手是否真的腾出了时间？几位独立开发者的账本和发行经历，让持续做作品所需的时间具体起来。拿到一个控制器，究竟能指挥到哪一步？ →按下电梯按钮、接管车载屏幕、切断无人机的连接。三个动作都改变了系统的输入，接下来谁能决定真正的物理动作，却要顺着调度模式、车辆网关和机上的失联策略分别查。没有程序计数器，点唱机怎样记得下一步？ →点唱机已经松开了按钮，唱片却还在移动。跟着一条维持电流的回路读下去，再对照弹珠机的复位和暖炉的压力开关，找出状态保存在哪里、谁有权让它往前走。交接以后，怎样查回一项决定的来由？ →从注释里的设计理由走到工作记录里的操作和结果，看看接手的人能从哪一处开始复查。旧用户还在，新版本能改到哪一步？ →一个必填字段、一段旧网页、一台苏联计算机：版本一旦有人在用，修改就要回答谁来迁移、谁来承担旧行为。插得上，就算接得上吗？ →充电桩、密封圈、差速器和掌机的接口都「装得上」。顺着电流、热量和力往下看，才知道接口两边究竟交换了什么，又有哪些条件没有写进规格。接口藏起来的成本，最后由谁承担？ →零开销抽象、换一家内存分配器、在内部用并发：接口让调用者不必关心实现，但时间、内存和协调的成本并没有消失，只是换了承担者。对方说做到了，怎样验收这个承诺？ →一台自制烤面包机、一份 GPL 源码、一句「有云服务」：交付方的说法要变成可检查的条件，验收才不只是相信对方。