PDF分布式开发永不落幕
KEN COAR，APACHE 软件基金会和 IBM
世界各地的人们可以全天候地在一个分布式项目上工作，但真正的挑战在于驯服社会动态。
越来越多的软件开发正在分布到越来越远的距离。动机各不相同，但最主要的动机之一是努力降低成本。既然人才无处不在，为什么不在发现人才的地方使用人才，而不是花钱将人才迁移到表面上更“中心”的位置呢？互联网日益普及，使得远方的人才更容易获得。
就目前而言，这很有道理，但这是一种可能产生许多副作用的方法，这些副作用甚至比金钱上的节省更难以捉摸。参与者广泛分散的大型项目存在一些问题，这些问题在所有参与者都在同一栋大楼工作的项目中是未知的。如果项目计划具有足够的前瞻性以关注潜在的节省，那么在一个完美的世界中，它当然也应该意识到将产生的其他不太有形的成本。唉，世界并不完美，因此，当组织试水分布式领域时，同样的问题会一遍又一遍地出现。
始终存在协调所有开发人员的问题，以避免从事项目同一部分的人员无意中互相干扰。项目协调的挑战可以通过技术解决方案在一定程度上解决。对于高度多样化和分布式的群体（其中一些人可能从未见过面，但所有人都必须共同工作）的社会动态的理解和影响，则远非一门科学。这是更难理解的问题，也是最难解决的问题。
分布式开发特有问题的主要原因有两个，它们就像是 “进退两难” 的境地
- 跨空间的地理分布包括跨时区的时域分布。
- 不同地区的人们通常具有不同的文化、语言或两者兼而有之。
后者本身就值得深入研究，因此我将主要关注前者。
分布式开发的许多问题都是人类是社会性动物这一事实的直接产物。当我们独自在房间里时，我们倾向于以自我为中心——即使我们此时此刻正在与十几个其他人在线交流——因此从他人的角度看问题并非自动发生。如果我们真的与某人面对面，我们的成长环境会触发一套特定的社会行为模式。通常，当他人的存在是虚拟的而不是物理的时，不会形成这种习惯；我们通常需要有意识地努力表现得好像人们亲身在场一样。由于房间里没有其他人可以让我们模仿和学习，因此教导自己新习惯的重担就完全落在我们自己身上。
在过去的几年中，作为分布式开发过程的参与者，并通过 IRC（互联网中继聊天）提供自愿的实时支持，我个人遇到了所有这些问题——并且不止一次地陷入了他们的陷阱。据推测，并非所有人都会如此容易犯错（尽管我还没有遇到任何不是这样的人），因此为了避免绝对论，我在本文中加入了一种“在许多情况下”的缓和语气。也就是说，以我的经验来看，更好的措辞是“在大多数情况下”。
问题
跨时区的分布实际上迫使人们使用非实时的通信方式，例如电子邮件或文本输入会议工具。即使所有参与者都处于同一时区和文化，并且说同一种语言，这些方式也会给沟通带来自身的负担。本文的其余部分专门关注几乎完全使用此类非个人化媒介（尤其是电子邮件）的问题。
串行和同步通信。 使用电子邮件进行激烈的讨论通常会带来极大的压力，这正是由于媒介的性质所致。通信是通过原子内容包进行的，因此您无法接收部分电子邮件消息。在您拥有可以回复的内容之前，您无法回复。这种“轮流”是媒介的同步性质，它与我们正常的讨论模式差异很大，以至于破坏了我们许多通常的行为和习惯。
电子邮件交流与面对面交流有何不同？首先，亲自参与者可以互相打断，以纠正错误的印象或阻止混乱和冗长的题外话。这是面对面交流的基本特征之一；无论是在团队会议、公共汽车上还是午餐期间，都无关紧要。
这在电子邮件中不会发生；当您阅读某人的消息时，发送者已经完成撰写；您无法在消息完成并发送之前打断。如果您碰巧不同意，或者看到您的通信者在某种误解下走入歧途，当您通读收到的整体消息时，很容易开始怒火中烧并在脑海中起草一份尖刻的回应。但是，另一个人不会在您发表最初的评论后很久才“听到”您。如果这些评论的提出没有争议或冒犯之意，那么您尖酸刻薄的回应很可能会导致情绪升级。
与此相关的是媒介的非个人化性质的影响。即使使用表情符号，由于无法察觉彼此的肢体语言，我们也倾向于变得敏感并保持警惕，从而很容易被冒犯。在电子邮件中添加“开玩笑的！”可能不具有与亲自真诚微笑相同的消除戒心的效果；这取决于相关人员以及他们彼此之间的历史。也许有一段只是开玩笑的；但是如果其他人激怒了您，您可能会回复哪些内容呢？
互联网时间。 随着人们花费更多时间在线，他们往往会变得更加习惯于快速响应时间。传输速度在很短的时间内取得了长足的进步。想想 1989 年，我正在与千里之外的某人通电话，并给他发送了一封电子邮件消息。当我们在大约 15 分钟后听到他那端的哔哔声时，我们都惊讶于它到达得如此之快。当时非凡的事情现在被认为是理所当然的。遇到问题，发送消息寻求帮助，并在您再喝一杯咖啡之前通过回复邮件获得答案，这绝非不寻常。
这对于实际的协作开发工作来说很方便，但当它蔓延到决策过程时，就会出现问题。存在一种明显的趋势，即期望每个人都像自己一样反应迅速——或者至少忽略他们并非如此的可能性——并相应地分配截止日期和决策点。
这是 ad nuntium 错误的一个例子（直接回复消息的内容，在下一节“骂战”中讨论）；努力快速完成事情常常没有考虑到并非所有参与者都处于同一时区，或者可能在休假，或者可能正在享受地区性假日。如果事情继续进行，当那些在截止日期前无法参与的人员返回时，随后的元讨论和激烈言辞（情绪化的电子邮件爆发）可能比首先延长截止日期对工作的损害更大。
对这种近乎即时的满足感的期望以及它所助长的缺乏耐心，可能直接导致摩擦和不好的感觉。如果您向某人发送带有问题的消息，但在大约一小时内没有收到回复，您可能会（有些人确实会这样做）放弃并将其发送给其他人。当第一个人从午餐、银行或（在时区不同的情况下）上班回来，并发现您没有留出足够的回复时间时，您的原始通信者很可能会以非纯粹的仁慈眼光看待您。
在加速的期望与现实世界的需求之间还存在另一个方面的冲突。电子邮件消息通常非常切中特定问题的要点；一个人可能同时进行多个不同的“对话”。当我们从一个主题到下一个主题进行时分复用时，这使我们有机会喘口气并重新集中注意力——因此，当回到一个对话中并发现语气变得不那么友好了时，可能会特别刺耳。这种突然意外地陷入情绪漩涡可能会使我们的反应比其他情况更强烈，就像当我们刚从暴风雪中回来时，淋浴在室温下的水最初会感觉很热一样。
骂战。 这些尖刻的交流几乎是前两个问题不可避免的后果。参与者感到受到攻击——无论是个人上还是意识形态上——被媒介的串行性质使得不可中断和整体的消息序列所攻击，或者他们可能感到被轻视或被剥夺权利，因为当他们无法跟上并表达他们的观点时，事情进展得很快。
激烈言辞的一种众所周知的形式（和原因）是人身攻击，即针对个人而非针对某人的立场或论点进行的攻击。它几乎总是会导致以牙还牙的回应，并且紧张局势开始迅速升级。首先，当参与者解剖对方时，问题变得 thinly veiled 烟幕弹；然后，一些特别恶性的骂战最终可能会放弃任何其他伪装。
奇怪的是，将您的评论专门针对消息内容（ad nuntium），而不是发送者，可能几乎同样糟糕。非个人化地 abrupt 甚至 vicious 非常常见，并且忘记了您不是在与计算机对话——毕竟，屏幕的另一端是人。因此，即使您无意冒犯您回复的消息的作者，但在屏幕的另一端看来也可能并非如此。
骂战可能特别具有分裂性和破坏性的一个原因是可能“产生分支”——也就是说，一方或另一方开始一项独立的努力。这在分布式开源软件开发项目中偶尔会发生，但如果工作完全在内部完成，则可能不是主要问题。
保持同步。 允许面对面会议的环境具有一种内置方式，可以使每个人都了解项目各个方面的当前状态。然而，广泛分布的个人集合可能会很容易失去对彼此工作和进度的跟踪。后果谱系中的两个病态终点是
- 人们重复工作，因为他们不知道其他人已经在做（或已经完成）它。
- 有些任务未能完成，因为每个人都认为其他人正在负责它们。
如果项目工作确实需要协调，那么管理者必须找到某种方法，将每个人重新同步到大局以及正在进行的各种努力。
由于电子讨论是持续不断的 focused to-the-point 消息流，因此脱节任何一段时间都可能是灾难性的。没有可以查看会议记录的会议；可能没有任何详细的进度报告。为了真正重回正轨，缺席的参与者需要阅读他们在离开期间发生的所有相关讨论流量。在活跃的讨论论坛中，这可能是一个真正令人望而却步的前景。如果量太大，则往往会忽略或仅浏览错过的较早部分内容，而仅密切关注最近的帖子。取决于缺席期间发生的事情，这可能会使返回者在未来的某个时候意外地挣扎。
高流量对于读者来说是一个陷阱，它会诱使他们浏览或跳过。另一方面，低流量对于作者来说是一个陷阱。如果没有问题，如果没有迫切需要讨论，工作可能会在个人手中正常进行。但是，其正常进展的事实很容易让开发者忘记，他们的任务不仅是开发，还要沟通。软件开发人员在文档方面通常不理想，因此这可能是另一个需要有意识努力的领域——让其他参与者了解进度，即使进展非常顺利。
当然，非常人性化的害怕显得愚蠢也可能导致不情愿通过在线方式描述问题。邮件消息是永久的，因此如果有人犯了一些非常愚蠢的错误，可能会在未来几年为他人提供娱乐。有些人可以随时随地发布内容，无论是由于他们在媒介中长大，拥有钢铁般的自我，还是非常胜任。但是，那些感觉不太舒服的人可能还有额外的障碍需要克服：认识和接受犯错是可以的，无知是可以治愈的，以及保持沉默可能对整个项目不利。
达成共识。 电子邮件通信媒介的第三个自然结果是难以得出结论或达成共识。由于所有参与者都彼此失去实时联系，因此任何人很难做相当于喊“好了，够了！”的事情。如果在电子邮件中尝试，几乎总是有些人正在撰写消息继续讨论，或者尚未赶上事件并回复他们现在才阅读的旧消息。
对共识建立的需求是快速（“互联网时间”）讨论和开发与需要更多会面时间来做出决定之间看似矛盾的结合的另一个例证。如果参与者都在会议中面对面，讨论很可能会非常快速地进行，并且可以在休会前做出决定。然而，在线讨论媒介允许以会议中通常不可能的方式精心设计消息和论点、进行研究和进行实验。开发可以快速进行，因为所有参与者都可以在自己的时区中大致按照自己的节奏进行。但是，引入某种做出决定的汇合点，您就必须充分减慢流程以适应不同的时间表。
作为一个类比，考虑几个人同意在分开吃午饭前在某处会面。在最慢的成员到达会合点之前，该小组无法继续进行。如果最后一个人特别迟到，情况会变得更糟，因为先到的人往往会在等待时“暂时”从事其他活动（去银行、取报纸、买软饮料等）。然后，即使在最后一个人到达之后，也需要重新协调才能采取下一步行动。
解决方案
这些问题中的大多数可以通过应用网络礼仪来处理，网络礼仪本质上是将礼貌和文明应用于电子通信媒体。然而，即使是良好的网络公民也可能会变得充满激情和兴奋，并忘记他们的电子形象将如何被感知。
自动化。 首先也是最重要的，请记住，计算机和网络是您的仆人。尽可能多地自动化任务，让机器来完成它们。它们不仅比容易犯错的开发人员更不容易忘记，而且它们的非个人化还可以引入对某些形式的骂战的抑制剂。
例如，大量的分布式开源开发项目都有计算机在源代码更改时自动发送摘要消息。例如，图 1 显示了来自 Apache HTTP 服务器项目开发邮件列表的此类消息的文本：该消息标识了谁进行了更改 (nd)、更改时间、更改了哪些文件以及原因，以及实际更改是什么。已添加的行以“+”为前缀；已删除的行以“ -”标记。替换的行显示为“ -”行标记旧文本，然后用“+”行显示新文本。
图 1
Subject: cvs commit: httpd-2.0/modules/mappers mod_rewrite.c From: nd () apache ! org Date: 2003-08-05 21:18:47
nd 2003/08/05 14:18:47
Modified: modules/mappers mod_rewrite.c Log: add a comment for future editors no code change.
Revision Changes Path 1.222 +1 -0 httpd-2.0/modules/mappers/mod_rewrite.c
Index: mod_rewrite.c
==============================================================
RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_rewrite.c,v
retrieving revision 1.221
retrieving revision 1.222 diff -u -r1.221 -r1.222
--- mod_rewrite.c 5 Aug 2003 18:45:53 -0000 1.221
+++ mod_rewrite.c 5 Aug 2003 21:18:47 -0000 1.222
@@ -1416,6 +1416,7 @@
}
}
+ /* buf is not zero terminated, so be careful! */
if (i == 4 && strncasecmp(buf, “NULL”, 4) == 0) {
return NULL;
}
来自 Apache HTTP 服务器项目开发邮件列表的摘要消息，指示源代码中的更改
Apache 环境更进一步：如果更改非常大，则会提供指向显示更改页面的 Web 链接，而不是更改本身；这避免了因兆字节的邮件而给网络、磁盘和人们的耐心带来压力。图 2 显示了此类消息的示例
图 2
Subject: cvs commit: httpd-2.0/modules/filters mod_inc lude.CaFrom: nd () apache ! org Date: 2003-08-22 0:15:28 nd 2003/08/21 17:15:28
Modified: modules/filters mod_include.c Log: before working further, bring some kind of system into the stuff and (re-)order the code. That should finally improve readability...
Revision Changes Path 1.239 +1618 -1543httpd-2.0/modules/filters/mod_include.c
http://cvs.apache.org/viewcvs/httpd2.0/modules/filters/mod_include.c.diff?r1=1.238&2=1.239
请注意修改的行数：添加了 1,618 行，删除了 1,543 行。由于这些行中的每一行都显示出来，再加上两侧的一些上下文，因此原始报告将长达数千行——因此，使用了指向单个基于 Web 的版本的链接，而不是每个邮箱中都包含大量副本。
可能需要一段时间才能习惯这种报告，但是一旦您习惯了它，您就可以快速掌握更改。而且由于它是开发的副作用——不需要开发人员付出额外的有意识的努力——因此它以某种方式使进度自我记录。
所有记录和存档（包括邮件列表和任何类型的自动化核算，例如刚刚描述的核算）都应该易于搜索。这有助于识别现有技术和以前的讨论和决定，从而通过提供避免重复讨论旧话题或方法的方式来简化工作。
任何其他可以减轻参与者“管理琐事”的方式都可能值得考虑。示例包括用于记录和整理投票或意见的工具、定期自动邮寄状态文档或错误跟踪报告以及更新网页的定时作业。
意识和理解。 网络礼仪是常识和黄金法则的结合。请记住，在您的电子邮件的另一端是一个人，他们的观点、信仰、文化、语言和时区可能与您自己的不同。不仅要像对待与您在同一个房间里的人一样对待您的通信者，还要像您希望他们对待您一样对待他们。
始终记住做一个良好的网络公民是一项困难的任务，特别是由于它确实需要在他人实际缺席的情况下进行有意识的思考。
宽容和耐心。 除了记住您的消息另一端有人之外，您还必须记住语言、文化和/或时区的差异。轻微骂战的常见原因之一只是误解：两个人使用相同的词语或表达方式表示不同的含义，或者根本不理解作者打算赋予词语的含义。我在在线实时支持论坛中多次看到这种情况，尤其是在双方基本上彼此不认识的情况下。
对他人有耐心是硬币的一面；对自己有耐心是另一面。对于某些人来说，在线发言的挑战，在一个将被无限期存档的论坛中，似乎难以克服。有助于克服这一障碍的一件事是令人欣慰的认识，即没有人生来就拥有您所缺乏的知识；每个人都必须在某个时候学习它。
记录。 过度（且通常没有成效）讨论，有时甚至是骂战的原因之一是关于谁说了什么以及何时说的“他说/她说”的争论。如果其中一位参与者沉迷于，呃，“情境反应”，回避问题，从一条消息到另一条消息改变调子，并且通常难以捉摸，这可能会特别具有破坏性。
解决这种病态情况以及关于事情现状的任何正常困惑的一种方法是将通信记录在某处可访问的地方，例如邮件列表的存档。存档的访问程度完全取决于您的环境，但它们至少应该对参与者本身可用。
要保留的另一个有用的记录是“当前状态”文档，该文档详细说明当前的各种活动是什么，谁参与其中，哪些决策待定以及已做出哪些决策。大多数项目通常都有类似的东西，但在分布式社区中，定期将状态文档发送到邮件列表或论坛可能非常有用。这有助于每个人保持在同一页面上，并有助于避免因未完成的任务而出现“我不知道”的借口的可能性。
领导力。 保持电子讨论步入正轨的最佳方法是分配某人——或多人——来监控讨论并尝试使其以富有成效的方式进行。偶尔提醒所有参与者注意等待粗心大意者的陷阱是一个好的开始，但更具挑战性的任务是发现萌芽状态的骂战并在它们真正开始之前阻止它们。有时它们是不可避免的，因此挑战变成了成为一名出色的消防员并尽快扑灭火焰。
并非每个人都具有担任此角色的性情；有时领导者自行涌现，有时他们被征召入伍并以他们的技能让所有人感到惊讶。在线领导者的先决条件是赢得其他参与者的尊重。因此，观察通常会揭示具有适当品质的人——如果有的话。显然，社区越大，就越有可能出现一个或多个潜在的领导者。
即使讨论领导者不处于权威地位，评论和回应的调节作用也应该是明显的。这样的人是否应该具有任何公认的权威是一个高度情境化的问题。
在和平维护者的角色中，社区领导者最好擅长搜索讨论档案，以便在争端进一步发展之前澄清它们。
结论
如果您花费任何时间参与拥有来自全球各地参与者的邮件列表，那么我提出的绝大多数观点很可能与您产生共鸣，或者看起来非常明显。不幸的是，尽管事后看来它们可能很明显，但在实践中，很多人会忽略它们。
我们拥有的保持分布式讨论文明和富有成效的最佳工具是警惕——关注正在发展的骂战的警告信号，确保每个人都有机会参与，并且最重要的是，仔细检查我们自己的行为，以确保我们是良好的网络公民。
参考资料
1. 有关表情符号的更多信息，它是由 Scott Fahlman 在 1982 年创建的，请访问维基百科网站： http://wikipedia.org/wiki/Emoticon。
KEN COAR 是 Apache 软件基金会的董事兼副总裁，也是 IBM 的高级软件工程师。他在网络软件和应用程序、系统管理、系统编程、流程分析和计算机安全方面拥有超过二十年的经验。Coar 自 1992 年以来一直从事万维网工作，是 成员，并参与了为 CGI（通用网关接口）开发 Internet RFC 的项目。他是《Apache Server for Dummies》（Dummies Press，1998 年）的合著者、《Apache Server Unleashed》（Pearson Education，2000 年）的合著者，并且刚刚完成了一本新书《Apache Cookbook》（O'Reilly，2003 年）。多年来，他一直参与分布式开发和实时技术支持。
最初发表于 Queue 第 1 卷，第 9 期—
在 数字图书馆中评论本文
更多相关文章
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - 在线事件处理
对跨异构存储技术的分布式事务的支持要么不存在，要么在操作和性能特性方面表现不佳。相比之下，OLEP 越来越多地用于在这些设置中提供良好的性能和强大的数据一致性保证。在数据系统中，日志通常用作内部实现细节。OLEP 方法有所不同：它使用事件日志而不是事务作为数据管理的主要应用程序编程模型。传统数据库仍然使用，但它们的写入来自日志，而不是直接来自应用程序。使用 OLEP 不仅仅是开发人员的实用主义，而且它还提供了许多优势。
Andrew Leung, Andrew Spyker, Tim Bozarth - Titus：将容器引入 Netflix 云
我们相信我们的方法使 Netflix 能够快速采用容器并从中受益。尽管细节可能特定于 Netflix，但通过与现有基础设施集成并与合适的早期采用者合作来提供低摩擦容器采用的方法对于任何希望采用容器的组织来说都可能是一种成功的策略。
Marius Eriksen - 大规模函数式编程
现代服务器软件的开发和运营要求很高：它必须始终在所有位置可用；它必须在几毫秒内回复用户请求；它必须快速响应容量需求；它必须处理大量数据和更多流量；它必须快速适应不断变化的产品需求；并且在许多情况下，它必须容纳一个大型工程组织，其众多工程师就像一个又大又乱的厨房里众多的厨师。
Caitie McCaffrey - 分布式系统的验证
Leslie Lamport 以其在分布式系统方面的开创性工作而闻名，他曾说过一句名言：“分布式系统是指即使您不知道存在的计算机发生故障也可能导致您自己的计算机无法使用的系统。” 鉴于这种黯淡的前景和大量可能的故障，您甚至如何开始验证和确认您构建的分布式系统正在做正确的事情？
© 保留所有权利。