Kode Vicious - @kode_vicious
PDFKode Vicious 即兴
有些月份，当 Kode Vicious 兴致勃勃时，他会仔细阅读你们的所有来信，为了回复哪封信件而苦恼数日。然而，大多数时候，他会采取一种不太严谨的方式。这通常包括将信件打印出来，扔到空中，看看哪封信件正面朝上，然后重复这个过程，直到只剩下两封信件。偶尔，KV 也会完全不理会读者的反馈，就像本月的情况一样。不过不用担心，他仍然喜欢阅读和回复你们每月的代码问题，所以请继续发送到 [email protected]。
问候，
你知道，有时候我真的不需要阅读邮件就能开始谈论一个话题；有时候我只需要阅读一点代码。我很抱歉我不能与你分享代码，因为它属于专有代码，但这引出了 Kode Vicious 非常讨厌的长长清单中的另外两项。我越想这件事，就越意识到这只是一个大问题，它有很多不同的表现形式。
问题是什么？计算机让复制数据变得太容易了。是的，我知道你们都期待我抨击糟糕的注释或文档质量，但实际上，这只是因为计算机在它们被设计用来做的事情上做得太好了。我想我真的不应该责怪计算机；我应该责怪键盘后面的白痴，但是对机器发脾气比对人发脾气更容易接受。毕竟，你可能不会因为把电脑扔出窗外而被捕，除非它砸到街上的人，但是你可以肯定，把同事扔出窗外，即使当时感觉很好，也会有后果。为了阐明我所咆哮的内容，让我给你讲一个我今天发生的故事。
今天开始的时候天气很好，鸟儿在歌唱，阳光明媚，一切都... 哦，算了！今天我在查看一位程序员对一些处理 C++ 字符串和 C char* 缓冲区的代码所做的修复。代码中有一个错误，当字符串放入缓冲区时，没有正确终止，导致一些数据泄漏到系统的其他部分。很好，指针和字符串是难以对付的野兽，是许多程序错误的已知来源。所以，带着我通常的中午咖啡因水平——也就是说，差一点就要把牙齿磨成粉末——我决定检查这些修复。
我打开编辑器，查看了其中一个已更改的文件，尽管代码本身让我感到不舒服，但我只是来查看的，不想陷入重新修改修复的困境。检查完第一个更改后，我继续检查下一个更改，它看起来像是第一个更改的副本。好吧，这没问题，几个地方不是问题。我移动到下一个差异，它也与前两个相同。我想你可以看到这是怎么回事。我检查了超过 10 个更改。同一个错误出现在超过 10 个地方，在一个只有大约 200 个文件的程序中，为什么？因为编写第一个有错误代码版本的人只是简单地一遍又一遍地复制了这个错误。我正在谈论的代码不仅仅是对某个函数的单行调用；这是 15 行代码，它正在处理一个已知的危险量，一个指向缓冲区的指针，这是错误的常见来源。
所以，现在我们来到了第一个烦恼：在到处复制和粘贴代码的能力。我不想说“永远不要剪切和粘贴代码！”因为如此强烈的声明没有考虑到足够多的情况，但我可以说，“在您剪切和粘贴代码之前，请思考！”您看，很多年前，在您或我，或许多阅读本文的人出生之前，一些非常好的人发明了函数调用，然后在 1951 年发明了库。似乎大多数人认为库是由其他人提供的，而不是由他们自己提供的。众所周知，函数调用是简化重复性工作的一种方式。与其用 10 行或 20 行，是的，我见过这种情况，100 行代码在您的软件中到处复制和粘贴做同样的事情，不如简单地说：“哦，看，这段代码一次又一次地被使用，我敢打赌它通常很有用。”然后您取出该代码，将其放入函数中，将该函数放入库中，并与您的所有同事共享，他们因此可以从您的天才中受益。就像妈妈在我们小时候说的那样，“分享是好的！”
现在，不幸的是，故事并没有到此结束。正是在像今天这样的日子里，我实际上为坐在我附近的人感到抱歉，因为尽管我已经学会了控制在办公室里使用极其粗俗的语言，但人们仍然觉得我的头撞击桌子的声音有点令人不安。正是这种声音引来了我邻居通常的“又怎么了？”的询问，他们偶尔会被我的咆哮逗乐，只要我停止用头撞击桌子。
我完全偶然地发现了一个当前产品的整个子目录，其中包含我正在检查的产品的文件子集。似乎为了制作一个新产品，有人只是复制了旧产品，然后开始编辑它。现在，不仅在我应该检查的代码中有 10 多个错误，而且在某人复制以制作其新产品的代码中也有相同的错误。但是等等！还有更多！新产品没有保留所有旧代码；不，它保留了许多 API，但巧妙地更改了它们的底层含义，在这里添加了一些新常量，在那里更改了一个返回值。在一个文件中，即导致我做出这个可疑发现的文件中，有 200 多个单独的更改——不够显着，以至于与错误库链接的人会得到明显的错误；哦，不，只够让代码以奇怪和神秘的方式崩溃。
所以，现在我们有两个不同的问题是由复制的容易性引起的。第一个问题是在危险的、处理指针的代码中复制错误，这些错误现在必须在一个产品的 10 多个地方进行维护。第二个问题是复制整个产品，包括所有错误，以及两个相关但又足够微妙不同的产品，以至于在一个产品中修复错误需要在另一个产品中手动修复错误。
我只能想，“这些人当时在想什么？”我的意思是，是的，对于我们这些使用类 Unix 系统的人来说，输入 cp -r OldProduct NewProduct 然后立即开始工作非常容易。看看我们节省了多少时间！我们肯定会因为我们的生产力而获得加薪，而不是被踢一脚，这才是我们应得的。对于那些心中有桌面隐喻的人来说，这只是点击一下，甚至比我们这些使用 Unix 的人所需的 28 个字符（包括“Enter”）输入的工作量还要少。但是，这不是重点；重点是软件是由库和函数组成的，这是有原因的，当您遇到您需要的东西时，您应该尝试使您自己和他人都容易重复使用它。从长远来看，它将比您盲目复制代码或文件节省更多时间。如果您与我一起工作，它也可能使您免于被扔出窗外。是的，这就是今天的词：defenestration（扔出窗外）。查一下！
KODE VICIOUS，凡人称之为 George V. Neville-Neil，以网络和操作系统代码为乐和营利。他还教授有关编程相关主题的课程。他的兴趣领域是代码探险、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，自 1990 年以来一直以旧金山为家。
最初发表于 Queue 第 3 卷，第 8 期—
在 数字图书馆 中评论这篇文章
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。加密哈希存在许多由各种安全要求驱动的标准，但在非加密方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直观地说，技术领导者普遍接受良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，为改善 DevEx 而提出的倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和方法来服务于商业和社会，但它也很健忘。在它匆忙前进的过程中，它容易受到时尚的支配，并且可能会忘记或忽略已证实的解决它所面临的一些永恒问题的方法。用例最初于 1986 年引入，后来普及，是这些经过验证的解决方案之一。
© 保留所有权利。