码厩开发者笔记

#106 转载：布尔变量取名规则

传说中，编程有两大难题，一个是缓存失效，另一个是变量起名。

其中，布尔变量尤其难起名。怎样才能贴切地表达，这个变量是表示"真"（true）和"伪"（false）的布尔值呢？

我最近读到一篇文章《布尔变量起名的艺术》，提出使用四个前缀就能给布尔变量正确起名，我觉得很有启发。

1. is-：描述事物的状态，后面跟形容词，比如 isActive，isDeleted，isEmpty。
2. has-：描述事物的所有权或包含关系，后面跟名词，比如 hasAccess，hasChildren，hasValidationErrors。
3. can-：描述事物的能力或权限，比如 canEdit，canDelete，canRetry。
4. should-：描述事物的意图或逻辑，比如 shouldRetry，shouldCacheResponse。

除了这四个前缀，起名还有另一条规则：永远不在布尔变量名中使用否定词。
比如，不使用 isDisabled，而要用 isEnabled = false。

#105 百度云 ICP 备案记录

• 原备案信息（阿里云 · 2019）：备案名称「码厩Markjour」，备案号 鄂ICP备15002462号。
• 迁移原因：不再使用虚拟主机，业务迁至百度云低成本主机，需在百度云重新提交接入/备案，备案名称变更为「码厩开发者笔记」。

初审被拒，原因：

1. 应急联系电话校验：应急手机号不能与负责人手机号码相同，需提供另一位真实可联系人的号码（当年没有这个要求）。
2. 前台菜单合规审核：初审要求网站不得出现“留言”和“给我写信”菜单，这算页面交互入口（推测当年备案时尚未增加这两个菜单）。
   • 这两个功能从没用过，暂时屏蔽前端入口以通过核验，后面再看如何处理。

初审通过之后，备案进入 “管局审核中-短信校验中” 状态。
几分钟之后就会收到工信部短信验证码，需要进入指定链接输入验证码、手机号、身份证后六位进行核验。
短信核验之后过一会儿，备案进入 “管局审核中-人工审核中” 状态。

#104 阅读代码之前执行的 git 命令

AI 总结了 The Git Commands I Run Before Reading Any Code，可以作为参考。
PS：其中部分命令的有效性是建立在提交规范执行良好的基础之上。我过去经手的项目全部没有提交规范。😂

Five git log commands that diagnose a new codebase before you open a single file: code churn hotspots, bus factor, bug clusters, and crisis patterns.

1. 变更热点 列出去年改动最频繁的 20 个文件，榜首常是团队"无人敢碰"的那个。高变更本身不糟，但若叠加"无人愿拥有"，便是代码库拖累的最强信号——每次修改都是补丁叠补丁，小改动的影响范围不可预测。微软 2005 年研究证实，变更率指标比复杂度更能预测缺陷。

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

2. 总线因子 按提交数排名贡献者。一人占 60%+ 即为风险；若其已离职半年便是危机。长尾同样关键：30 位贡献者中仅 3 位近一年活跃，说明建造者已非维护者。注意 squash-merge 会压缩作者信息，下结论前需确认合并策略。

git shortlog -sn --no-merges

3. Bug 集群 形态同变更热点，但过滤含 bug 关键词的提交。同时出现在两张列表的文件风险最高：反复出错、反复修补却从未根治。此法依赖提交信息规范。

git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20

4. 提交节奏 按月统计提交数。稳定节奏健康；单月减半常因有人离职；6–12 个月下滑曲线揭示团队失速；周期性尖峰后沉寂则是批量发布模式。这是团队数据，而非代码数据。

git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

5. 回滚与热修频率 一年中偶发回滚正常；若每几周一次，说明团队不信任部署流程，背后是测试不可靠、缺预发环境或回滚困难。零结果同样值得玩味。

git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'

#103 阿里全面禁用 Claude Code

阿里巴巴宣布，自 2026 年 7 月 10 日起，全面禁止员工在办公及研发环境下使用 Anthropic 旗下 Claude 系列产品（含 Claude Code），并要求全员卸载清理，同时推荐使用阿里自研 AI 编程工具 Qoder 作为替代方案。

此前，阿里曾鼓励员工使用海内外 AI 辅助编程工具，Claude Code 是程序员高频使用的编码助手，相关外部模型调用费用可走企业报销。

此次变动主要可能基于三方面考量：

1. Claude Code 被曝存在隐蔽检测/后门风险，可能导致企业核心代码与研发数据外泄；
2. Anthropic 近年多次无预警封禁中国用户并限制中资企业使用其服务，供应链与合规风险上升；
3. 阿里自研 Qoder 已具备端到端AI编程能力且支持内网私有化部署，可保障数据不出境、满足自主可控与信息安全合规要求。

