Kode Vicious - @kode_vicious
PDFKode Vicious 循环往复
盛夏降临，带着它炎热和黏腻的光辉。正如一位读者提醒我们，过多的阳光会对程序员（以及那些撰写编程文章的人）产生奇怪的影响。为了逃避这种命运，许多人躲到室内，在工业级、大功率空调的凉爽环境中避暑。但这是一种虚假的避风港。起初感觉很好，但长时间暴露在这种环境中会产生有害影响，减缓大脑活动，使工作人员逐渐变得像冷冻人一样。这对程序员来说是灾难性的，他们会突然发现自己被最基本的任务难住。不过不用担心，Kode Vicious 了解这种感觉，并且可以用他独特的解冻大脑的智慧来帮助受困者。这肯定能让你摆脱僵化的状态。通过 [email protected] 联系他... 并把该死的空调调低！
Kode Vicious 收到了很多关于他三月份发表的“Kode Vicious Reloaded”专栏的反馈。特别是，许多人对 KV 给 “Driven to Abstraction” 的建议感到担忧。以下是一些信件和 KV 对这些信件的回应。
亲爱的 KV，
我喜欢你在 上关于编程的专栏，主要是因为文章结尾说你像我一样也是一个“狂热的自行车爱好者”。在加利福尼亚州，你居住的地方骑自行车，一定比在我居住的德国骑自行车有趣得多，因为你们那里总是天气晴朗。然而，过多的阳光有时会让你写出在我们老欧洲人看来很奇怪的专栏文章。在你的“Kode Vicious Reloaded”专栏（2005年3月）中，你给可怜的读者 “Driven to Abstraction” 的建议是“从问题的较小部分开始”，然后使用脚本语言来研究它们。
加利福尼亚不仅给你充足的阳光，显然那里的雇主也给你充足的时间去研究你喜欢的“小问题”，并使用与后续实现无关的编程语言。这可能很方便，但实际上先解决你喜欢的问题，然后再添加困难的、不喜欢的东西是非常危险的。例如：安全性——可以稍后添加吗？不行！阅读 George Brandman 在 “Patching the Enterprise” (, 2005年3月: 32-39) 中的认罪请求！性能——可以稍后添加吗？不行！看看所有沮丧的软件重构工程师的脸。
比我国家缺乏阳光更令人沮丧的是，当项目截止日期临近且预算已经超支时，雇主们不给你时间去研究脚本语言。我们被迫首先做出良好的总体设计，然后再迭代改进。哦，加利福尼亚——牛奶与蜜糖之地，以及阳光下骑自行车的地方！
程序员-用户-骑行者-教师 (KURT)
亲爱的 KV，
关于你建议 “Driven to Abstraction” 将 C++ 切换到 Python 来进行“简单”数据分析程序的评论，你提出的问题/答案场景存在两个问题
- 他不理解他被分配的问题，正如他在信的结尾令人困惑地表示“系统中有太多东西需要分析，每个都需要特殊情况”。因此，这并不简单。他对分配给他的问题理解不足。像这样的声明应该在他编写任何代码之前就提出。如果他花更多时间规划问题，他本可以避免一些尴尬。
- 然而，你在不了解他的任何情况细节的情况下，盲目建议他切换到另一种语言，同样是一种失职。听起来 “Driven to Distraction” 像是在锅炉房工作，周围没有人。解决方案，至少是教会他如何思考和设计。我提醒你，你是在为一个享有盛誉的国际专业“思想家”协会写作。
我的第一个建议是开发人员进行必要的预先思考和设计，以便他理解问题。如果他不理解问题是什么——即所涉及数据的特征以及如何分析它——那么解释性语言也好不到哪里去。“贪多嚼不烂” 的工程师不是在搞工程，而是在搞黑客。你建议的只不过是用不同的语言进行黑客行为，这是在迎合大众。真正的问题不是使用什么语言，而是编写代码之前缺乏思考。但是，如果我的猜测是正确的，团队和经理们没有时间做这些。你在给 “Driven to Distraction” 的回答中只是建议 “边写代码边思考”。我建议采用 IEEE/EAI 12207.0 标准，即开发过程。
KH
我亲爱的老欧洲人，
我要感谢你们两位写信给身处新世界的 KV，这里我们享受着充足的阳光和仁慈的雇主。当你们的信件到达时，我实际上正在办公室享受我的私人按摩师的按摩，但我把雅克遣走了，以便我可以全神贯注地回复你们。
我认为不幸的是，你们在我的原始回复中遗漏的是我建议 “Driven to Abstraction” 将问题分解成更小的、可能是小块的部分。虽然认为你可以预先指定程序的所有方面是很好的，但只有在你开始设计之前就理解了问题的所有部分，情况才是如此。我相信你们每个人都遇到过自己不完全理解的系统，并且为了掌握问题，你们不得不使用更小的模型和原型来理解问题并最终解决它。
过度规范系统和浪费时间玩弄子问题的脚本原型一样容易浪费大量时间，而且两者对于项目的成功都同样危险。然而，最危险的是日复一日地盯着同一个空白屏幕、笔记本页面或白板，而没有任何实际进展。告诉你的老板，“嗯，我上周都在思考这个问题，” 即使在牛奶与蜜糖之地，也是不可接受的。
我的建议旨在打破 “Distracted” 陷入的精神僵局，这相当于禅宗中的捏鼻子或用棍子敲一下。我认为在工作场所，告诉人们将较大的问题分解为较小的问题比四处走动捏他们的鼻子或用棍子敲打他们更容易接受。
KV
亲爱的 KV，
虽然我同意贪多嚼不烂不是一个好主意，但我对你对 “Driven to Abstraction” 问题的回应感到担忧。我担心你忠实的读者会认为不创建类是可以接受的。我见过太多所谓的面向对象程序只由一个类组成。我意识到你没有建议不添加类，但你也没有直接解决 “Driven to Abstraction” 对类的恐惧。
害怕那些害怕类的人
亲爱的 ATAC，
很高兴看到对我的 “Driven to Abstraction” 回应问题的另一种看法，对于这个看法我完全同意。就在两天前，我还在审查一些代码，这些代码显然是由一个要么害怕要么完全不了解类的人编写的。实际上，这位程序员似乎也不了解模块化的概念，因为所有内容都在一个 5000 行的文件中。从内部来看，代码非常巧妙，但就目前的状态而言，完全不可重用。现在轮到 KV 让代码更 “klassier”（更像类）。
不幸的是，这是一个我认为我们都面临的常见问题。要么是因为时间压力，要么是因为缺乏培训，程序员们决定不仅要贪多嚼不烂，还要吃下别人都咽不下的东西。
与世界上的许多事物一样，过大和过小之间存在一个范围。很多时候，人们只是为了自己编写代码，而没有意识到他们创建的所有东西都必须由其他人阅读和调试。如果我们能够改正我们自私的方式，也许我们都可以相处融洽。
KV
KODE VICIOUS，凡人称之为 George V. Neville-Neil，以网络和操作系统代码为乐，并以此营利。他还教授与编程相关的各种主题的课程。他的兴趣领域是代码探险、操作系统和重写你的烂代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，自 1990 年以来一直以旧金山为家。
最初发表于 Queue 第3卷，第6期—
在 数字图书馆 中评论本文
更多相关文章
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 年引入并在后来普及，就是这些成熟的解决方案之一。
© 保留所有权利。