改造：原则与实践
将全新的功能改造到生产软件上，考验着程序员的每一项技能。一个实际的案例研究阐明了将新技巧应用于旧系统的原则。
不想要的惊喜
当那个玩笑般的 API 落在你头上时
这里有一个更高层次的问题，即使用强制转换的松散类型语言是否从一开始就是一个好主意。如果你不知道你在操作什么，或者预期的输出范围可能是多少，那么也许你一开始就不应该操作这些数据。但是现在这些语言已经进入了野外，我们永远无法及时地追捕并杀死它们，这既不符合我的喜好，也不符合更大利益。
质疑评估非加密哈希函数的标准
也许我们需要更多地思考非加密哈希函数。
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全要求驱动的加密哈希标准，但在非加密方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
应对技术债务的工作模型
了解各种选项，定制适合您需求的方法
请记住，并非所有债务都是坏事，有时，实际上，战略性技术债务甚至可以用作实现某些业务目标的宝贵工具——就像可以承担金融债务以获得可以投资于其他盈利事业的资本一样。例如，如果能够让公司从客户反馈中学习，然后相应地迭代产品，那么为了快速将产品推向市场而走捷径可能被证明是一个明智的决定。
对偏见零容忍
从赌博到军事征兵，随机化做出了至关重要的现实世界决策。事关重大，公平性不容谈判。不幸的是，糟糕的建议和有偏见的方法比比皆是。我们将学习如何避开虚假信息，开发可靠的方法，并为设计和代码审查编制清单。
构建成功
软件结构的问题在于，人们在真正需要它之前，并不会真正学习它。
软件结构的问题在于，人们在真正需要它之前，并不会真正学习它，而你的家庭作业将不得不迫使他们仔细审视他们如何解决问题，不仅通过算法，而且通过结构。
跑两趟
拉里·戴维的新年决心也适用于 IT 领域。
无论你的项目是像把杂货搬进屋子这样简单，还是像多年的工程项目那样复杂，“跑两趟”都可以简化项目，减少出错的机会，提高成功的概率，并使解释更容易。
采用和维持基于微服务的软件开发的挑战
组织挑战可能比技术挑战更困难。
MS（微服务）已成为软件开发中最新的流行语。MS 软件开发方法为传统的单体架构风格提供了另一种选择。虽然基于 MS 的开发相对于单体架构风格的优势显而易见，但行业专家一致认为，这两种风格在所有情况下都不具备绝对优势。支持者认为，MS 软件开发方法更容易促进将组织变革（体现出更具活力的商业环境）映射到相应的 IT/IS（信息技术/信息系统）变革。本文确定了从最初决定采用 MS 到长期维持新范式的持续任务中的关键挑战。
DevEx 在行动
对其有形影响的研究
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
亲爱的日记
关于保留实验室笔记本
虽然调试日志很有帮助，但它与实验室笔记本不同。如果更多的计算机科学家像科学家一样行事，我们就不会为计算是艺术还是科学而争论不休。
低代码开发生产力
“代码技术的冬天要来了”吗？
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。低代码技术显然显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。
用例至关重要
用例提供了一种经过验证的方法，以简洁易懂的格式捕获和解释系统需求。
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和技巧不断涌现，为商业和社会服务，但它也很健忘。在快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略解决其面临的一些永恒问题的经过验证的解决方案。用例于 1986 年首次引入，后来得到普及，就是这些经过验证的解决方案之一。
OCCAM-v2：结合静态和动态分析以实现有效且高效的程序整体特化
利用可扩展的指针分析、值分析和动态分析
OCCAM-v2 利用可扩展的指针分析、值分析和动态分析来创建一个有效且高效的工具，用于特化 LLVM 位代码。代码大小缩减的程度取决于具体的部署配置。每个要特化的应用程序都附带一个清单，其中指定了先验已知的具体参数，以及运行时将提供的剩余参数的计数。部分求值的最佳情况发生在参数完全具体指定时。OCCAM-v2 使用指针分析来反虚函数调用，从而可以消除任何直接调用都无法访问的函数的整个主体。
病态软件项目的四骑士
不要让苍白的骑士用异常抓住你。
KV 在过去的专栏中谈到了各种软件质量衡量标准，但也许软件质量下降是一个团队正在失败的最客观的衡量标准之一。这种瘟疫是由战争和饥荒给团队带来的士气低落造成的，这清楚地表明出了问题。在现实世界中，可以剔除患病的动物，这样疾病就不会蔓延并在陆地上蔓延成瘟疫。错误计数的增加，尤其是在没有功能增加的情况下，是即将到来的项目灾难的明确迹象。
物联网、TLS 和现实世界中随机数生成器的挑战
糟糕的随机数仍然伴随着我们，并在现代系统中扩散。
密码学界的许多人嘲笑在实现 RNG 时犯下的错误。许多密码学家和 IETF 成员抵制使 TLS 更能抵抗此类故障的呼吁。本文讨论了 TLS 协议的历史、现状和脆弱性，最后举例说明了如何改进该协议。目标不是提出解决方案，而是开始对话，通过证明在没有完美随机数假设的情况下 TLS 的安全性是可能的，从而使 TLS 更具弹性。
线性地址空间
任何速度下都不安全
线性地址空间作为一个概念在任何速度下都不安全，它非常需要强制性的 CHERI 安全带。但更好的做法是完全摆脱线性地址空间，回到过去，就像 30 多年前在 Rational R1000 计算机中成功实施的那样。
软件彩蛋万岁！
这是一个动荡的时期。叛军开发者从持续部署服务器发起进攻，赢得了他们的第一次胜利。在战斗中，叛军间谍设法在 https://pro.sony 的 HTML 代码中推送了一个史诗级的提交。在邪恶特工的追捕下，叛军藏身于提交、按钮、工具提示、API、HTTP 标头和配置屏幕中。
中间件 101
现在和未来需要了解什么
无论是将复杂的软件组件分隔成更小的服务，在计算机之间传输数据，还是为无缝通信创建通用网关，您都可以依靠中间件来实现不同设备、应用程序和软件层之间的通信。随着敏捷运动的兴起，科技行业已经采用了快速瀑布模型来为每个结构需求创建层叠堆栈，包括集成、通信、数据和安全。鉴于此范围，现在的重点必须放在端点连接和敏捷开发上。这意味着中间件不应仅仅充当执行简单请求-响应命令的面向对象的解决方案。
计算机程序中的意义和上下文
使用源代码作为媒介在程序员之间共享领域知识
当您查看函数程序的源代码时，您如何知道它的含义？意义是在函数的返回值中找到，还是位于函数体内部？函数名呢？回答这些问题对于理解如何使用源代码作为媒介在程序员之间共享领域知识非常重要。程序是程序员之间交流以分享其解决方案的媒介。
静态分析工具的 UI 设计
使用 SWAN 评估工具设计指南
静态分析工具存在可用性问题，例如误报率高、响应速度慢以及警告描述和分类不明确。在这里，我们探讨了将以用户为中心的方法和设计指南应用于 SWAN（一种面向 Swift 编程语言的安全静态分析工具）的效果。SWAN 是探索静态分析工具可用性的一个有趣的案例研究，因为它面向广泛的目标受众，具有轻松集成到开发者工作流程中的潜力，并且独立于现有的分析平台。
以人为中心的静态分析驱动的开发者工具方法
未来取决于良好的人机交互
复杂且不透明的系统不容易扩展。以人为中心的方法来发展工具和实践对于确保软件安全可靠地扩展至关重要。静态分析可以揭示有关程序行为的信息，但是导出此信息的目的不应是积累吹毛求疵的细节。HCI 可以帮助指导静态分析技术进入面向开发者的系统，这些系统可以构建信息，并将关系体现在与程序员思维密切相关的表示形式中。伟大软件的生存取决于支持而非抑制沟通、推理和抽象思维的编程语言。
GitHub 的静态分析
一份经验报告
GitHub 的 Semantic Code 团队构建并运营一套技术，为 github.com 上的符号代码导航提供支持。我们了解到，规模与采用率、用户行为、增量改进和实用性有关。特别是静态分析很难根据人类行为进行扩展；我们通常认为复杂的分析工具致力于查找代码中潜在的问题模式，然后试图说服人类修复它们。
静态分析：简介
软件工程的根本挑战之一是复杂性。
现代静态分析工具为代码库提供了强大而具体的见解。例如，Linux 内核团队开发了 Coccinelle，这是一种用于搜索、分析和重写 C 源代码的强大工具；由于 Linux 内核包含超过 2700 万行代码，因此静态分析工具对于查找错误和对其众多库和模块进行自动化更改都至关重要。另一种针对 C 语言系列的工具是 Clang scan-build，它带有许多有用的分析功能，并为程序员提供了编写自己的分析的 API。就像计算机科学中的许多事情一样，静态分析的实用性是自指的：为了编写可靠的程序，我们也必须为我们的程序编写程序。
赞美反汇编器
从硬件的较低级别细节中可以学到很多东西。
当您刚开始时，您希望尽可能将整个程序保存在您的头脑中。一旦您熟悉了您的第一种简单汇编语言和您正在使用的机器架构，您将完全有可能查看一两页汇编代码，不仅知道它应该做什么，而且知道机器将为您逐步做什么。当您查看高级语言时，您应该能够理解您希望它做什么，但通常您不知道您的意图将如何转化为行动。
薛定谔的代码
理论和实践中的未定义行为
未定义行为在流行的编程语言中最令人困惑和危险的方面中排名靠前。《钻头》专栏的这一期澄清了广泛的误解，并介绍了从您自己的代码中消除未定义行为并查明任何软件中的无意义操作的实用技术——这些技术揭示了在财富 500 强公司支持关键业务应用程序的软件中令人震惊的缺陷。
动荡时期的软件开发
使用快速决策能力、敏捷项目管理和极端低代码技术创建软件解决方案
在这个项目中，挑战是“以比冠状病毒传播更快的速度部署软件”。在一个具有如此特殊特征的项目中，有几个因素会影响成功，但有些因素显然很突出：高层管理人员的支持、敏捷性、项目团队的理解和承诺以及所使用的技术。传统的开发方法和技术根本无法及时满足要求。
厌恶版本
解决代码依赖性问题
永远不应在代码本身内部硬编码版本或路径。代码需要具有灵活性，以便它可以安装在任何地方并在任何地方运行，只要必要的依赖项可以在构建时（对于静态编译的代码）或运行时（对于解释型代码或带有动态链接库的代码）解析即可。目前，有一些正确的方法可以做到这一点，但令人遗憾的是，很多人仍然做错了。
开发者生产力的 SPACE
它比你想象的要复杂。
开发者生产力不仅仅关乎个人的活动水平或用于交付软件的工程系统的效率，它也不能用单一指标或维度来衡量。SPACE 框架捕获了生产力的不同维度，在这里，我们演示了如何使用此框架来理解实践中的生产力，以及为什么使用它将帮助团队更好地理解开发者生产力，并创建更好的衡量标准来指导他们的工作和团队。
低频交易中的离线算法
清算组合拍卖
人们对做出现实世界决策的软件抱有很高的期望，尤其是在金钱攸关的情况下。《钻头》专栏的第三集展示了精心设计的软件如何通过优化组合拍卖中的交易收益来有效地创造财富。我们将揭示拍卖与经典的教科书问题之间的深刻联系，我们将看到清算拍卖类似于高风险的变异俄罗斯方块，我们将学会停止担心并热爱在实践中远非棘手的 NP 难问题，并且我们将把组合拍卖的深思熟虑的业务与高频交易的近乎实时的喧嚣进行对比。
最佳实践：应用程序框架
虽然功能强大，但框架并非适合所有人。
虽然框架可能是一个强大的工具，但它们也有一些缺点，并且可能并不适合所有组织。框架维护者需要提供标准化和明确定义的行为，同时又不会过于规范。但是，当框架达到适当的平衡时，它们可以为开发者带来巨大的生产力提升。框架的广泛使用所提供的一致性对于其他团队（例如 SRE 和安全团队）来说是一种福音，这些团队对应用程序的质量具有既得利益。此外，框架的结构为构建更高级别的抽象（例如微服务平台）奠定了基础，从而为系统架构和自动化开辟了新的机会。
超凡脱俗的增材制造
从奇特的小玩意到火箭，3D 打印有多种形式。
流行文化使用术语 3D 打印作为增材制造工艺的同义词。2010 年，美国材料与试验协会小组提出了一套标准，将增材制造工艺分为七类。每个工艺使用不同的材料和机器技术，这会影响用例和应用，以及经济性。为了购买最好的 3D 打印机，我深入研究了各种工艺。
移除 Kode
死函数和死功能
从系统中删除死代码是 KV 最喜欢的编码消遣之一，因为没有什么比当你摆脱你确信没有被使用的东西时所获得的感觉更棒的了。代码删除就像打扫房子，只是有时你会用火焰喷射器打扫房子，说实话，这非常令人满意。由于您正在使用版本控制系统（您最好正在使用 VCS！），因此可以非常轻松地删除代码而无需担心。如果您曾经需要删除的代码，您可以随时从 VCS 中检索它。
委员会如何发明？以及自动化的讽刺意味
康威定律的制定以及自动化水平提高的反直觉后果
林迪效应告诉我们，如果一篇论文长期以来一直非常重要，那么它在未来很长一段时间内也可能继续如此。我的首选是“委员会如何发明？” 作者 Melvin E. Conway 提供了许多伟大的素材，这些素材促成了以他的名字命名的定律的制定。我的第二个选择是 Lisanne Bainbridge 的“自动化的讽刺意味”。这是关于自动化水平提高的反直觉后果的经典论文。
超越修复性事务
高性能组织中事件后工件的使用
鉴于人类对安全社会学因素的研究已有近一个世纪的历史，技术行业的事件后分析实践以及我们如何创建和使用这些实践产生的工件仍处于起步阶段。因此，不要惊讶于许多这些实践如此相似，用于解析和理解事件和中断的认知和社会模型很少且固化在操作理念中，并且从事件后分析中寻求的副产品远远地侧重于补救项目和预防。
管理协调的隐性成本
当多个分布式视角至关重要时，控制协调成本
控制事件响应者的认知成本的一些初步考虑因素包括：（1）评估相对于事件认知需求的协调策略；（2）认识到适应代表多种竞争需求（协调和认知工作）之间的张力，并寻求更好地理解它们，而不是单方面消除它们；（3）扩大镜头以研究联合认知系统（人机能力集成）作为分析单元；以及（4）将联合活动视为在组织间和组织内边界之间实现互惠的机会。
异常响应期间的假设探索的认知工作
看看我们如何应对意外
来自基于 Web 的软件公司的四个事件揭示了 Web 运营中发生事件时异常响应过程的重要方面，本文讨论了其中两个方面。详细检查的一个特定认知功能是假设生成和探索，考虑到模糊自动化对工程师开发他们管理的系统的连贯模型的影响。使用认知系统工程的技术和概念分析了每个案例。这组案例为了解复杂 Web 运营系统的事件管理中“线上”的认知工作提供了一个窗口。
线上，线下
面向互联网的系统的弹性依赖于表示线以上的内容。
对线下结构和功能的知识和理解不断变化。需要不断努力来校准和刷新对那里存在的运作方式、依赖关系、限制和能力的理解。在这种动态情况下，任何个人或群体都永远无法了解系统状态。相反，个人和群体必须满足于部分、零散的心理模型，如果要使这些模型有用，则需要或多或少地不断更新和调整。
揭示人为因素在软件中的关键作用
现在是时候重新评估我们对面向互联网的软件系统的人为方面的认识了。
理解、支持和维持表示线以上的能力需要所有利益相关者都能够不断更新和修改他们对系统如何混乱但通常设法工作的模型。这种持续重新审视系统实际工作方式的开放性需要扩大从事件中学习的努力。
软件工程中的速度
从构造板块到 F-16
软件工程在各行各业的公司中都扮演着越来越重要的角色，但太多的软件计划最终都偏离目标并超出预算。更可靠的路径是针对速度进行优化，对实验和学习持开放态度，敏捷，并接受定期纠正。好的想法往往是丰富的，但高速执行是难以捉摸的。好消息是速度是可控的；公司可以系统地投资以提高速度。
在软件依赖项中生存
软件重用终于来了，但也带来了风险。
软件重用终于来了，其好处不应被低估，但我们接受了这种转变，而没有完全考虑潜在的后果。Copay 和 Equifax 攻击清楚地警告了当今软件依赖项消费方式中的实际问题。那里有很多优秀的软件。让我们共同努力，找出如何安全地重用它。
必须和不得
关于编写文档
没有背景或解释材料的声明对于那些没有深入研究计算机安全或一般安全艺术和科学的人来说是无用的。像攻击者和防御者一样思考需要一种特殊的思维方式，而大多数人都没有能力做到这一点；因此，如果您希望阅读文档的人遵循您的指导，那么您必须带领他们从无知走向知识。
DevOps 现象
高管速成课程
对于采用 DevOps 软件开发和交付方法的公司来说，压力大的紧急发布已成为过去。新版本频繁发布。错误得到快速修复。新的商机以极大的热情和信心寻求。新功能通过快速迭代发布、修订和改进。与传统的软件开发方法相比，DevOps 为组织带来了战略优势。领导力在该转型过程中起着重要作用。DevOps 旨在为新软件功能的更快上市时间和实现更高水平的稳定性提供指导。实施跨职能、以产品为导向的团队有助于弥合软件开发和运营之间的差距。
行业级知识图谱：经验和挑战
五家不同的科技公司展示了如何做到这一点
本文着眼于五家不同科技公司的知识图谱，比较了他们在构建和使用图谱方面的各自经验的异同，并讨论了当今所有知识驱动型企业面临的挑战。此处讨论的知识图谱集合涵盖了广泛的应用，从搜索到产品描述再到社交网络。
有史以来最糟糕的主意
100 期揭秘！
2004 年 2 月，我和 Queue 编辑委员会的其他成员一起参加了我们的每月一次的面对面晚宴会议，我们在会上集思广益，提出有趣的讨论主题，这些主题将产生面向从业者的文章（以及撰写这些文章的最佳作者），以便在 Queue 中发表。这只是我们创业的第二年，尽管我们已经发表了一些成功且广为阅读的文章，但 Queue 仍然没有固定的专栏作家。我最初是由另一位编辑委员会成员 Eric Allman 邀请参加董事会会议的，并且为该出版物撰写了几篇文章。我也是我的第一本书的合著者，但从未担任过专栏作家。
SageDB 和 NetAccel
数据库系统中的学习模型；网络加速的查询处理
CIDR（创新数据系统研究会议）每两年举办一次，对我们来说幸运的是，2019 年是其中一年。我从今年的会议中选择了两篇论文，突出了数据系统的大胆而令人兴奋的方向。
了解你的算法
停止使用硬件来解决软件问题。
知道你的 CPU 使用率达到 100% 并不能告诉你关于整个系统的太多信息，除了它很忙，但是忙什么呢？也许它正处于一个死循环中，或者某个小丑在测试期间添加了一堆不再需要的延迟循环。在分析你的系统之前，你不知道 CPU 为什么忙。所有系统都提供某种形式的分析，以便你可以追踪瓶颈在哪里，在花费金钱购买全新的硬件之前，应用这些工具是你的责任。
拆除方法监狱！释放实践！
Essence：一种新的思维方式，有望解放实践并实现真正的学习型组织
本文解释了为什么我们需要摆脱这种重复的、功能失调的行为，并介绍了 Essence，这是一种新的思维方式，有望将实践从其方法监狱中解放出来，从而实现真正的学习型组织。
GitOps：通往更多自助式 IT 的道路
IaC + PR = GitOps
GitOps 降低了创建常用 IT 流程自助服务版本的门槛，使其更容易达到投资回报率计算中的回报。GitOps 不仅实现了这一点，而且还鼓励了 IT 系统中期望的行为：更好的测试、降低巴士系数、减少等待时间、更多基础设施逻辑通过 IaC 以编程方式处理，以及将时间从手动苦工转移到创建和维护自动化上。
手动工作是一个 Bug
A.B.A：始终自动化
每个 IT 团队都应该拥有持续改进的文化——或者朝着自动化目标的路径前进，即自动化团队有信心自动化的任何事物，并以易于随着条件变化而变化的方式进行自动化。随着指针向右移动，团队从彼此的经验中学习，系统变得更容易创建和更安全地运行。一个优秀的团队拥有一个使流程顺畅且协作的结构。
持续交付听起来很棒，但在这里可行吗？
这不是魔法，它只需要在各个层面上持续的、每天的改进。
持续交付是一套旨在使部署变得可预测、日常化，并且可以随时按需执行的原则、模式和实践。本文介绍了持续交付，提出了对实施它的常见异议和实际障碍，并描述了如何使用真实案例克服它们。持续交付不是魔法。它关乎组织各个层面上持续的、每天的改进。
DevOps 指标
你最大的错误可能是收集了错误的数据。
通过软件为业务交付价值需要流程和协调，这些流程和协调通常跨越复杂系统中的多个团队，并涉及开发和交付具有质量和弹性的软件。作为从业者和专业人士，我们知道软件开发和交付是一门日益困难的艺术和实践，并且管理和改进任何流程或系统都需要深入了解该系统。因此，衡量对于创建有效的软件价值流至关重要。然而，准确的衡量绝非易事。
爆米花内核
在内核或用户空间中进行编程之间的选择
在一个高性能代码继续以花哨的汇编程序（又名 C）编写的世界中，没有内存安全和大量其他风险，唯一的补救措施是坚持软件工程基础知识。减少危险代码的数量，保持子系统之间高效且显式的耦合，并努力为这项工作提供更好的工具，例如静态代码检查器和大型运行时测试套件。
愚人节恶作剧中的卓越运营
搞笑是一项严肃的工作。
成功的恶作剧需要细心和计划。编写设计提案和项目计划。尽早让运营部门参与进来。如果这是对您网站的技术更改，请执行负载测试，最好包括“暗启动”或隐藏启动测试。将恶作剧隐藏在功能标志后面，而不是需要新的软件版本。进行回顾并广泛发布结果。请记住，一些最好的恶作剧几乎不需要任何技术更改。例如，可以简单地总结启动任何新功能的最佳实践，但将其写成如何启动愚人节恶作剧的指南。
物联网是否有一种单一方法？
Essence 可以防止物联网的软件开发变得难以控制。
工业互联网联盟预测，物联网（Internet of Things）将成为继工业革命和互联网革命之后的第三次技术革命。它对所有行业和企业的影响几乎难以想象。现有的软件（商业、电信、航空航天、国防等）预计将被修改或重新设计，并且必须开发大量解决新问题的新软件。因此，软件行业应该欢迎新的和更好的方法。
实践研究：面向服务欠缺社区的技术；个人制造
专家策划的 CS 研究最佳指南
本期《实践研究》提供了面向服务欠缺社区的技术和个人制造新进展的精选阅读指南。首先，Tawanna Dillahunt 描述了面向服务欠缺和贫困社区的设计考虑因素和技术。为全球超过 16 亿贫困人口进行设计需要特别考虑社区需求、约束和环境。Tawanna 的选择涵盖了低质量通信网络的协议、社区驱动的内容生成以及资源和公共服务发现。其次，Stefanie Mueller 和 Patrick Baudisch 概述了个人制造（例如，3D 打印机）的最新进展。他们的选择涵盖了制造（和模拟）复杂材料（例如，通过操纵物体的内部结构）、更轻松地指定物体形状和行为以及人为循环快速原型设计的新技术。
副作用，居于中心！
一个系统的副作用是另一个系统的肉和土豆。
我们从计算的后果来考虑计算。大型 MapReduce 作业返回一个大型结果。Web 交互显示信息。企业应用程序更新数据库并返回答案。这些是我们进行工作的理由。我们很少讨论的是进行我们打算进行的工作的副作用。副作用可能是不受欢迎的，或者它们实际上可能在系统的不同层引起期望的行为。本专栏指出了一些有趣的模式，在我们构建和使用系统时要牢记这些模式。
有人听你的吗？
你如何从单纯的贡献者跃升为真正的变革者？
一个想法本身并不值钱。仅仅因为你认为你知道更好的做事方式，即使你是对的，也没有人有义务关心。在工作中取得伟大的成就不仅仅是聪明。好的想法的成功或失败取决于你将它们正确地传达给有权实现它们的人的能力。当你在组织中导航时，了解与谁交谈以及如何联系他们是值得的。这是一个将你的想法向上级传达并使其真正实现的简单指南。
解决冲突
不要“赢”。解决。
我对冲突感到矛盾。一方面，我讨厌它。听到人们不同意，即使是关于小事，也让我想要撞穿最近的墙，然后蜷缩在床底下直到结束。另一方面，当它发生时，我总是想参与其中。
工业规模的敏捷 - 从工艺到工程
Essence 在推动软件开发朝着真正的工程学科发展方面发挥了重要作用。
有很多很多方法可以说明 IT 投资是多么脆弱。你只需要看看，即使在对教育和指导进行了巨额投资之后，许多组织仍在努力将其敏捷采用扩展到整个组织——或者看看其他组织在团队变化和系统成熟时，如何努力保持其敏捷采用的势头。
新的开始
仅仅因为你一直以相同的方式做事，并不意味着你做的是正确的方式。
我喜欢新的开始。在成长过程中，我最喜欢的事情之一是开始新的学年。从新鲜的学校用品到新班级的学生、老师和课程的承诺，我都迫不及待地想让暑假结束，然后回到学校。新工作也会发生同样的事情。它们让你精神焕发，让你兴奋，让你前进。
云卡尺
命名下一代，并记住云只是别人的计算机
目前，我们很可能继续拥有因语言限制而对其函数进行版本控制的程序员，但让我们希望我们可以阻止他们以下一代的名字命名他们的下一代。
变化的动力：为什么反应性很重要
通过将每个关注点集中在自己的模块中来驯服变化的动力。
专业编程是关于大规模处理软件。当问题很小且受限时，一切都很简单：可以使用命令式编程或函数式编程或任何其他范例优雅地解决它。当程序员必须处理大量数据、网络请求或相互交织的实体（如 UI（用户界面）编程）时，就会出现现实世界的挑战。
让信使冷静下来
让自我远离软件设计评审
试图纠正刚完成大量工作的人，即使最终该工作不是正确的工作，也是一项艰巨的任务。相关人员无疑相信他已经非常努力地工作，为团队的其他成员创造了一些有价值的东西，走进并唾弃它，无论是字面上还是隐喻上，都可能越过你的“冒犯”线——至少我认为是这样。我有点惊讶，因为这是第一个 sprint，并且已经编写了这么多代码，难道不应该在 sprint 确定需要什么、利益相关者是谁等等之后才出现软件吗？
介绍实践研究
专家策划的 CS 研究最佳指南
阅读一篇伟大的研究论文是一种乐趣。一个专家团队巧妙地引导你，读者，通过通常复杂的研究领域，注意先前的技术、当前的趋势、手头紧迫的问题——然后，有时巧妙地，有时似乎凭借纯粹的意志力，在 12 页左右的散文中扩展知识体系。一篇伟大的论文包含一个谜题和一个解决方案；这些可能是有用的、有启发性的，或者两者兼而有之。
作为工程师经理，我不知道我会学到的九件事
许多技能根本不是技术性的。
当我从工程师转变为开发主管时，我知道我有很多东西要学。我最初的想法是，我必须能够进行彻底的代码审查，设计和架构网站，在问题发生之前看到问题，并提出有见地的技术问题。对我来说，这意味着学习技术并成为一名更好的工程师。当我真正担任这个角色时（并且在做了将近 15 年之后），我学到的——并且最重要的——不是那些技术细节。
你想达到什么目的？
一次缓存未命中比许多指令更昂贵。
节省指令——真是 1990 年代的风格。当人们关注细节时总是很高兴，但有时他们只是没有关注正确的细节。虽然 KV 永远不会鼓励开发人员浪费指令，但考虑到现代软件的状态，似乎已经有人这样做了。KV 会像你一样，站在清晰易懂的一边，而不是节省一些指令。
委托的艺术
成为一个让其他人变得更好的人。
当我作为一名初级工程师开始我的职业生涯时，我迫不及待地想成为高级工程师。我会定期审查我们的晋升指南，并根据指南评估我的进步和贡献。当然，当时我并不真正理解成为高级工程师意味着什么。成为一名高级工程师意味着拥有强大的技术技能、良好的沟通能力和驾驭模糊情况的能力，最重要的是，培养和领导他人的能力。领导力不再仅仅是经理的事情。
用例 2.0
软件开发的中心
用例作为一种需求方法已经存在了将近 30 年，并且一直是用户故事等较新技术的灵感来源。现在，灵感已经向另一个方向流动。用例 2.0 是新一代的用例驱动开发——轻量级、敏捷且精益——灵感来自用户故事和敏捷方法 Scrum 和 Kanban。
GNL 不是 Linux
名字里有什么？
名字里到底有什么？正如你已经看到的，这个准技术主题继续在软件社区，特别是在开源世界中引起一些热议。你可以通过点击本文的附言中提供的链接找到来自 GNU 方面的叙述，但 KV 发现该叙述缺乏，因此，违背我对猪和跳舞的更好判断，我将权衡一些评论。
自主与认可的悖论
关于软件团队文化中信任和功绩的思考
谁不希望因其辛勤工作和贡献而获得认可？在我的职业生涯早期，我想相信，如果你努力工作并增加价值，你就会得到回报。我想相信乌托邦式的理想，即努力工作、纪律和贡献是你提升企业阶梯的燃料。孩子，我错了。
腌制补丁
关于补丁存储库以及安全专业人员和内部开发人员之间的紧张关系
我最近偶然发现了一个软件存储库，它不是代码存储库，而是补丁存储库。该项目似乎由几个其他组件构建而成，然后具有复杂的脚本，这些脚本以特定的顺序应用补丁。我不得不查看这个存储库，因为我想修复系统中的一个错误，但是试图弄清楚在任何特定时间点代码的实际外观都令人困惑。是否有工具可以帮助以这种方式工作？
它可能有效
概率算法无处不在——它们不仅可以接受，而且一些程序员实际上会寻找使用它们的机会。
概率算法的存在是为了解决那些不可能或不现实（太昂贵、太耗时等）精确解决的问题。在理想的世界中，你永远不需要真正使用概率算法。对于不熟悉它们的程序员来说，这个想法可能令人非常紧张：“我如何知道它实际上会起作用？如果它莫名其妙地错了怎么办？我该如何调试它？也许我们应该放弃这个问题，或者购买更多服务器……”
自动化应该像钢铁侠，而不是奥创
“剩余原则”需要越来越多高技能的人。
几年前，我们自动化了系统管理团队中的一个主要流程。现在系统无法调试。没有人记得旧的手动流程，自动化超出了我们任何人的理解范围。我们感觉自己把自己逼到了墙角。所有运营自动化注定要这样吗？
精益软件开发 - 构建和交付两个版本
在满足团队目标的同时迎合开发人员的优势
曾经我管理一个软件团队，我们正在进行多个项目。项目根据谁有空、他们的技能以及他们的发展目标进行分配。这导致两位开发人员 Mary 和 Melissa 被分配到同一个项目。
仍在寻找正确的问题
acmqueue 随着时代发展而扩展和变化
欢迎来到最新版本的 acmqueue。当我们在 2003 年初开始编写第一版 时，这对于 来说是一项全新的出版实验。面向从业者受众意味着我们所做的大部分事情都将与学术出版不同。我们创建了一个新的编辑委员会，其作用不仅是审查文章，还要确定从业者和学者都感兴趣的主题和作者。委员会创建了客座专家的概念，他们将负责杂志的某一期，并帮助委员会获取内容，有时还会撰写将所有内容联系在一起的总体文章。
滴答滴答钟声响
关于空加密和自动化文档
尊敬的 KV，在审查我们产品中的一些加密代码时，我遇到了一个允许空加密的选项。这意味着可以打开加密，但数据永远不会被加密或解密。它将始终以“明文”存储。我从我们最新的源代码树中删除了该选项，因为我认为我们不希望毫无戒心的用户打开加密，但仍然以明文存储数据。我团队中的另一位程序员审查了潜在的更改，并阻止我提交它，说空代码可以用于测试。
原始网络
相关性和可重复性
尊敬的 KV，我工作的公司已决定使用无线网络链接来减少延迟，至少在站点之间的天气良好时是这样。在我看来，对于通过有损无线链路的传输，我们需要自己的传输协议，该协议直接位于无线电提供的任何东西之上，而不是在 IP 和 TCP 或 UDP 标头上浪费比特，对于点对点网络来说，这些标头并不是真正有用的。
一种新的软件工程
软件开发中严谨、规范、专业的实践承诺发生了什么？
软件工程发生了什么？软件开发中严谨、规范、专业的实践承诺发生了什么，例如在其他工程学科中观察到的那些实践？在“软件工程”的标题下采用的是一套主要从其他工程学科改编而来的实践：项目管理、设计和蓝图、过程控制等等。基本的类比是将软件视为一种制造产品，所有真正的“工程”都发生在它的上游——在需求分析、设计、建模等方面。
响应型企业：拥抱黑客之道
很快每家公司都将成为软件公司。
截至 2014 年 7 月，成立于 2004 年的 Facebook 位列标准普尔 500 指数中最有价值公司前 20 名，这家成立 10 年的软件公司与 IBM、Oracle 和可口可乐处于同一级别。在 2014 年市值增长最快的五家公司中（表 1），有三家是软件公司：苹果、谷歌和微软（事实上，有人可能会争辩说英特尔也是由软件驱动的，使其成为五分之四）。
和专业程序员
作为读者的你，如何了解影响你工作的研究？
在计算的早期，专业编程几乎与学术研究同义，因为计算机往往是仅存在或主要存在于学术环境中的设备。随着计算机变得商业化，它们开始在私营部门的商业环境中被发现。20 世纪 50 年代和 60 年代，计算以自动化和数据处理的形式进入私营部门，随之而来的是一个不断壮大的专业人士社区，他们对计算的关注是务实的和面向生产的。计算正在（并且仍在）发展，学术界继续探索新的软件和硬件概念和结构。人们发明了新的语言（并且仍在发明），以尝试程序制定的新想法。
分叉过度
被开源蒙蔽
当大多数开源项目只是建议您获取 GitHub 或 SourceForge 上的最新位时，如何才能基于开源软件制作合理的软件包？我们可以像 GitHub 鼓励我们做的那样分叉代码，然后制作我们自己的版本，但这会将我们期望从项目中获得的发布工程工作转移到我们身上。
大型 SEMAT：为什么高管应该关心？
变得更好、更快、更便宜、更快乐
在当今竞争日益激烈的世界中，董事会和高管要求 CIO 及其团队“以更少的资源交付更多”。研究表明，毫不奇怪，没有一种万能的方法可以适用于所有软件计划，并且具有一定程度轻量但有效的秩序和治理的基于实践的方法是大多数软件开发部门的目标。
日志记录的逻辑
以及 PDF 的非逻辑
我在一个相当开放的环境中工作，我所说的开放是指许多人都有能力成为我们服务器上的 root 用户，以便他们可以在服务器崩溃时修复问题。
这是 Foo 字段
位的含义以及避免升级瓶颈
什么时候有人会编写文档来告诉你位的含义，而不是它们设置什么？我一直在努力将一个库集成到我们的系统中，每次我试图弄清楚它想从我的代码中得到什么时，它都只是告诉我它的一部分是什么：“这是 foo 字段。”问题在于它没有告诉我设置 foo 时会发生什么。就好像我应该已经知道了一样。
软件地狱
软件架构师体验的但丁故事
《软件地狱》是一个与但丁·阿利吉耶里在 1300 年代早期创作的《神曲》第一部《地狱》平行的故事。那部文学杰作描述了各种罪人在他们死后在地狱中遭受的谴责和惩罚，作为对他们在世上存在的暴行的补偿。《软件地狱》是一个类似的叙述，描述了一段旅程，其中“反对软件的罪人”在他们的折磨中，在他们被分配的永恒谴责区域内相遇，并忏悔他们的罪行。
Bug 和吹牛的权利
重要的不总是大小。
尊敬的 KV，我一直在处理一个用 Java 编写的大型程序，该程序似乎大部分时间都在要求我重新启动它，因为它已耗尽内存。
敏捷和 SEMAT - 完美的合作伙伴
结合敏捷和 SEMAT 比单独使用任何一个都更有优势
今天，与以往一样，正在进行许多不同的举措来改进软件开发的方式。其中最流行和最普遍的是敏捷运动。SEMAT（软件工程方法和理论）倡议是最新兴的事物之一。与任何新举措一样，人们都在努力了解它如何融入世界并与所有其他正在发生的事情相关联。例如，它会改进还是取代他们当前的工作方式？
关口的野蛮人
高频交易和交易所技术
我是一位前高频交易员。在美好的几年里，我领导了一群杰出的工程师和数学家，我们一起在电子市场上进行交易，并将系统推向了其能力的边缘。
高频交易中的在线算法
竞争性 HFT 算法面临的挑战
HFT（高频交易）已成为现代金融市场中的一股强大力量。仅仅在 20 年前，大部分交易量发生在纽约证券交易所等交易所，那里的人们穿着鲜艳的服装，手舞足蹈，尖叫着他们的交易意图。如今，交易主要发生在数据中心的电子服务器中，计算机通过网络消息传递他们的交易意图。从物理交易所到电子平台的这种转变对于 HFT 公司来说尤其有利可图，这些公司在新环境的基础设施上投入了巨资。
主机的命名是一件困难的事情
还有，过早重启的危险
主机的命名是一件困难的事情，它与编码风格、编辑器选择和语言偏好在计算机人员争论的事情的万神殿中并列，而这些事情对全世界其他任何人来说都无关紧要。
精挑细选和科学方法
软件应该是计算机科学的一部分，而科学需要证明。
因此，在与樱桃卖家讨价还价时，很明显，购买整板樱桃将比购买单篮樱桃更划算，即使那才是我们真正想要的。然而，不想错过这笔交易，我的朋友买下了整板樱桃，我们出发了，边吃边聊。又过了 45 分钟才到家，在那段时间里，我们已经吃掉了超过一半的樱桃。
被自动化淹没
无论何时有人要求你信任他们，都不要信任。
所以你的团队迷上了“只需安装此软件，一切都会好起来”的诡计。这是一个古老的伎俩，它仍在困扰系统管理员和其他在开发人员周围扮演支持角色的人。无论何时有人要求你信任他们，都不要信任。尽管这可能很愤世嫉俗，但这总比被愚弄要好。
因分裂而分裂
软件是否有最佳使用期限？
您是否知道任何关于软件应该多久需要维护一次的经验法则？我不是在考虑错误修复，因为错误从代码编写的那一刻就存在了，而是在考虑代码中似乎不断进行的代码重构。有时我觉得程序员使用重构作为保住工作的一种方式，而不是提供任何真正的改进。
软件工程的本质：SEMAT 内核
以可执行内核形式的思考框架
每个开发软件的人都知道这是一项复杂且有风险的业务，参与者总是在寻找能够改进软件的新想法。幸运的是，软件工程仍然是一个年轻且不断发展的行业，每年都会看到最佳实践的创新和改进。例如，看看精益和敏捷思维为软件开发团队带来的改进和好处。
迷失在集市中的一代人
只有当有人负责时，质量才会发生。
十三年前，埃里克·雷蒙德的书籍《大教堂与集市》（O’Reilly Media，2001）重新定义了我们的词汇，几乎承诺了瀑布模型和大型软件公司的终结，这要归功于新兴的草根开源软件开发运动。我发现这本书发人深省，但它并没有说服我。另一方面，由于深入参与开源，我不禁想到，如果他是对的就好了。
管理技术债务
今天节省金钱和时间的捷径可能会在未来付出代价。
1992年，沃德·坎宁安在 OOPSLA（面向对象编程、系统、语言和应用程序）上发表了一份报告，其中他提出了技术债务的概念。他用不成熟的代码来定义它：“首次交付代码就像进入债务。” 然而，技术债务并不局限于首次交付的代码。有很多方法和原因（并非所有都是坏的）来承担技术债务。
最昂贵的一字节错误
肯、丹尼斯和布莱恩选择以 NUL 结尾的文本字符串是否错误？
IT 既驱动又实现了现代西式经济。因此，我们经常看到关于与 IT 错误相关的惊人巨额资金的新闻标题。哪个 IT 或 CS 决策导致了最昂贵的错误？
一秒战争（你会在什么时间死去？）
随着越来越多的系统关注秒和亚秒级时间，找到解决闰秒问题的持久解决方案变得越来越紧迫。
感谢一个主要在公众视线之下运作的秘密阴谋，您的死亡时间可能会比目前预期的晚一分钟。但不要期望活得更久，除非您碰巧负责大型计算机网络中的时间同步，在这种情况下，这场政变将每隔一年左右稍微降低您的压力水平。我们正在谈论废除闰秒，这是一个 40 年前添加的粗糙的黑客手段，用来掩盖行星作为时钟不如量子力学现象的事实。
B.Y.O.C.（1,342 次及更多）
为什么我们不能都使用标准库来实现常用算法？
尽管很少明确地表达，甚至根本没有表达，但良好软件工程的基石思想之一是重用代码库，其中包含常用算法和工具的易于访问的实现。这种沉默寡言的原因可能是因为没有办法简洁地说明它，而不会听起来像廉价模仿奥卡姆剃刀：用少数人就足够完成的事情，用几个人来做是毫无意义的。
园艺技巧
一个好的库就像一个花园。
在过去的一年里，我一直在为我的公司维护一组库。这些库用于连接我们销售的一些特殊硬件，我们销售给最终用户的所有代码都运行在这些库之上，这些库几乎直接与我们的硬件对话。我一直遇到的一个问题是，应用程序员不断绕过库直接与硬件对话，这会导致我们的系统出现错误，因为库代码维护了关于硬件的状态。如果我使库无状态，那么每个库调用都必须与硬件对话，这将减慢库以及所有使用它的代码的速度。
通过建模应对架构复杂性
组件模型可以帮助诊断新系统和现有系统中的架构问题。
现代计算机日益增长的强大功能使得解决曾经认为太难解决的问题成为可能。然而，对于这些功能复杂的难题空间，系统架构往往过于复杂。在本文中，我使用术语“架构”来指代系统的整体宏观设计，而不是各个部分如何实现的细节。系统架构是可用功能背后的东西，包括内部和外部通信机制、组件边界和耦合，以及系统将如何使用任何底层基础设施（数据库、网络等）。
收集计数器
收集统计数据很重要，但让其他人可以使用它们也很重要。
在过去的一个月里，我一直在试图解决我们的系统在网络负载过重时出现的问题。大约两周后，我将问题从“网络坏了”（我的同事主要用来惹恼我的短语）缩小到我们系统中的网络接口上出了问题。
避免过时
对于系统管理员来说，过度专业化可能是死亡之吻。
尊敬的 KV，系统管理员面临的最大威胁是什么？不是技术威胁（安全、中断等），而是系统管理员作为一种职业的最大威胁？
背叛的简单性
模拟视频系统展示了即使是简单的接口也可能比看起来更复杂且更强大。
模拟器是一个程序，它运行为与支持模拟器的主机平台不同的计算机架构构建的程序。方法各不相同，但大多数模拟器都以某种方式模拟原始硬件。至少模拟器会解释原始 CPU 指令，并为输入和输出提供模拟的硬件级设备。例如，键盘输入取自主机平台并转换为原始硬件格式，从而使模拟程序“看到”相同的击键序列。相反，模拟器会将原始硬件屏幕格式转换为主机上的等效形式。
构建失败
频繁的构建失败可能表明开发项目内部存在更深层次的问题。
对于程序员来说，还有什么比团队成员签入破坏构建的代码更令人恼火的吗？我发现自己不断地追踪其他人代码中的小错误，仅仅是因为他们没有检查他们的更改是否破坏了构建。最糟糕的是，当有人破坏了构建并且他们对我的指出感到愤怒时。有没有更好的方法来防止这些类型的问题？
提交问题
什么时候是提交更改的正确时间？
我的项目中的另一个人坚持以大批量签入不相关的更改。当我说不相关时，我的意思是，他会修复几个不相关的错误，然后在整个源代码树中对间距和缩进进行一些小的更改。然后，他会一次性提交所有这些更改，通常会附带一条简短的提交消息，其中仅列出他声称已修复的错误。您是否认为我对希望每次签入只解决一个问题或问题过于挑剔？
某些规则和限制可能适用
对合同和下一件大事的探究
在我们与外界的许多互动中（唯我论者现在可以停止阅读了，如果他们曾经开始阅读的话），我们与不同的实体签订合同，有些是预先签订的，有些则潜伏在表面之下。普遍理解的合同主题是双方达成共同协议，每方接受某些成本和责任，并反过来可以依赖某些利益和回报。
尽早合并，经常合并
集成分支开发中的更改
在进行合并开发时，应该多久合并一次？很明显，如果我等待太久，那么我会花费数天时间在合并地狱中，在那里似乎什么都无法正常工作，并且我最终使用 revert 命令比 commit 更频繁；但是分支开发的全部意义在于能够保护开发主分支免受不稳定更改的影响。是否有一个快乐的中间地带？
关于软件维护，你一窍不通
长期以来，软件维护一直被认为是事后才考虑的事情，当从一开始就构建到系统中时，软件维护是最容易且最有效的。
每个人都知道维护既困难又无聊，并且避免这样做。此外，他们那些尖头老板会说这样的话：“没有人需要做维护 - 那是浪费时间。”
言语无法表达
取消指定和其他语言危害
最近在关闭英国裸体海滩的公告（这么早我就引起了您的注意吗？）的结尾向所有受影响的“博物学家”道歉。这让“观鸟者”、博物学家和裸体主义者（暗示，暗示）以及那些致力于更好英语的“文字观察者”感到不安。莎莉·贝克的《伦敦时报》反馈专栏中出现了不满和困惑的信件，该专栏是心怀不满的流行语法学家的传统发声筒。
一个也许，两个也许，三个也许，更多
双关语和典故
人们总是不愿意解释笑话。在面对面的玩笑中，讲笑话的人可以从他们立即的反应中判断出对笑话的理解程度。如果未能赢得赞许的微笑、轻笑或捧腹大笑，讲故事的人可以选择补救措施，包括快速退出策略（“真是一群笨蛋。我走了！”）。谦虚的讲述者会接受责备（“哦，我忘了提到岳母是一位金发碧眼的共和党 Fortran 程序员！”）并点所有人的饮料。
不要被定型为软件开发人员
Kode Vicious 的脾气显然受到了清理同行错误的影响。他希望他们现在学习什么，以便他可以期待优雅而成熟的晚年？
我想象学习更多知识将有助于我日常在系统集成商处编写胶水和定制代码的工作。但是，显而易见的适用知识特定于工具和软件包，这些工具和软件包甚至可能在项目生命周期内变得过时或停止使用，并且在某些情况下已经达到了这个目的地。
与史蒂夫·伯恩、埃里克·奥尔曼和布莱恩·坎特里尔的对话
在他们讨论的第二部分中，我们的编辑委员会成员考虑了 XP 和敏捷。
在 2008 年 7 月/8 月的 杂志中，我们发表了关于软件工程实践的两部分讨论的第一部分。目的是了解软件工程师在日常生活中使用的工具、技术和方法。Queue 编辑顾问委员会的三名成员参与了讨论：史蒂夫·伯恩、埃里克·奥尔曼和布莱恩·坎特里尔，他们每个人都为该领域做出了重大而持久的实际贡献（有关每位参与者的更多信息，请参阅第一部分）。在第二部分中，我们重新加入他们的对话，讨论 XP（极限编程）和敏捷。
现实的捏造
“那里”外面有“那里”吗？
总是有周年纪念日，无论是真实的还是虚构的，来缓解专栏作家的写作障碍和/或证明饮酒是合理的。我将为此干杯，因为我们很幸运拥有一个相当有规律的太阳系，它提供了一个年度增量的时间线，我们可以根据它来列举和庆祝过去的事件。Hic semper hic。当饮酒以零星和过度的爆发形式出现时，它被不赞成地称为“狂饮”。我很想声称，这个色彩鲜艳的林肯郡方言词 binge，意思是浸泡，在 200 年前首次用于狂饮的意义。而且，当然，这需要庆祝。
与史蒂夫·伯恩、埃里克·奥尔曼和布莱恩·坎特里尔的对话
在由两部分组成的系列文章的第一部分中，三位 Queue 编辑委员会成员讨论了软件工程的实践。
在由两部分组成的系列文章的第一部分中，三位 Queue 编辑委员会成员讨论了软件工程的实践。为了解决下一个重大的计算问题或开发下一个颠覆性技术，软件工程师很少花时间回顾他们专业的历史。什么改变了？什么没有改变？为了阐明这些问题，我们邀请了 编辑顾问委员会的三名成员坐下来，就不断发展的软件工程实践提供他们的观点。
有很多这样的事情
每个人都在做。
很多什么，关于哪里？我听到你哭了。一次一个问题，我回答道。首先，现在的一切都太多了，其次，它正在各地发生。此外，每个人都在做。正如当代华兹华斯可能会说的那样：“网络对我们来说太多了，早晚，获取和浏览我们浪费了我们的力量。” 大量未经筛选的信息比亚历山大·蒲柏的“一点点学问”更危险，在“一点点学问”中，“浅薄的草稿使大脑陶醉”。
软件开发的阴阳
基础设施元素如何使开发团队在不限制创造力的情况下提高生产力
Parasoft 的 C/C++ 解决方案经理解释了基础设施元素如何使开发团队在不限制创造力的情况下提高生产力。
管理协作
TechExcel 的 Jeff Johnstone 解释了为什么需要一种新的应用程序生命周期管理方法，这种方法可以更好地反映开发团队面临的业务需求和挑战。
我认为从根本上来说，开发被认为是，并且已经变得更像是一个业务流程，而不仅仅是一组工具。在过去，就像你所说的那样，开发人员和开发组织有点孤立无援。他们相当自主，他们会做适合流程每个部分的事情，并且他们会采用在技术和工具层面上合适的工具，但他们并没有真正将自己视为任何更高业务流程的组成部分。
Vista 更好安装的五个步骤 - 文本记录
解开奥秘，学习掌握 Vista 应用程序新应用程序安装例程的最佳实践。在由 Michael Vizard 主持的此 Premium Queuecast 中，Macrovision 全球产品营销高级经理 Bob Corrigan 和首席培训师 Robert Dickau 揭示了您需要了解的关于 Vista 应用程序安装的五个最关键的事情。
今天加入我的是 Macrovision 全球产品营销高级经理 Bob Corrigan；以及 Macrovision 首席培训师 Robert Dickau。今天的主题是 Vista，以及围绕 Vista 的安装例程以及为开发人员带来的机会。
软件运营的利润潜力
今天的软件生产商在建立和保持满意的客户群方面面临许多挑战。在此 Premium Queuecast 中，Macrovision FLEXnet Publisher 产品经理 Mitesh Pancholy 讨论了公司如何解决其许可证管理挑战并将软件运营转变为利润中心。
今天加入我的是 Macrovision 产品经理 Mitesh Pancholy，以及同样来自 Macrovision 的 Abby Domini。今天我们将讨论许可证管理。
理清你的头绪
Kode Vicious 饿了。他靠你从软件开发战壕中提出的问题（和大量啤酒）维持生计。没有你每月的信件，KV 就像离水的鱼，或者像没有问题要解决的科学家。所以请尽你的一份力量，让他保持理智（或至少免于精神病发作）、忙碌和有用。
尊敬的 KV，我遇到的最大的问题之一是记忆力。不是我电脑里的 RAM，而是我头脑中湿糊糊的东西。似乎无论我在我的隔间周围贴多少标志，也无论我多久关闭一次我需要用于工作的那些烦人的即时通讯客户端，我一次最多只能工作 15 分钟，就会有人打断我，然后我就失去了思路。如果这发生在我阅读电子邮件时，那不是问题，但是当处理代码时，特别是当调试代码中的难题时，这使我的生活变得非常困难。
Alloneword
错误、欺骗和歧义
三年前，就在此时此刻，我的第一篇 Curmudgeon 专栏在 中发表，赢得了沉默的大多数人热烈的单手鼓掌。从那时起，我的文章与其他脾气暴躁的贡献者的文章交替出现。在本期（低沉的鼓声）中，我很荣幸地宣布政权发生了类似于戈尔的气候变化，这将重新定义 ACJ（敏捷计算机新闻，稍后详述）的浅根基。精明的 管理层（是的，确实存在 - 您真的必须阅读本杂志的开头几页！）给了我独自行动的机会。至少在接下来的几期 Queue 中，我被加冕为 Curmudgeon 国王，Moaners 的伊迪·阿明，不，抱怨党的最高总书记！
像谷仓一样大？
衡量衡量的标准
德克萨斯州的牧场主正试图用他的财产面积给英国农民留下深刻印象。“我可以黎明时分开车穿过我的土地，到日落时分我仍然没有到达我牧场的边界。” 英国人同情地点点头说：“是的，是的，我知道你的意思。我也有一辆这样的车。”
你可以查阅它：或者可能查不到
通过无休止的、错误标记的节点追逐引文
据说很多人说过：“如果我不能带走它，我就不走了！” 我刚刚说过，但这几乎不算数。我们要求，谁先说或写了它？这就是我所说的（并声称拥有首创权）FUQ（经常无法回答的问题，发音为 fook 以避免歧义和争吵）。尤吉·贝拉的名言是“你可以查阅它”，实际上意思是“相信我的话”。他很清楚，很少有人有手段或耐心来翻阅记录。当然，现在，正如我们在 Unix 中所说的那样，它比 sed 更容易完成。
打破主要版本习惯
敏捷开发能否使您的团队更有效率？
跟上快速变化的步伐可能是一项艰巨的任务。就在您最终使您的软件与新技术配合使用以满足昨天的需求时，更新的技术被引入，或者新的业务趋势出现，打乱了计划。无论您面临的新挑战是 Web 服务、SOA（面向服务的架构）、ESB（企业服务总线）、AJAX、Linux、萨班斯-奥克斯利法案、分布式开发、外包还是竞争压力，都越来越需要开发方法来帮助缩短开发周期时间、更快地响应用户需求并同时提高质量。
Eclipse 的核心
深入了解可扩展的插件架构
ECLIPSE 既是用于构建软件的开放、可扩展的开发环境，也是可以构建软件的开放、可扩展的应用程序框架。它被认为是目前最流行的 Java IDE，为使用工具提供了通用的 UI 模型，并促进了基于插件组件模型的模块化功能的快速开发。Eclipse 基金会将该平台设计为可在多种操作系统（包括 Macintosh、Windows 和 Linux）上原生运行，从而提供与每个操作系统的强大集成，并提供支持每个人都熟悉的 GUI 交互的丰富客户端：拖放、剪切和粘贴（剪贴板）、导航和自定义。
家庭 TB 级服务器的合理化
自我放纵，还是对未来的展望？
拥有 1 TB 的 RAID 5 存储，我的大多数朋友都认为我真的对我的家庭服务器走火入魔了。他们可能是对的，但就像生活中的大多数事情一样，我已经通过一系列合理的个人升级达到了这一点，所有这些升级在当时都是完全合理的。我是否过于放纵我内心的极客，还是我是一个早期采用者，未来这将成为家庭 IT 基础设施的必然标准？这是我的故事；你来评判吧。
与 KV 一起登录
一个有态度的程序员 KV 回答你的问题。他可不是曼纳斯小姐。
尊敬的 KV，我一直被困在为工作中新的支付处理系统编写日志系统。正如您可能想象的那样，这需要记录大量数据，因为我们必须能够在每个计费周期结束时将日志中的数据与我们的客户和其他用户（例如信用卡公司）进行核对，并且如果对账单本身有任何争议，我们必须做好准备。我被分配到这项工作有两个原因：因为我是团队中最晚来的人，并且因为没有人认为编写另一个日志系统非常有趣。
进化还是革命？
高科技的高在哪里？
我们工作在一个以“改变世界”为荣的行业中，一个不断高呼创新口号的行业，新产品可以恰如其分地描述为“本世纪的年度突破”。虽然技术行业中确实存在一些真正的革命，包括手机、GPS（全球定位系统）、量子计算、加密和对内容的全球访问，但绝大多数新产品介绍都是进化性的，而不是革命性的。真正的技术突破少之又少。大多数新产品只是对早期想法的回收。
开始你的编码
尊敬的 KV，简单的问题：什么时候是调用字符串上的 c_str() 方法以获取实际指针的正确时间？
又一年开始了，我们很高兴 Kode Vicious 仍然在怒斥不安全的编程、注释不足和许多其他形式的编码失职行为。然而，尽管他尽了最大努力，但苦乐参半的真相是，这些问题不会很快消失，因此应该继续为未来的 KV 专栏提供充足的素材。哦，生活在一个不需要 KV 的建议或医生的世界里，就此而言。
停止抱怨外包！
我厌倦了听到所有关于外包将如何将所有 IT 工作迁移到工资最低的国家的抱怨。
这种工作迁移的多米诺骨牌理论引发的偏执狂导致美国和西欧程序员担心印度，印度程序员担心中国，中国程序员担心捷克共和国，等等。多米诺骨牌理论家一定认为所有 IT 工作都将流向埃尔博尼亚共和国，这个极度贫穷、四等世界、东欧国家，在呆伯特漫画中有所描绘。
与雷·奥兹的对话
合作、沟通、协作
在计算机编程领域，没有多少名字比雷·奥兹更响亮。作为计算机支持协同工作的行业远见卓识者和先驱，他最初的职业生涯是电气工程师，但很快就进入了计算机科学和编程领域。他是 IBM Lotus Notes 的创建者，现在是微软的首席技术官，向首席软件架构师比尔·盖茨汇报工作。最近，奥兹作为首席技术官的角色扩大了，因为他承担了公司三大部门软件服务战略的责任。
Kode Vicious
医生来了
KV 重返工作岗位，准备治疗另一种编码疾病：糟糕的 API。这是影响，有时甚至感染我们所有人的最广泛的病理之一。但是，无论我们是编写 API 还是只是使用 API（或两者兼而有之），我们都应该好好阅读并听取这位恶棍的建议。
Kode Vicious 未经脚本化
问题？计算机使复制数据太容易了。
有些月份，当 Kode Vicious 感觉雄心勃勃时，他会仔细阅读你的所有来信，为回复哪封来信而苦恼数日。但在大多数情况下，他采取的方法不太谨慎。这通常包括将信件打印出来，将它们扔到空中，看看哪些面朝上着陆，重复这个过程直到只剩下两封。偶尔，KV 会完全不理会读者的反馈，就像这个月的情况一样。
与罗杰·塞申斯和特里·科阿塔的对话
对象和组件之间的区别？这是有争议的。
在 2004-2005 年 12 月/1 月的 Queue 杂志中，罗杰·塞申斯发表了一篇关于对象、组件和 Web 服务以及何时应该使用哪种的文章（“模糊边界”，40-47），引起了一些轰动。塞申斯是国际软件架构师协会董事会成员，著有六本书，撰写了 Architect Technology Advisory，并且是 ObjectWatch 的 CEO。他有非常面向对象的观点，但这不一定与 Queue 编辑委员会成员 Terry Coatta 相同，后者不同意塞申斯在他的文章中说的很多内容。Coatta 是一位活跃的开发人员，曾在组件框架方面进行了广泛的工作。
你的硬盘里有什么？
你的硬盘里有什么？
我喜欢的工具！Python。我仍然是 Python 的新手，但到目前为止我对它印象深刻。作为一种脚本语言，它可以快速测试一个想法或一个算法，即使我正在进行的项目不使用 Python。此外，借助 wxPython 和 py2exe 等免费工具，Python 脚本可以轻松成为具有强大 UI 的成熟可分发应用程序。
称之为胡言乱语？
区分真假变得越来越难。
第九届世界多学科会议 SCI（系统学、控制论和信息学）2005 年吸引了比其空洞的标题通常应得的更多的关注，因为它接受了三位麻省理工学院研究生的恶搞论文。《泰晤士报》（当然，默认情况下是伦敦的）刊登了引人注目的标题“胡言乱语是如何让科学家蒙羞的”（2005 年 4 月 6 日）。其中一位学生杰里米·斯特里布林解释了他们如何开发了一个计算机程序来生成技术术语的随机序列，以证实他们怀疑学术性可疑的论文正在绕过严格的审查，甚至根本没有审查。事实上，学生们声称，这种缺乏适当的同行评审背后存在不可告人的经济动机。
Kode Vicious 继续前进
一个有态度的程序员 KV 回答你的问题。他可不是曼纳斯小姐。
加利福尼亚不仅给你充足的阳光，显然雇主也给你充足的时间来处理你喜欢的小问题，使用一种与以后的实现无关的编程语言。
你的硬盘里有什么？
你的硬盘里有什么？
我喜欢的工具！DbVisualizer。这个工具符合我的直觉。每当我使用数据库并想到“真的应该有一个工具来 ___________”时，DbVisualizer 通常都有我需要的东西。
不良管理者：实地指南
我已经看到了敌人，他就是我。
请允许我带领您进行一次“办公室探险”，可以这么说。在今天的旅程中，我们将穿越计算机领域的走廊，寻找广泛但难以捉摸的不良管理者，或者用通俗的话来说，坏经理。它们将很难被发现，因为我们将在某种意义上寻找所有生物中最难以捉摸的生物：我们自己。也就是说，我们中的许多人很可能与我们将要遇到的各种类型的不良管理者分享一些品质。我可能会补充说，我们不愿承认自己拥有的品质。
Kode Vicious vs. 摩斯拉
一个有态度的程序员 KV 回答你的问题。他可不是曼纳斯小姐。
尊敬的 KV，我的同事们一直在代码中做非常糟糕的事情，例如编写带有 goto 语句的 C++ 代码，这些 goto 语句会跳出宏，并在较低级别的函数中使用 assert 作为错误处理工具。我一直在试图让他们停止做这些事情，但我得到的标准回复是，“是啊，它不好看，但它有效。” 我怎样才能让他们开始问，“有没有更好的方法来做这件事？” 他们听取我的论点，但似乎没有被说服。在某些情况下，他们甚至坚持认为他们遵循了良好的实践。
Kode Vicious 继续战斗
Kode Vicious 又来了，把你从编码泥潭中拉出来，并与常识的敌人作斗争。
尊敬的 KV，我正在维护一些 C 代码，这让我快要疯了。似乎我在任何文件中都不能超过三行，就会遇到一段有条件编译的代码。
你的硬盘里有什么？
你的硬盘里有什么？
我喜欢的工具！GCC。我喜欢 GCC，因为它的每个编译器都完全按照它的指示执行 - 不多也不少。如果你不能在不使用 IDE 的情况下用你喜欢的语言编写程序，你就不是程序员。
Kode Vicious Reloaded
一个有态度的程序员 KV 回答你的问题。他可不是曼纳斯小姐。
该程序应该是一个小型项目，但是每次我开始指定对象和方法时，它似乎都会增长到巨大的规模，无论是在行数还是最终程序的大小方面。
Kode Vicious Unleashed
编码难题让你抓狂？同事让你疯狂？不用担心，Kode Vicious 罩着你。
尊敬的 KV，我的同事编写了 1,000 行长的方法，并声称它们比分解成更小的方法集更容易理解。我们如何才能让他相信他的代码是维护的噩梦？
Kode Vicious：回归
一个有态度的程序员 KV 回答你的问题。他可不是曼纳斯小姐。
尊敬的 KV，每当我的团队审查我的代码时，他们总是抱怨我没有检查系统调用的返回值。我可以理解必须检查常规函数调用，因为我不信任我的同事，但是系统调用是由知道自己在做什么的人编写的——而且，此外，如果系统调用失败，我也没有太多可以恢复的。何必费心呢？
用法语英语编程
半斤八两
当我在高中学习法语时，我们学生经常说“法式英语”（Franglais）：我们知道法语语法和单词就用法语，当我们法语不够用时就插入英语。这很糟糕，老师也不赞赏这种做法。但我们还是能断断续续地交流，因为我们对这两种语言的掌握程度都差不多。如今，一种程序员式的“法式英语”非常普遍。年纪稍大的人会记得在 20 世纪 60 年代末和 70 年代初，关于编译器、操作系统和其他系统程序应该用汇编代码还是高级语言编写的激烈争论。
代码恶棍再次出击
叫我们疯狂也行，但我们正让“代码恶棍”成为常驻栏目。
亲爱的代码恶棍，我有个问题。我总是找不到我确定自己写过的代码片段。这倒不是工作代码——工作代码在我们的源代码服务器上——而是你知道的，那些我上个月写的测试代码，我总是找不到它们。你是怎么处理这个问题的？
燃烧的粪便袋子和其他环境反模式
你以为你的问题很严重？
在我年轻的时候，当地不良少年最喜欢的恶作剧是把装满狗屎的纸袋放在邻居的门廊上，点燃它，按响门铃，然后逃跑。房主开门后，别无选择，只能踩灭燃烧的粪便，弄脏他们的鞋子。为什么要讲这个关于粪便的轶事呢？因为它是一个隐喻，象征着工作场合中情况变得如此糟糕，以至于“灭火”的唯一方法就是踩进去。我称之为“燃烧的粪便袋子”反模式。
观点：一字之差，谬以千里
标点符号与软件开发有什么关系？
出版界发生过更奇怪的事情，但也不多。亚马逊畅销书排行榜（在我写这篇文章时）的首位是 Lynne Truss 关于……标点符号的书。它的销量超过了《哈利·波特》。从书名《Eats, Shoots and Leaves》（Gotham Books，2004）开始，当省略逗号时，书名含义会发生巨大变化，这本书以一种娱乐的方式漫谈了正确和清晰地使用标点符号写作的好处。
从此刻开始
用计算机预测计算机的未来
科幻小说似乎衍生出两个不同的子类型。其中一种已经不受欢迎，它为我们描绘了一个光明的未来，假设了一种乐观的、达尔文主义的“可完善性”。这些情景预测了一个不断扩张（或者更确切地说，是永不内爆）的宇宙，有足够的时间进行乌托邦式的进化。
首先，不要造成伤害：软件开发人员的希波克拉底誓言？
更严肃地对待我们的职业有什么问题吗？
当被问及希波克拉底誓言时，大多数人可能会想起“首先，不要造成伤害”这句话。这是一个合理的反应，因为即使那些不熟悉誓言的人也可能明白，在治疗过程中避免造成额外伤害至关重要。事实上，在任何努力中，力求在修复过程中不要进一步破坏某些东西是很自然的。在软件工程中，就像在医学中一样，不造成伤害始于对可用工具和技术的深刻理解。使用这个主题和一些医学隐喻，我对软件工程的实践提出了一些看法。无论我们做什么，首先，不要造成伤害。
观点：缓冲区溢出疯狂
为什么优秀的程序员会遵循不良实践？
在 2003 年 1 月，据报道，“冲击波”蠕虫是有史以来传播速度最快的蠕虫。“冲击波”通过利用缓冲区溢出来获得访问权限。如果你仔细阅读 CERT 咨询或安全升级发布说明，你会发现大多数计算机安全漏洞都是缓冲区溢出。如果不是因为世界对弱类型编程语言 C 及其衍生语言 C++ 的依赖，这些都只是小麻烦。缓冲区溢出是一种数组越界错误。关于它实际可能如何发生有很多种变体，但这是一个典型的场景。函数 F 调用函数 G，G 返回一个字符串。F 分配一个缓冲区来保存结果，并传递一个指向其第零个字符的指针。
死于 UML 热
自我诊断和早期治疗是对抗 UML 热的关键。
一种可能致命的疾病，临床上称为 UML（统一建模语言）热，正在困扰着当今许多软件工程工作。这种热病有许多不同的菌株，其致命性和传染性各不相同。然而，许多这些菌株在症状上是相关的。严格的实验室分析表明，每种菌株的起源和组成都是独一无二的。UML 热病的一个特别阴险的特征，在它的大多数不同菌株中都很常见，是个人和组织在自我诊断疾病方面遇到的困难。一个后果是，许多热病病例未经治疗，并且经常演变成更复杂和致命的菌株。
瀑布模型的消亡迫在眉睫，以及其他都市神话
关于瀑布生命周期模型消亡的传言被大大夸大了。
我们在最近对近 200 名软件专业人士的调查中发现了这一点和其他关于当前软件工程实践的令人失望的指标。这些发现引发了关于软件工程师的性质、软件工程实践和行业方面，感知与现实之间差异的问题。
IDE 的大爆炸理论
思考着不断扩展的 IDE 宇宙的浩瀚，你可能会想，是否要求一个可用的 IDE 太过分了。
还记得开发只需要一个文本编辑器、一个编译器和某种调试器（在 printf() 或两个 printf() 不够用的情况下）的平静日子吗？在计算机的早期，这些是独立工具，在开发的黄金圈中迭代使用。在某个时候，我们意识到更紧密地集成这些工具可以加快开发过程。因此诞生了集成开发环境（IDE），这是一个用于软件开发的框架和用户环境，实际上是一个对软件创建至关重要的工具包。起初，IDE 只是简单地连接了三大件（编辑器、编译器和调试器），但如今大多数 IDE 都远远超出了这些最低要求。
站起来发言：为什么我讨厌站立会议
站立会议是“全团队”的重要组成部分，“全团队”是极限编程（XP）的基本实践之一。
根据极限编程网站的说法，站立会议是极限编程的规则和实践的一部分：“整个团队之间的沟通是站立会议的目的。它们应该每天早上举行，以便沟通问题、解决方案并促进团队专注。其理念是每个人都站成一个圈，以避免长时间的讨论。与其召开许多只有少数开发人员参加的会议，不如召开一次每个人都必须参加的简短会议效率更高。”
用户界面设计师，时尚的奴隶
现状在界面设计中盛行，而有缺陷的剪切和粘贴概念就是一个完美的例子。
界面设计的学科、科学和艺术已经停滞不前。关于该主题最畅销的书籍主要都是关于如何充分利用现有小部件的纲要。现状被误认为是必然。设计师们被限制在这个夜壶里，四处游荡，给他们的产品用户带来很少的安慰或新鲜空气。
IDE 的困境
糟糕的集成开发环境界面阻碍了编程速度和质量。
来自人机界面世界的人士和大师的布道正在慢慢地说服管理层、软件设计师——甚至程序员——更好的人机界面可以通过加快工作速度、缩短学习时间、减轻人类记忆负担以及缓解用户的身心压力来提高生产力。