给英语母语者的敏捷指南：一场对Scrum文化的辛辣讽刺
以讽刺幽默的方式解构敏捷开发术语，将Scrum仪式比作宗教行为，揭示流程形式主义背后的荒诞。适合对敏捷实践有反思的技术人员阅读，提供情绪共鸣与批判视角。
Lewiscampbell
Lewis Campbell 的个人主页，项目、文章与技术内容。
评论
点赞
收藏断网24小时的简短反思
作者尝试断网24小时，重获深度阅读与思考空间。反思数字成瘾对育儿的影响，以及社交媒体“钩子”机制的难以抗拒。虽未完全戒断，但提供了关于数字极简主义的个体实验视角。 
我认为Rust是面向对象的
作者认为Rust在本质上符合面向对象编程（OO）的核心特征：数据与行为的紧密封装、隐藏结构体字段以及通过Trait实现多态。文章指出，Rust社区常因缺乏传统继承机制而否认其OO属性，但这更多源于对C++虚函数和动态分发性能问题的回避。作者主张从“黑盒方法调用”的设计哲学而非语法细节来定义OO，这一观点挑战了主流认知，容易引发关于语言设计和OO本质的激烈讨论。
用户不在乎——但你应该在乎
本文反驳软件行业一句流行口头禅——「用户不在乎你的代码/技术栈/测试」。作者直言这是「一派胡言」：用户虽不直接关心代码内在质量，但会在意性能、Bug 数量、修复速度、功能迭代快慢等下游效果。文章用桥梁质检、飞行员状态等类比说明，忽视工程质量终将反噬产品体验。作者进一步指出，「用户不在乎」论流行的深层原因，是部分人对自己不擅长的领域进行贬低，将能力缺陷包装为实用主义，是一种自我防御机制。观点鲜明、表达犀利，适合对软件工程文化有思考的技术从业者阅读与讨论。
类型系统基础术语辨析
本文澄清了编程语言类型系统中四组常被混用的概念：静态类型与动态类型、强类型与弱类型，并指出常见误解——动态类型不等于"无类型"，强类型不等于静态类型。作者用C语言（弱且静态）和Python（强且动态）为例说明区别，同时批评了"严格类型""松散类型"等模糊说法。文章短小但有明确立场和个人观察，适合对类型系统有基础困惑的读者快速理清概念。
告别敏捷
一篇对Agile（敏捷开发）直言不讳的告别与批判。核心论点：敏捷从未被清晰定义，它赖以生存的对立面——Waterfall（瀑布模型）——早在1970年就被Royce本人指出不可行并提出了迭代方案，1976年Bell & Thayer的实证研究进一步确认了问题。作者翻阅原始论文发现，所谓"敏捷创新"（原型先行、客户参与、迭代开发）半个世纪前就是常识。如今LLM时代，行业回归写规格说明（Spec-Driven Development），敏捷"可工作的软件胜过全面文档"的主张被事实推翻。文章立场鲜明、考据扎实，有强烈争议性和讨论入口，适合对软件工程方法论感兴趣的读者。
为什么我选择用原生 JavaScript 做 Web 应用
一位曾深度使用 React 的前端开发者，用亲身经历论证：直接使用原生 JavaScript 和浏览器 API 开发 Web 应用，反而是更务实、更易维护的长期选择。疫情期间他跟主流用 React，做打包、转译、Hooks 和虚拟 DOM；后来因一个紧急项目来不及引入框架，直接写原生 JS 操作 DOM，发现不仅没问题，反而更轻松——50 行代码写了一个流式对象就实现了交互。最近他又在 Preact 项目中遇到 Hydration 和组件树错误，果断放弃，重回原生方案。他直言 React 并非对 DOM 的更高层抽象，而是另一种平行抽象，且抽象泄露严重——hooks 调试、useRef 绕圈子、组件渲染心智负担都很重。前端行业普遍年轻化，复杂框架导致的问题很少有人能真正掌控。与其依赖一个快速迭代、抽象层不稳定的框架，不如直接用平台本身——它始终向后兼容，文档优秀，对 LLM 代码生成也更友好。作者承认对其他框架了解有限，欢迎不同意见。
Rust 不过是一种工具
Rust 功能强大、工具链优秀，但作者直言它"不过是一种工具"。本文批判了 Rust 社群中过度狂热的现象——无需因为用了 Rust 就必须喜欢每个流行库、攻击其他语言使用者、拒绝承认设计缺陷。作者将编程语言去魅为工具而非身份标识或道德选择，呼吁开发者之间互相尊重不同的技术偏好。短小但有鲜明个人观点，适合激发关于技术社群文化的讨论。
你能读懂公元 1000 年的英语吗
一个有趣的语言实验：你能回溯到多远的古英语并仍能读懂？文章关联了 Hacker News 上一条有 400+ 评论的热门讨论，将历史语言学变成可参与的时间旅行式体验。话题本身自带好奇心和讨论入口，适合转发和互动。
LLM极端鼓吹者那源于不安全的布道
一位资深开发者以亲身经历挑战LLM狂热鼓吹者：他尝试了agentic编程和vibe coding，结果令人失望——需要大量监督、进展缓慢且错误频出。他并不否认LLM能帮新人创造东西，但质疑为何最激进的鼓吹者无法容忍不同意见，动辄指责质疑者是"害怕被替代"。作者提出一个反直觉的假设：这种布道式攻击其实是投射——他们自己发现AI比自己写代码更强，于是通过贬低别人来对抗不安全感。文章最后向LLM evangelists发出开放式挑战：你们是否愿意承认，自己可能并没有那么擅长编程？
强最终一致性——CRDT背后的核心理念
CRDT（无冲突复制数据类型）背后真正的核心理念是强最终一致性（Strong Eventual Consistency）：它保证多个副本在接收到相同更新后立即达成一致状态，而非"最终"一致。这意味着节点无需协调即可处理读写，延迟极低；即使多数节点宕机或离线，系统仍能正常工作。作者认为CRDT不仅是协同编辑和多人在线列表的工具，更是构建强最终一致性分布式数据库的基础组件。文章引用Shapiro等人2011年的经典论文，清晰区分了普通最终一致性与强最终一致性，并简洁阐述了SEC在本地优先应用和地理复制系统中的核心优势。
选错依赖，不如自己动手（NIH）
本文挑战了编程界"依赖没有成本"的常见误区，指出外部依赖不仅需要学习投入、可能因破坏性变更导致大规模重写，还会显著增加部署复杂度。作者引用 TigerBeetle 零依赖实践的案例，提出一套 5 维依赖评估框架：普适性（Ubiquity）、稳定性（Stability）、深度（Depth）、易用性（Ergonomics）和密封性（Watertightness），并以 POSIX 系统调用、ECMA-48 终端控制码和 Web 平台为例来说明什么是"好依赖"。文章立场鲜明，语言犀利，鼓励开发者理性评估依赖的真实代价，而非盲从"不重复造轮子"的口号。
高级测试与确定性：分离确定性代码与非确定性代码才是测试的核心
作者提出一个有力的观点：关于测试最该讨论的不是 TDD、单测/集成/E2E 的划分或静态类型能否替代测试，而是"分离确定性代码与非确定性代码"。确定性代码（给定相同输入永远产生相同输出）可以跟属性测试和确定性模拟测试等"高级测试"配合，极大提升发现 bug 的效率。文章梳理了不同编程范式（函数式、面向对象、系统编程）中各自解决这个问题的模式（依赖注入、Functional Core Imperative Shell、Hexagon Architecture、IO Monad、Mock、确定性模拟测试），对比了属性测试与确定性模拟测试的异同，也务实说明了遗留代码中"确定性孤岛"的现状，以及 E2E 测试作为"自动化的冒烟检查"的合理定位。有代码示例、对比表格和真实项目（FoundationDB、Tigerbeetle）参考，观点清晰、有作者亲身判断，不是泛泛的技术搬运。
编程语言的安全性只是实现目标的手段
文章作者旗帜鲜明地反对将静态类型系统、借用检查器等静态分析工具当作可靠软件的保证手段，认为它们只是辅助工具而非终点。核心论点：可靠软件靠的是充分测试，而充分测试靠的是软件真正跑起来。如果静态分析过于严格、繁琐、误报太多，反而阻碍代码运行，最终什么软件都出不来。作者明确表态：每次都在简单性和表达性之间选择前者，宁愿放弃严格的静态分析，也要让软件能跑、能测。短小但有真实立场，适合引发技术讨论。
我如何看待 Zig 与 Rust
本文跳出"Rust更安全但Zig更简单"的俗套对比，从语言设计哲学根源切入：Zig 骨子里是中端系统编程语言，刻意舍弃运算符重载、闭包、async/await 等表达力以保持"粗野主义"式的简洁，用 Comptime 一统泛型与宏；标准库直接提供 syscall 和 ring buffer。Rust 则出身高级语言世界，用仿射类型系统实现无 GC 安全，trait、模式匹配、monadic 错误处理等特性追求表达力，工具链和包生态也更成熟。作者结论是二者都是对 C/C++ 的巨大改进，建议根据场景选择：需要精确控制内存/系统调用选 Zig，想要高表达力同时能处理底层问题选 Rust，而不是纠结谁取代谁。有鲜明的个人立场和一手技术辨析，适合有编程背景的读者讨论和反驳。
文件也想成为Actor吗？——io_uring与并发模型的殊途同归
Linux异步I/O机制io_uring与1970年代提出的Actor模型——看似无关，实则殊途同归？本文作者敏锐点出：io_uring通过提交/完成双队列向内核发送操作请求并异步读取结果，与Actor模型中Actor之间发送消息、异步响应、自我状态更新的模式惊人相似。两者都在用"消息传递"取代传统函数调用语义，操作系统I/O正从阻塞式系统调用向异步消息范式演进。文章短小却有鲜明观点，为理解现代OS设计提供了一个新鲜的思考框架。