迷失在集市上的一代人 (2012)

2012 年 8 月 15 日，第 10 卷，第 8 期 十三年前，Eric Raymond 的书 The Cathedral and the Bazaar（O'Reilly Media，2001）重新定义了我们的词汇，几乎承诺结束瀑布模型和大型软件公司，这要归功于新的草根开源软件开发运动。我发现这本书发人深省，但它并没有说服我。另一方面，深入参与开源，我不禁想到如果他是对的就好了。今年夏天我带到海滨别墅的那本书也发人深省，比雷蒙德的（它甚至相当肯定地提到）更发人深省：弗雷德里克·P·布鲁克斯的设计设计（Addison-Wesley Professional，2010 年）。尽管我发现自己点头表示同意，而且我很喜欢布鲁克斯对语言和主题的掌握，但这本书也让我感到悲伤和失望。 13 年前也标志着 dot-com 狂热的顶峰，每个青少年都是网络程序员，每个大学辍学者都有一个网络创业公司。我在尝试向这些新手教授一些老式的技巧——测试恢复备份、操作系统安装脚本、版本控制等方面非常有趣。当然，事后看来是 20/20（即，事件可能没有您记得的那么有趣），并且无法逃避整个 dot-com 时代对于 IT/CS，尤其是软件质量和 Unix 来说都是一场灾难。我还没有看到任何关于 IT 行业在互联网时代变得更大的有力分析。我自己的估计是——将在此之前的 IT 部门锁着的钢门后面的工作种类计算在内——我们的贸易增长了两个数量级，或者如果你愿意，增长超过 10,000%。迷上计算机很容易——几乎任何人都可以使程序工作，就像几乎任何人都可以在几次尝试中将两块木头钉在一起一样。问题在于，在“骄傲的祖父”部分之外，将两块木头钉在一起的市场——不熟练——相当小，从那里获得一套像样的椅子或合适的橱柜需要天赋、实践和教育。额外的 9,900% 的人在进入我们的行业时既没有实践也没有受过教育，在他们有机会获得它之前，聚会就结束了，他们中的大多数人都失业了。我会仁慈地假设那些设法坚持下来的人是最有才华和最熟练的，但即便如此，作为 IT 专业人士，他们也无法逃避，因为他们缺乏镇流器。 Raymond 所提倡的集市模因，“Just hack it”，与前互联网时代精心设计的大教堂相反，不幸的是，它并没有随着互联网的疯狂而消亡，今天 Unix 在它的重压下迅速下沉.我更新了我的笔记本电脑。我已经连续运行 FreeBSD 的开发版本 18 年了，甚至从源代码编译我的 Spartan 工作环境也需要一整天，因为它涉及试图从 Raymond 的无政府主义软件集市中理解和架构。

