On Writing on IronCoreWorks

On "Against best practices"

Thu, 28 Nov 2024 00:00:00 +0000

I haven’t written any blogs on books or readings, so here’s what I’m gonna try: I will recommend some articles, and then write some comments about them.

This is the second piece of this series.

If you are interested, you can read the first one here on dependency updates.

Recently, I read an article bashing on best practices and I’d like to comment on it. Read the original article here. Or, here’s a summary for those TL;DR guys:

On "Disabling Scheduled Dependency Updates"

Thu, 28 Nov 2024 00:00:00 +0000

I haven’t written any blogs on books or readings, so here’s what I’m gonna try: I will recommend some articles, and then write some comments about them.

This is the first piece of this series.

Recently, I read an article on dependency updates and I’d like to comment on it. Read the original article here. Or, here’s a summary for those TL;DR guys:

关于 Against best practices 的评论

Thu, 28 Nov 2024 00:00:00 +0000

我还没写过关于别人的文章的评论，所以打算尝试这么一种形式：推荐一些文章，并附上我的评论。

这是本系列的第二篇。

如果你感兴趣，可以点击这里阅读第一篇关于依赖项更新的文章。

最近读到一篇炮轰"最佳实践"的文章，在此分享我的看法。原文链接在此。以下是给没耐心读者的TL;DR摘要：

作者批判编程领域对"最佳实践"的盲目崇拜。虽然承认许多最佳实践确有价值，但指出当缺乏经验者或热衷树立权威者将其教条化时，反而会产生危害。作者强调必须理解每个实践背后的上下文和逻辑，而非视其为金科玉律。文中以Postel定律、避免全局变量、DRY原则等为例，说明这些准则虽普遍合理却存在例外。作者抨击将"最佳实践"作为权威论据的行为，认为这会扼杀讨论与批判性思维，并类比安全领域规范——由于倡导者的道德优越感，质疑现有规则往往举步维艰。

先说说文章的闪光点：

每个人都该培养批判性思维，不该盲从教条，更不该把这些教条当作支撑观点的廉价论据。

对此我完全赞同——这反而让我有点不习惯，毕竟我平时看什么都想抬杠。

顺带一提，上文的TL;DR摘要由Gemini生成，质量相当过硬。

但问题在于：这篇文章的行文结构，恰恰无法支撑"不该盲从最佳实践"的核心论点。

且听我分解。

文章标题是《反对最佳实践》，开篇却大段讨论Postel定律。这个例子本身没问题，但"Postel定律"根本不算"最佳实践"——这个案例完全跑题了。

不信？问问谷歌：搜索"Postel’s law" + “best practice”，结果页没有任何内容同时提及这两个术语。因为从来没人鼓吹"Postel定律是必须遵循的最佳实践"这类说法。

就像写《反对酗酒》，却用"每天喝可乐有害健康"作为开篇案例——可乐又不是酒精饮料。

退一步说，我们来看看Postel定律，或者说所有所谓的"定律"。

作者声称这不是真正意义上的"定律"，违反也不会怎样。但事实上，所有"定律"都如此：摩尔定律、康威定律要么已失效，要么存在例外。给某个观点冠以"定律"之名（或原则、规则等）从不能保证其绝对正确——这本该是常识。世上本无百分百正确的理论，称之为定律也不代表你要盲从。

再退一步，看看现实世界的法律。并非所有法律都合理，也非所有违法行为都会受惩。但这不意味着你可以不守法。遵纪守法仍是"最佳实践"，因为这是常识，通常也对你无害。

即便是牛顿定律这样的科学定律，在微观层面也会失效。

好了，关于这些非最佳实践的"定律"的题外话到此为止，回到正题。

作者随后举了些真正的"最佳实践"例子（比如搜索该术语+“best practice"能同时出现的结果），这很好。例如12要素应用。

但这里论证却显得乏力：作者认为12要素应用"包含部分可取观点、部分可疑观点和部分彻头彻尾的坏主意”，却未作任何解释。

作为自由人类，你当然可以持任何观点，但多些解释总归更好。十二要素里哪些可疑？哪些是坏主意？作者没说，我们永远无从得知。

当然，12要素并非放之四海皆准。比如在不使用容器编排平台时它就效用有限——它本就是为现代容器化、K8s环境设计的。在这个特定语境下，它非常可靠，因此才成为公认的最佳实践：这是在特定上下文中形成的共识。即便你搜索"12要素应用是错的"这类关键词，也很难找到有力反驳——因为它们本身没错，在适用场景下非常可靠，这正是它能成为最佳实践的原因：为日常处理容器化部署的人们提供了简化工作的共同基础。

总结来说，这篇文章的标题观点我完全赞同，可惜内容无法支撑标题，导致说服力大打折扣——虽然我本就不需要被说服。