#102 我的 Token 消耗情况

我用的是 Cursor 做开发，根据 Cursor 后台统计，一个月消耗 Token 大约 6 亿 Token。
需要购买 Pro+ 套餐才能满足要求，一个月 48 美金（年付），折合人民币大约 336 元。

听说龙虾的创始人每月消耗 6000 多亿 Token，是我的 1000 倍，确实有点吓人。
哪怕采购量大可以打一折，也得 3 万多元人民币。
PS：他是 OpenAI 员工，可以无限量调用自家模型，不用花钱。

网约车巨头 Uber 今年头四个月就花完了全年34亿美元的 AI 预算，不得不限制使用 AI 了。
微软也因为费用超标，放弃了 Claude Code，改用自家托管的 OpenAI 模型。

听同事讲，公司提供的 Codex 200 刀的套餐，所有研发共用，每月基本上足够。
Codex 200 刀的这个套餐可以这么划算么？我查了 Codex 订阅和相关信息，看起来也不至于这么划算啊。
不知道实际上同事们的使用程度到底如何。

基础认知：

1. Cusor Tab（代码自动补全）通常不消耗额度，AI 对话/生成能力才会消耗额度
2. 模型价格 × 输入上下文长度 × 输出长度 × 调用次数
   其中：输入上下文通常是最容易失控的部分，一定需要控制好。
3. 控制上下文范围，比控制模型选择更重要

草拟了一个控制 Token 消耗的方法：

1. 默认使用 Auto 模型，让 Cursor 根据任务自动选择成本和效果更加平衡的模型。
2. 任务拆解后再交给 AI，不要直接把复杂目标交给 AI，确保问题规模小，描述准确。
   让 AI 解决明确的小问题，而不是让 AI 自己探索整个系统。
   扫描大量代码 + 生成超长上下文 + 多轮修改 = 快速消耗 Token
   我的套餐更适合日常开发修改，不适合让 Agent 长时间承担「全仓库理解 + 多轮推理 + 大范围修改」这类高消耗任务。
   所以少说：解决 xx 问题、重构 xx 方案。
3. 精准控制上下文范围，尽可能精准指定代码范围，只把相关代码加入模型上下文。
   不仅上下文更小，修改也会更准确一些。
4. 新任务就开启新对话（New Agent），避免长期复用同一个对话。
   长期积累会导致上下文膨胀。
   保持每个 Agent 任务边界清晰。
5. 定期查看 Dashboard 监控模型使用量和 On-Demand 消耗。

#101 为什么 Trace ID 应该 128 位

#100 软件工程定律

根据lawsofsoftwareengineering.com网站的分类体系，这些软件工程定律可以分为以下七大类别：

一、架构（Architecture）

1. 康威定律（Conway's Law）：组织设计的系统会反映其沟通结构
2. 盖尔定律（Gall's Law）：能工作的复杂系统必然从能工作的简单系统演变而来
3. CAP定理：分布式系统只能保证一致性、可用性、分区容错性中的两个
4. 海勒姆定律（Hyrum's Law）：API用户足够多时，所有可观察行为都会被依赖
5. 分布式系统八个错误假设：新分布式系统设计者常犯的八个错误假设
6. 复杂系统变更定律：改变复杂系统时总会遇到意外
7. 系统膨胀定律：小型成功系统往往被过度工程化的臃肿替代品取代

二、团队（Teams）

1. 邓巴数（Dunbar's Number）：一个人能维持约150个稳定关系
2. 布鲁克斯定律（Brooks's Law）：为延期项目增加人力只会让它更晚
3. 团队规模与生产率：个人生产率随团队规模增大而降低
4. 1%规则：总参与人数的平方根完成50%的工作
5. 技术管理悖论：懂技术的人不管理，管理的人不懂技术
6. 彼得原理（Peter Principle）：员工会晋升到不胜任的层级
7. 巴士因子（Bus Factor）：项目陷入严重困境所需的最小团队成员损失数
8. 无能晋升定律：公司倾向于提拔无能员工到管理层以限制其破坏

三、规划（Planning）

1. 帕金森定律（Parkinson's Law）：工作会填满所有可用时间
2. 90-90规则：前90%代码占前90%时间，剩余10%占另外90%
3. 侯世达定律（Hofstadter's Law）：事情总比预期花更长时间
4. 扎温斯基定律（Zawinski's Law）：每个程序都会膨胀到能读邮件
5. 古德哈特定律（Goodhart's Law）：指标成为目标后就不再是好指标