在顶层，FreeBSD 端口集合试图创建一个集市地图，使 FreeBSD 用户可以轻松找到他们需要的东西。实际上，目前这张地图由 22,198 个文件组成，这些文件对集市中的每个摊位进行了简要描述——几行内容大致告诉您该摊位提供什么以及您可以在哪里阅读更多相关信息。还包括 23,214 个 Makefile，它们告诉您如何处理在每个摊位中找到的软件。这些 Makefile 还试图告知您应该考虑的选择、选择哪些选项以及对它们来说什么是合理的默认值。该地图还方便地附带了 24,400 个补丁文件，以弥补所提供的许多商品缺乏工艺的问题，但是，一般来说，缺乏便携性导致需要这些补丁文件。最后，地图有用地告诉您，如果您想要拥有 www/firefox，您首先需要获得 devel/nspr、security/nss、databases/sqlite3 等。一旦您在地图中查找并找到它们的依赖项，并递归查找它们的依赖项，您将拥有一个包含 122 个软件包的购物清单，然后才能访问 www/firefox。模块化和代码重用当然是一件好事。然而，即使在最简单的情况下，代码重用的 CS/IT 教条在集市上也是完全陌生的：FreeBSD 端口集合中的软件包含至少 1,342 种复制和粘贴的加密算法。如果对代码重用的抵制/无知导致了自包含和独立的软件包，那么代码重复的价格实际上可能是为了方便包管理而进行的一个很好的权衡。但事实并非如此：这些包形成了一个杂乱无章的依赖关系网络，导致大量代码重复和浪费。这是一个具有讽刺意味的浪费的例子：Sam Leffler 的 graphics/libtiff 是通往 www/firefox 的 122 个包之一，但由此产生的 Firefox 浏览器不呈现 TIFF 图像。出于我没有尝试发现的原因，122 个包中有 10 个需要 Perl，7 个需要 Python；其中之一，devel/glib20，出于我无法想象的原因需要两种语言。再往下是彼得原理的重复应用，即在晋升基于成就、成功和功绩的组织中，该组织的成员最终将被提升到超出其能力水平的晋升。该原则通常被表述为“员工往往会上升到他们无能的程度”。将该原理应用于软件，您会发现您需要三个不同版本的 make 程序、一个宏处理器、一个汇编程序和许多其他有趣的包。在食物链的最底层，可以说是 libtool，它试图隐藏一个事实，即在 Unix 中没有标准化的方法来构建共享库。与标准化如何在所有 Unixen 中执行此操作不同——这对 ld(1) 命令只需要一个标志——而是应用了彼得原则，并使其成为 libtool 的工作。在这种情况下，彼得原理确实很强大——devel/libtool 的源代码有 414,740 行。一半的行数是测试用例，这在原则上是值得称赞的，但在实践中，它只是彼得原则在起作用：测试精心探索复杂解决方案的功能，用于解决最初不应该存在的问题。更令人抓狂的是，这些行中有 31,085 行在一个名为 configure 的难以阅读的丑陋 shell 脚本中。这个想法是配置脚本执行大约 200 次自动化测试，因此用户无需手动配置 libtool。这是一个非常糟糕的主意，早在 1980 年代它出现时就已经受到很多批评，因为它允许源代码在配置脚本的贴面后面假装可移植，而不是真正具有可移植性的质量。配置思想幸存下来是一种讽刺。 1980 年代看到了非常不同的 Unix 实现：带有 24 位指针的 Cray-1、Amdahl UTS 大型机 Unix、来自小型机制造商的许多或多或少能胜任地执行的 SysV+BSD 混搭，几乎（但不完全）来自像 Data General 这样的供应商，甚至是来自油漆公司 Mark Williams 的真正的 Unix 克隆 Coherent。

那时的配置脚本是手工编写的，并做一些事情，例如弄清楚这是否最像 BSD 或 SysV 风格的 Unix，然后复制一个或另一个 Makefile，也许还有一个 .h 文件到位。后来配置脚本变得更加雄心勃勃，作为彼得原理的几乎可预测的应用，有人编写了一个程序 autoconf 来编写配置脚本，而不是标准化 Unix 以消除对它们的需求。今天的类 Unix/Posix 操作系统，甚至包括 IBM 的 z/OS 大型机版本，用 1980 年的眼睛来看都是相同的；然而，libtool 的 31,085 行配置仍然检查 <sys/stat.h> 和 <stdlib.h> 是否存在，即使缺少它们的 Unixen 既没有足够的内存来执行 libtool，也没有足够大的磁盘供其 16- MB源代码。好吧，出于一些从未有过的原因，autoconf 是用晦涩的 M4 宏语言编写的，这意味着实际测试看起来像这样： ## `make' 是否支持仅订单先决条件。 AC_CACHE_CHECK([${MAKE-make} 是否支持 order-only 先决条件], [lt_cv_make_order_only], [mkdir conftest.dir cd conftest.dir touch b touch a cat >confmk << 'END' a: b | cabc: touch $ []@ END touch c if ${MAKE-make} -s -q -f confmk >/dev/null 2>&1; then lt_cv_make_order_only=yes else lt_cv_make_order_only=no fi cd .. rm -rf conftest.dir ]) if测试 $lt_cv_make_order_only = yes;然后订单='|' else ORDER='' fi AC_SUBST([ORDER]) 不用说，即使他们有技能，这也是大多数程序员都不愿意忍受的，所以 autoconf 的输入文件通常是通过复制和粘贴来发生的隐藏在越来越臃肿的标准宏后面，涵盖“标准测试”，例如前面提到的那些，寻找过去 20 年未见的兼容性问题。这可能也是为什么 libtool 的 configure 探测不少于 26 个不同名称的 Fortran 编译器我的系统没有，然后再花费 26 次测试来确定这些不存在的 Fortran 编译器中的每一个是否支持 -g 选项。这就是雷蒙德在他的书中所称赞的集市的可悲现实：一堆陈旧的破绽，被无知的一代 IT“专业人士”无休止地复制和粘贴它。今天很难相信，但在这种令人尴尬的混乱之下，隐藏着美丽的 Unix 大教堂的废墟，该大教堂以其简单的设计、经济的功能和优雅的执行而闻名。 （原文如此，gloria mundi 等）