就像挤奶凳需要三条腿（或四条；挤奶凳到底有应该有三条腿还是四条腿这种问题的答案取决于你的哲学倾向）才能稳固，文章的核心论点也需要内容支撑。

最后送上一句苦心经营的讽刺箴言：逻辑是个好东西，希望你也有。

关于 Disabling Scheduled Dependency Updates 的评论

Thu, 28 Nov 2024 00:00:00 +0000

我还没写过关于别人的文章的评论，所以打算尝试这么一种形式：推荐一些文章，并附上我的评论。

这是本系列的第一篇。

最近读到一篇关于依赖项更新的文章，想聊聊我的看法。原文在此阅读。给太长不看的读者总结如下：

David Lord维护着众多GitHub库，其中许多已趋于稳定，鲜需更新。他发现来自Dependabot和pre-commit.ci的自动依赖更新PR（每月每个项目约3个）造成了大量通知噪音和无效劳动，尤其是每月月初。这让他难以识别重要通知，并制造了项目活跃的假象。虽然自动更新对应用程序很有用，但类库并不需要这种持续关注。为此，他关闭了自动更新功能，转而使用pip-compile、pre-commit和自研工具gha-update（用于GitHub Actions）创建本地更新命令。现在他只在主动开发项目时手动更新依赖，既能确保固定依赖环境可用，又能在需要时灵活升级。他通过tox管理这些更新命令，并用all-repos批量执行，从而完全掌控更新节奏。

我有三点——也可能是四点——想说：

这篇文章好在哪？
对作者论点的反驳
文中一个与主题无关的细节
以及我的随想

首先声明，我不同意他的某些观点。

但正确之处也不少。凡事总有可取之处，没有绝对错误的事情，对吧？

先说优点：为保持统一的开发体验，固定依赖版本并定期更新是正确的做法。

如果依赖版本设定为范围（比如大于某版本号），本质上就不可预测，更容易遭受供应链攻击。若对供应链攻击和依赖混淆攻击感兴趣，可读我的旧文：

作者希望按自己的节奏升级依赖，理由有三，但在我看来都站不住脚：

他提到每月每个仓库3个PR造成的操作负担（滚动点击等），但这完全可以通过自动合并解决。况且更新频率本就可调，后文详述
他拥有20个仓库——这是极端案例。不能因为你无力维护20个仓库，就否定自动化更新对单个仓库的价值，这种逻辑不成立
自动化优于人工：零人为失误，零操作负担。综上，他的论点难以服人

第三点想谈个细节：

“对于应用程序，特别是配置了持续部署的场景，定时更新可能合理。你希望尽快部署所有错误修复和安全补丁。”

“对于类库，这些依赖仅在本地的开发环境运行。虽然新功能和修复很诱人，但并不需要持续即时关注。”

我持异议，尤其针对前半段。

即便是配置了持续部署的应用程序，也不该总是立刻升级到最新版本。关于这点我早年写过博客。

绝大多数漏洞和安全问题都集中出现在软件生命周期的前几个月，之后数量会急剧下降。这就是为什么Firefox、Chrome等关键软件都提供企业支持版，其版本往往落后标准版数月甚至数年。月度更新都嫌频繁，我倾向于季度更新。

最后，也是这篇文章的重点——我想分享近年阅读的一个感悟：作者应当对文字可能改变读者观念乃至人生的力量保持敬畏。举例说明：

偏爱手动操作本无妨，这是你的自由。

我自己就常手动处理：无论是单车还是汽车，我都享受换挡的掌控感；经常懒得写正则表达式匹配文本模式，而是在Sublime Text里按住Command+D逐个选中。我有的是时间，等得起"一会儿"。

但是（这个"但是"很重要），我绝不会建议你也这么做。这只是我的个人癖好，懂吗？我断不会为此专门写博客宣扬手工操作。能写≠应该写，尤其是这种仅符合小众偏好的主观选择。我不愿输出本质上"不正确"的内容。

然而（这个"然而"同样重要），作为Flask核心开发者——具有一定行业影响力的人物——下笔时理应对读者和社区多几分责任感。你要明白大多数人并不维护20个仓库，也不会每月处理3个依赖更新PR。更不该把特定场景下的个人工作流包装成普适建议公开发表。经验不足的读者可能会盲目追随：既然Flask大神都这么做，肯定是最佳实践吧？

再举个文学例子。

我喜欢的日本作家村上春树有本《刺杀骑士团长》，主人公是个住山间豪宅的富豪，开捷豹，每天凌晨2点失眠醒来，喝着威士忌配腰果。

他许多作品都有类似描写。当这类细节积累到一定程度，读者难免产生"喝威士忌配腰果很高级"的联想——既然是名家笔下被富豪主角青睐的生活方式，想必很有格调？我也该试试？

我们通过所见所闻塑造世界观，这些输入在某种程度上决定了认知的边界。

借此机会想对所有写作者说：少写些自我陶醉的内容，多承担几分责任。何乐而不为呢？