除法引发的争议

软件是否存在“最佳使用期限”？

尊敬的 KV，

您知道软件多久需要维护一次有什么经验法则吗？我不是在考虑错误修复，因为错误从代码编写的那一刻就存在了，而是关于代码中似乎不断进行的重构。有时我觉得程序员使用重构只是为了保住他们的工作，而不是提供任何真正的改进。软件是否存在“最佳使用期限”？

新鲜代码

尊敬的 Fresh，

我绝对喜欢软件带有像牛奶盒上看到的新鲜度标记的想法。与其他易腐产品一样，软件似乎确实会在一段时间后变质，当我打开编辑器中的某些源文件时，我经常想起变质牛奶的恶臭。难怪这么多程序员在去修复错误时会皱眉头。

我认为软件更好的类比是基础设施。任何活得足够久，看到新的基础设施被建造、忽视，然后被修复的人都应该立即理解这个类比。想想 20 世纪 50 年代在美国建造的高速公路。当这些道路最初建成时，它们被认为是奇迹，帮助通勤者进出大城市。每个人都喜欢新事物，这项基础设施的建设伴随着大量的欢呼、演讲等，这些都与大型项目联系在一起。

然而，一旦完成，忽视的过程就开始了——成本削减、缓慢维修、忽视主要设计缺陷，直到路面碎片掉落。最后，高速公路维护得如此糟糕，以至于成为一种威胁，然后，除非你幸运地遇到地震摧毁了这个可怕的东西，否则你就会做出通常的工程决策：维修或重建。

软件的不同之处在于，如果代码以相同的方式日复一日地使用，并且从未扩展或更改——除了修复以前存在的错误——它不应该磨损。不磨损取决于一些事情——尤其是硬件不会进步。一个在 1980 年交付的运行系统——例如，在经典的迷你计算机如 VAX 上——如果相同的硬件存在，那么今天的工作方式应该与它建成时相同。

软件维护的问题出现是因为事物在变化。虽然用于构建系统的原始库在任何物理意义上都不会磨损，但它们与之交互的代码会随着时间的推移而变化，因为白痴（哎呀，我想说的是营销人员）要求新功能，并且硬件的速度和复杂性不断提高。可移植性的努力是崇高的，通常也是值得的，但是在一台 1-MIPS CISC（复杂指令集计算）计算机上运行的代码，如果没有经过大量的重新测试和更改，就无法在具有现代外围设备的现代处理器上运行。操作系统和设备驱动程序只能在一定程度上隐藏应用程序的底层变化。

虽然我见过很多伪装成重构的内省式练习，但所有软件的生命周期中都会出现一个时刻，即必须重新审视它所表达的设计决策。对此没有硬性规定。如果代码是一个“原型”——你知道，管理层发誓绝不使用，然后却使用了——那么它很快就会变坏。

以更合理的风格编写且没有上方施加荒谬时间表的程序，可以保持更长时间的新鲜度。

我认为我自己的代码有一个从我完成项目起算一年的“最佳使用日期”。如果我一年没有看过一些代码，我可能已经忘记了它是如何工作的。在某些情况下，我曾积极与我当地的酒保合作，尽可能多地忘记一些代码。

尊敬的 KV，

我一直在将一些 Python 2 代码升级到 Python 3，并且遇到了语言中的以下更改。过去，两个整数的除法（/) 会得到一个整数，但是要在 Python 3 中获得该功能，我需要使用//。仍然有一个/，但那是不同的。任何心智正常的人为什么会拥有两个如此相似且代码如此接近的操作？他们难道不知道这会导致错误吗？

除法引发的争议

尊敬的 Divided，

Python 不是第一个——而且我非常肯定它不会是最后一个——使用视觉上相似的关键字来表示不同含义的语言。考虑 C 和 C++，其中按位和逻辑运算使用非常相似的图像来表示完全不同的操作|用于按位或运算和||例如，用于逻辑运算。我也最近发现了 Python 3 中的这个变化，我的同事在我发现之后也发现了它，因为我不扔脏话炸弹，而是猛烈地发射它们。

在编程中不使用视觉上独特的图像的问题可以追溯到另一个专栏作家（Poul-Henning Kamp 在“先生，请远离 ASR-33！”2010 年 10 月；https://queue.org.cn/detail.cfm?id=1871406）提到的问题，即我们用来创建语言的字符集。语言设计者在寻找代表操作快捷方式的东西时，只有以下图像可以使用

!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

许多字符已经具有编程之外的既定含义，例如算术运算+, -, *，和/，而决定更改其含义的语言设计者应该被送往最近的河流或湖泊底部单程票。

当然可以放弃快捷方式，并将所有内容都做成函数，例如

(plus a b)

用于函数式语法，或者像在

a equals b plus c

中那样创建大量的保留字列表，用于 Algol 类语言。事实是，作为程序员，我们喜欢紧凑的语法，并且会拒绝使用像我刚刚给出的示例那样笨重的东西。

另一种选择是抛弃 ASCII 编码，转而使用更丰富的编码，我们可以在其中拥有更多独特的图像，我们可以将语义含义附加到这些图像上。然后出现的问题是如何输入该代码。现代计算机键盘旨在允许程序员键入 ASCII。问问日本程序员他们是使用日文键盘还是美式键盘，十分之九的人会告诉你美式键盘。他们选择美国版本是因为“程序员按键”，即代表上面列表中字形的按键，位于最容易使用的地方。扩展我们的字符集以允许复杂的字形将减慢输入新代码的过程，我们都知道打字速度是代码质量的最大指标。多年前，有一种名为 APL 的语言需要特殊的键盘。该语言大部分已经消亡；看看图 1 中的键盘，找出原因。

这就把我们带到了现在的处境，其中/表示一件事，而//表示另一件事。我非常确定许多错误将由此图像混淆而产生，并且我确信当处理代码的人刚刚被惊慌的电话从沉睡中唤醒时，这些错误将会发生。在大白天，很容易区分/和//，但在重新醒来的昏暗的光线下，就不那么容易了。

喜欢它，讨厌它？请告诉我们

[email protected]

KODE VICIOUS，凡人称为 George V. Neville-Neil，为乐趣和利润而从事网络和操作系统代码工作。他还教授有关编程相关主题的课程。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了位于马萨诸塞州波士顿的美国东北大学计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，目前居住在纽约市。

最初发表于 Queue 第 11 卷，第 1 期—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非密码散列函数的标准
尽管密码学和非密码学散列函数无处不在，但在它们的设计方式上似乎存在差距。密码学散列存在许多由各种安全要求驱动的标准，但在非密码学方面，存在一定程度的民间传说，尽管散列函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx in Action
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直觉上，技术领导者普遍认为良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发效率
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的反复无常的影响，并且可能会忘记或忽略某些永恒问题的久经考验的解决方案。用例，于 1986 年首次引入并在后来普及，是那些久经考验的解决方案之一。