布鲁克斯的众多优点之一是质量只有在有人对其负责的情况下才会发生，而“某人”只能是一个人——一个充满活力的二人组除外。我很惊讶布鲁克斯没有引用 Unix 作为这种说法的一个例子，因为我们几乎可以精确地指出 Unix 开始分裂的那一刻：在 1990 年代初，AT&T 将 Unix 剥离出来将其商业化，从而抢走了它的建筑师。近年来，其他人不止一次得出与布鲁克斯相同的结论。有些人试图强加一种理智，甚至以技术标准的形式正式制定法律，希望为集市带来秩序和结构。到目前为止，他们都以惊人的失败告终，因为在集市上迷路的互联网网络神童这一代从未见过大教堂，因此甚至无法想象你为什么想要一个大教堂，更不用说它应该是什么样子了。具有讽刺意味的是，那些最需要阅读它的人可能会发现《设计的设计》完全无法理解。但是对于任何曾经想过使用 m4 宏来配置 autoconf 来编写 shell 脚本来寻找 26 个 Fortran 编译器以构建 Web 浏览器的人来说，这有点绕道而行，Brooks 提供了一个有充分理由的希望更好的方法。 Poul-Henning Kamp ([email protected]) 已为计算机编程 26 年，是bikeshed.org 背后的灵感来源。他的软件已被广泛用作开源和商业产品中的底层构建块。他最近的项目是 Varnish HTTP 加速器，用于加速大型网站，如 Facebook。最初发表在队列卷。 10，没有。 8 — 在 ACM 数字图书馆中查看此项目 相关：João Varajão - 破坏性时期的软件开发 在该项目中，挑战是“以比冠状病毒传播更快的速度部署软件”。在具有如此特殊特征的项目中，有几个因素会影响成功，但有些因素很明显：高层管理人员的支持、敏捷性、项目团队的理解和承诺，以及所使用的技术。传统的开发方法和技术根本无法及时满足要求。 Nicole Forsgren、Margaret-Anne Storey、Chandra Maddila、Thomas Zimmermann、Brian Houck、Jenna Butler - 开发人员生产力的空间 开发人员生产力不仅仅是个人的活动水平或依赖于交付软件的工程系统的效率，而且不能用单一的指标或维度来衡量。 SPACE 框架捕捉了生产力的不同维度，在这里我们展示了如何使用该框架来理解实践中的生产力，以及为什么使用它可以帮助团队更好地了解开发人员的生产力，并创建更好的衡量标准来为他们的工作和团队提供信息。 Chris Nokleberg、Brad Hawkes - 最佳实践：应用程序框架 虽然框架是一种强大的工具，但它们也有一些缺点，可能并非对所有组织都有意义。框架维护者需要提供标准化和明确定义的行为，同时又不能过于规范。然而，当框架达到正确的平衡时，它们可以为开发人员提供大量的生产力提升。框架的广泛使用提供的一致性对其他团队（如 SRE 和安全性）来说是一个福音，这些团队对应用程序的质量有既得利益。此外，框架的结构为构建更高级别的抽象（例如微服务平台）提供了基础，这为系统架构和自动化带来了新的机会。

J. Paul Reed - 超越 Fix-it 跑步机 鉴于人类对安全社会学因素的研究已有近一个世纪的历史，技术行业的事故后分析实践以及我们如何创建和使用这些实践产生的人工制品仍然处于他们的幼年。因此，不要对这些实践中的许多如此相似感到惊讶，用于解析和理解事件和中断的认知和社会模型很少并且在运营精神中得到巩固，并且从事件后分析中寻求的副产品是远远专注于补救项目和预防。