四、质量（Quality）

1. 过早优化：过早优化是万恶之源
2. 童子军规则：离开时让代码比来时更好
3. 破窗理论：不要留下未修复的破窗（坏设计、错误决策、差代码）
4. 技术债务：开发软件时拖慢我们的一切
5. 林纳斯定律（Linus's Law）：足够多的眼睛能让所有bug变浅显
6. 调试难度定律：调试比写代码难两倍
7. 测试金字塔：项目应有大量快速单元测试、较少集成测试、少量UI测试
8. 测试衰减定律：重复运行相同测试效果会随时间降低
9. 软件演化定律：反映现实世界的软件必须演化，且演化有可预测限制

五、扩展（Scale）

1. 阿姆达尔定律（Amdahl's Law）：并行化加速受限于不可并行工作比例
2. 古斯塔夫森定律（Gustafson's Law）：通过增加问题规模可在并行处理中获得显著加速
3. 梅特卡夫定律（Metcalfe's Law）：网络价值与用户数平方成正比
4. 测量重要性：任何需要量化的东西都能以某种方式测量，这比不测量好
5. 墨菲定律（Murphy's Law）：可能出错的事情总会出错

六、设计（Design）

1. YAGNI原则：除非必要，不要添加功能
2. 抽象泄漏定律：所有非平凡抽象在某种程度上都会泄漏
3. 本质复杂性：每个应用都有固有不可减少的复杂性，只能转移不能消除
4. 单一事实来源原则：每条知识必须有单一、明确、权威的表示
5. KISS原则：设计和系统应尽可能简单
6. SOLID原则：增强软件设计的五个主要指导原则
7. 迪米特法则（Law of Demeter）：对象只应与直接朋友交互，不与陌生人交互
8. 最小惊讶原则：软件和接口应以最不令用户和其他开发者惊讶的方式行为
9. 鲁棒性原则：对自己要保守，对他人要宽容

七、决策（Decisions）

1. 斯特金定律（Sturgeon's Law）：90%的东西都是垃圾
2. 邓宁-克鲁格效应（Dunning-Kruger Effect）：对某事了解越少，往往越自信
3. 汉隆剃刀（Hanlon's Razor）：不要归因于恶意，如果愚蠢或粗心能充分解释
4. 奥卡姆剃刀（Occam's Razor）：最简单的解释往往最准确
5. 沉没成本谬误：因已投入时间或精力而坚持选择，即使放弃更有益
6. 地图不是疆域：我们对现实的表征不等于现实本身
7. 确认偏误：倾向于支持现有信念或想法的信息
8. 阿马拉定律（Amara's Law）：我们倾向于高估技术短期影响，低估长期影响
9. 路径依赖：某物使用时间越长，继续使用的可能性越大
10. 分治法：将复杂问题分解为最基本模块，然后从那里构建
11. 逆向思维：通过考虑相反结果并反向工作来解决问题
12. 帕累托法则（Pareto Principle）：80%的问题来自20%的原因
13. 坎宁安定律（Cunningham's Law）：在互联网上获得正确答案的最佳方式不是提问，而是发布错误答案

这56条定律涵盖了软件工程从架构设计到团队管理、从项目规划到质量保证的全方位智慧，为开发者提供了系统性的指导框架。

#99 随机字符串碰撞概率分析

在设计邀请码、一次性授权码等场景时，通常会使用较短的随机字符串。

随机字符串越短，用户输入越方便，但碰撞风险也会显著上升。因此，长度设计本质上是在“可用性”和“唯一性”之间做平衡。

假定采用一个 Base32 字符集（A-Z 2-7），分析在每天生成 10,000 个随机字符串时，不同长度下的碰撞风险。

#98 一种廉价技术栈方案

博客文章 Steve Hanov's Blog 《How I run multiple $10K MRR companies on a $20/month tech stack》介绍，他运行多个月收入1万美元公司的技术栈以极简和高性价比为核心，每月总成本控制在20美元左右。在极低成本下实现高可用的创业项目，避免过早引入复杂架构和巨额云账单。
PS：其实没有计算一次性购买 GPU 的费用，以及开发工具 GitHub Copilot 的月费。

以下是其技术栈的详细总结：

PS：需要执行 AI 任务的时候，线上服务调用作者本地机器进行 GPU 计算（可能是搞了一个 VPN）。
PS：开启 WAL 模式之后，SQLite 的并发性能会有很大提升。（SQLite WAL 模式）

自研库：

#97 终端图像渲染技术