Kode Vicious - @kode_vicious
PDF构建失败
频繁的构建失败可能是开发项目中更深层次问题的症状。
亲爱的 KV，
对于程序员来说，还有什么比团队成员提交破坏构建的代码更令人恼火的吗？我发现自己不断地追踪其他人代码中的小错误，仅仅是因为他们没有检查他们的更改是否破坏了构建。最糟糕的是，当有人破坏了构建，而我指出这一点时，他们却感到愤怒。有没有更好的方法来防止这类问题？
注定失败
亲爱的注定，
我知道你，以及其他所有人，都期望我简单地咆哮，说你应该切掉那些冒犯者的粉红色小指尖，以此作为对他们的教训，并警告其他人不要粗心大意。虽然这可能会让人满意，但在大多数地方都是非法的，而且，我被告知，在道德上是错误的。
频繁的构建失败是一种疾病的症状，但它本身并不是疾病。它表明以下三个领域中的任何一个存在问题：管理、基础设施或软件架构。
当出现团队或项目范围的问题时，管理是最容易想到的领域。项目中的大多数工作人员——那些负责编写和验证代码和系统的人——都认为项目范围的问题需要由妈妈（也就是项目负责人或经理）来解决。不幸的是，妈妈只能提醒人们多次整理房间、系好鞋带，以及不要提交破坏构建的代码。
解决人们在提交代码之前不检查代码的问题的最佳方法之一是同侪压力。任何在没有先编译代码的情况下提交代码的人都应该为这样的错误感到尴尬，如果他们没有，周围的其他人应该强烈鼓励他们感到尴尬。事实证明，羞耻感是避免反社会行为的强大动力。就像 KV 的许多——或许是全部——建议一样，羞耻感可能会被过度使用，但我建议你尝试一下，看看效果如何。
指望妈妈来训斥那些行为不端的孩子，过一段时间后，对你和项目管理来说都会变得厌烦。你想要看到的是一种良好的工作文化发展起来，在这种文化中，人们知道破坏构建就像在休息室中间拉屎一样；有趣一次，但通常是不可接受的。
糟糕的基础设施也可能导致频繁的构建失败。有一件事一直让我感到惊讶，那就是计算机硬件变得越来越便宜，但公司仍然在没有夜间甚至更频繁的构建系统的情况下勉强维持。对于一台台式电脑和几天的脚本编写的成本，大多数团队都可以拥有一个系统，该系统可以定期更新其代码的测试构建，构建它，并在构建失败时向团队发送电子邮件。这种系统节省的时间量是很容易衡量的。从团队的程序员数量中减去 1。将结果数字乘以通常需要多少小时来找出是谁破坏了构建、找到他们、让他们感到羞耻并让他们修复构建。现在将该数字乘以团队中每个人的平均小时工资，你就大致了解了由于没有定期构建而浪费了多少时间和金钱。我们暂且不讨论定期测试，定期测试可以节省更多的时间和金钱，因为如果你的构建总是失败，你显然还没有达到足够的成熟度来转向夜间测试。
即使破坏的代码仍然会进入系统，通过定期构建系统，冒犯者也会很快发现他或她破坏了构建，并希望在电子邮件中承认这一点（“我破坏了构建，稍等一下”），然后修复错误。虽然这仍然不是最佳方案，但它比你以前的情况要好得多。
有时，问题的原因是构建系统本身。许多现代构建系统严重依赖于缓存派生对象以及构建过程的并行化。虽然并行构建过程可以更快地为您提供结果，但它通常会导致构建失败，而这些失败是误报。尝试构建一个需要先创建另一个对象的对象，例如自动创建的include文件，总是会导致麻烦。手动维护依赖项列表是一个容易出错，但通常是必要的过程。如果您使用的构建系统依赖于缓存并使用并行构建，那么您的问题可能就在这里。
现在我们来谈谈导致构建问题的最后一个领域。一块软件的组装方式，通常被称为其架构，通常不仅影响软件运行时如何执行，还影响软件如何构建。我犹豫是否使用架构这个词，因为这个术语的过度使用导致了软件架构师这个职位的不幸泛滥，而这在很多时候都是名不副实的。
如果软件系统的所有组件都过于相互依赖，那么对一个组件的更改可能会导致所有组件都受到损害。当软件交付时，缺乏足够的模块化通常是一个问题，但当软件正在编译时，这绝对是一个问题。当对一个include区域中的文件进行更改导致另一个区域中的构建失败时，那么您的软件可能过于紧密地联系在一起，团队应该考虑将各个部分分开。通常，这种联系来自对系统某些部分的粗心重用。粗心重用是指当你看到一个大型抽象时，你会想，“哦，我真的想要方法 X 的这个版本”，其中 X 是整个抽象的一小部分，然后你最终使你的代码不仅依赖于你想要的小部分，而且依赖于与 X 关联的所有部分。如果你到了知道频繁构建失败既不是粗心大意也不是糟糕的基础设施造成的程度，那么就该审视软件架构了。
现在您知道了减轻频繁构建失败的三种最基本的方法：让您的队友感到羞耻、添加一些基本的基础设施，最后改进软件架构。现在，这应该可以让你暂时摆脱牢狱之灾。
KV
KODE VICIOUS，在凡人中被称为 George V. Neville-Neil，为了乐趣和利润而从事网络和操作系统代码方面的工作。他还教授与编程相关的各种主题的课程。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。
© 2010 1542-7730/10/0300 $10.00
最初发表于 Queue vol. 8, no. 3—
在 数字图书馆 中评论本文
更多相关文章
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 年提出，后来普及开来，就是那些成熟的解决方案之一。
© 保留所有权利。