Kode Vicious - @kode_vicious
PDFKode Vicious 释放
编码难题让你抓狂？同事让你发疯？不用担心，Kode Vicious 为你撑腰——解答你的疑问，解决你的难题，让世界变得更美好。
亲爱的 KV，
我的同事编写的方法长达 1,000 行，并声称这比将它们分解成更小的方法更容易理解。我们如何说服他，他的代码是维护噩梦？
抽象爱好者
亲爱的 FoA，
对于你的问题，简短的回答是让你同事永远维护他自己的代码，因为这应该就是足够的惩罚了。不幸的是，那些有恼人习惯的人，比如大声用手机说话、驾驶技术差劲或给出不必要的建议，很少能看到他们的错误。这就是为什么必须始终有像我们这样的正义捍卫者。
我注意到你使用了“方法”这个词，而不是“函数”，这表明你正在使用面向对象语言。在我们深入探讨之前，请允许我指出，我在这里所说的一切都适用于面向对象语言中的方法和非面向对象语言中的函数。基本问题是，太多的功能被塞在一个地方。可以提出几个论点来解释为什么如此过长的方法是有问题的。
首先想到的论点是代码重用。程序中拥有方法或函数的原因之一是为了捕捉单个想法或算法的本质，以便其他人可以轻松地重用它。当一个方法增长到 1,000 行时，它通常会变得高度专业化，只针对一项工作，而且这项工作可能并不经常需要。最好将较大的问题分解为较小的问题，其中一些问题可以被软件的其他部分重用。较小的、可重用的方法的另一个优点是，你可以在你工作的下一个项目中使用它们。可重用的方法对程序员有利，因为他们现在不必编写那么多代码，对程序员工作的公司也有利，因为他们现在可以更快地完成项目。这种避免工作是我做任何事情最喜欢的原因之一。
另一个论点是，过长的方法只是难以阅读和理解。一个 1,000 行的方法，如果在一个一次显示 50 行的窗口中查看，就相当于 20 页的代码需要阅读。现在，我不了解其他人，但 20 页的任何东西——书籍、杂志或代码——都很难消化，并且一次性全部记在我的脑海中。理解任何东西都需要上下文，而上下文应该是局部的。从第 18 页跳回到第 2 页，因为那是变量 fibble 最后一次被修改的地方，这常常让我迷失方向。我最终盯着第 2 页思考，“我为什么在这里？” 我变得目光呆滞，盯着太空，偶尔开始流口水，这让我的同事非常紧张。
最后，我们谈到你提出的关于代码维护的绝佳观点。显然，如果某些东西难以理解，正如我们刚刚在上段中确定的那样，那么它也将难以维护。一个 1,000 行的方法同时做了太多的事情。当一个方法同时做着相当于平衡你的支票簿、吹口哨唱《欢乐颂》和玩杂耍链锯的事情时，你如何找到其中的错误？更糟糕的是，一段代码中可能存在的副作用数量会随着你添加的每一行代码而增加——也许不是呈指数级增长，但肯定超过线性增长。
有一些方法可以让你的同事走上编写整洁代码的正道，即使不是过上清洁的生活。一种方法是提出这组论点，看看你的同事如何回应。使用中立第三方的代码作为示例是避免“我比你更优秀的程序员”的争吵的好方法，这种争吵很少能让任何人站在你这边。如果理性的论证失败了，你可以尝试使用软件规范作为一种方法，从这个人那里获得合理大小的功能块。你们确实有软件规范，对吧？如果它清楚地说明了每个方法要完成的工作量，那么当你的同事违反规范时，就会非常清楚，然后你就可以尽可能严厉地批评他。
当然，有时合理的论证（即胡萝卜）和直接控制（即大棒）都会失败。在那时，我推荐一些持久的，用沸油或熔化的铅。只是不要告诉国际特赦组织——尽管如果他们不得不维护你同事的代码，他们可能会理解。
KV
亲爱的 Kode Vicious，
关于你编码痛点 2，代码赘疣（“Kode Vicious 再次出击”，2004 年 11 月），我同意清理掉未使用的代码更好。我经常注释掉被修改后的代码替换的区域，因为我可能想以后记住我是如何做某事的。将它放在源代码控制系统中是个好主意，但是多年后你如何记住它在哪个版本中呢？
短期记忆
亲爱的 STM，
我不确定你正在使用什么源代码控制系统，但我在过去 10 年中使用过的所有系统都能够为每次签入存储注释。一旦存储，也可以检索此签入注释。当我在查看一段已经从我的记忆中褪色的代码时——例如，在一次特别好的派对之前的星期五签入的代码——我会获取该文件的完整历史记录，并扫描它，寻找我或其他人在进行各种更改时的想法的蛛丝马迹。我相信，STM，你在签入代码时会添加适当的注释，但我也相信，有很多读者可以从我对另一个痛点的简短抨击中受益。
糟糕的签入注释是一个没有进入我的前五名的痛点，但它们肯定在我的前十名中。多年前，我实际上与一位工程师共事，他拒绝在签入代码时添加任何注释。这完全符合他的性格，因为他在工作时一天也很少说超过 10 个字的话，并且用“是”或“否”回答所有问题。最终，团队安装了一个触发器，要求在签入任何文件之前，必须在任何注释中至少输入三个单词。如果注释为空，则拒绝签入。老实说，这并没有对我们有太大帮助，因为我们随后得到了诸如：添加了新功能或修复了错误 511 之类的注释。
虽然我考虑过对这位特殊的工程师施用拇指夹，但我被告知，至少在美国，这不是一种现代商业惯例。在经历了几年这种疯狂之后，这位工程师离开了公司。尽管他是一位非常优秀的程序员，但他的软件也有错误，就像我们任何人的软件一样。主要的区别在于，修复这个人做过的任何事情都是一场噩梦，因为所有代码都没有任何上下文。代码中存在令人难以置信的糟糕注释，这是一个已经解决的痛点，并且签入轨迹没有告诉你任何关于代码演变的信息。
签入注释与代码中的注释受到相同的限制。首先，实际上应该有一个注释。就我而言，所有源代码控制系统都应该强制工程师在签入时包含注释。如果可以向那些在没有注释的情况下签入代码的人的键盘传递电击，我也会安装它。其次，注释必须有用。对我共事的工程师施加的至少三个单词的规定显然是不够的。我认为，如果你修复了一个微不足道的错误，那么你应该包含一个完整的句子，说明错误编号是什么，以便以后可以查找，问题最终是什么，以及你是如何修复它的。简洁可能是智慧的灵魂，但除非你是奥斯卡·王尔德（而且他已经死了，所以你显然不是），否则你至少需要三个完整的句子才能满足我的标准。当然，当你添加更重要的东西时，例如新功能，那么你需要一整段来描述该功能是什么，它是如何工作的以及如何使用它。
我相信我会收到投诉，认为有更好的地方可以存储此类信息。错误信息应该在错误数据库中，功能信息应该在规范中。没错，但是当我打开一段代码时，我希望在一个地方获得尽可能多的信息。我不希望不得不在错误数据库窗口、规范的电子版和我的代码之间切换。所以，拜托，下次你将某些东西签入到你的源代码控制系统时，假装我正拿着电牛棒站在你身后，并仔细考虑你即将写些什么。
KV
KODE VICIOUS，凡人称之为 George V. Neville-Neil，为乐趣和利润从事网络和操作系统代码方面的工作。他的兴趣领域是代码探险、操作系统和重写你的烂代码（好吧，也许不是最后一个）。他是一位狂热的自行车爱好者和旅行者，自 1990 年以来一直以旧金山为家。
有问题要问 Kode Vicious 吗？发送电子邮件至 [email protected]——如果你敢！如果你的信件在印刷版上出现，他甚至可能会送你一个 Queue 咖啡杯，如果他心情好的话。哦，对了，我们会出于内容、风格以及为了你好而编辑信件！
最初发表于 Queue 第 3 卷，第 1 期—
在 数字图书馆 中评论本文
更多相关文章
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 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。在其快速前进的步伐中，它容易受到时尚的 whims 的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的经过验证的解决方案。用例，于 1986 年首次引入，并在之后推广，就是这些经过验证的解决方案之一。
© 公司，版权所有。