Kode Vicious - @kode_vicious
PDF有毒的程序员
一个态度强硬的程序员，KV 回答你的问题。他可不是曼纳斯小姐。
众所周知，项目的成功或失败在很大程度上取决于拥有合适的人才，以及技术。但是，如何防止某些“捣蛋分子”破坏您的项目？KV 对这个“非技术问题”有很多话要说。惊喜！他的解决方案既不涉及肢体虐待，也不涉及言语辱骂。我们鼓励您通过电子邮件向 [email protected] 提出您自己的解决方案，或思考其他问题。
亲爱的 KV，
我希望您不介意我问您一个与工作无关的问题，当然如果您介意，您可以不回答。我在有空的时候参与一个开源项目，我们有一些恼人的非技术问题。问题实际上是人，我想您知道我指的是哪些人：他们总是为了看似最琐碎的事情与其他项目成员争吵，或者他们对项目贡献很少，但似乎需要大量帮助来满足他们的特定需求。我发现自己想，如果这些人消失就好了，但我不认为在我们的邮件列表上就这些事情发起口水战真的会有帮助。
对这个非技术问题有什么想法吗？
精疲力尽
亲爱的 BO，
您是对的，发起口水战不会有帮助。我实际上从未理解那些发起和维持口水战的人从中得到什么，但我总是能找到更有效的方式来引起别人的注意——通常是当面侮辱他们，说实话，这更有趣。
事实证明，大多数项目都涉及人，通常超过八个人。八个人是人类群体似乎能够为了一个目标而合作的极限，也大约是一场愉快的晚宴的合适规模。一旦您必须让人们参与技术项目，就会出现管理问题。如果您认为在工作环境中与人打交道很困难，至少还有解雇无用之人的隐性威胁，那么管理一个志愿者项目的问题会让您怀念您曾经为之工作过的暴虐经理。
您描述的这类人已经被 Subversion 源代码控制系统的两位开发者 Ben Collins-Sussman 和 Brian Fitzpatrick 很好地记录下来，并且很有趣。他们将这些人称为“有毒的”，并在多个场合（包括 Google 视频 (http://video.google.com/videoplay?docid=4216011961522818645)）中展示了他们关于如何应对这些人的非常有趣的观点。
我不会重复他们的整个演讲，但他们提出的几个观点非常值得在任何项目中记住，而不仅仅是开源项目。
他们指出的一件事是，参与任何项目的人都需要有共同的价值观，他们的价值观列表包括礼貌、尊重、信任和谦逊。KV 的老读者可能会震惊地发现我也有相同的价值观，而且我的列表不包括殴打或暗杀。虽然对大多数人来说，每个人都应该得到礼貌、尊重和所有其他尊重似乎是显而易见的，但任何在过去 15 分钟内阅读过邮件列表的人都可以很容易地找到对话沦为 Monty Python 的飞行马戏团的“辩论诊所”重演的例子。如果您还没看过，请去找来看看，网上有。我会等。
人们出于多种原因加入开源项目，而且让我们面对现实，有时他们的理由并不完全无私。如果您是项目的一份子——特别是如果您运行一个项目——您需要决定的事情是，特定的人是在贡献、中立还是在消耗资源。贡献者很棒，但项目中的大多数人只有很少的时间做出贡献。最大比例的人可以被认为是中立的：他们贡献不多，但他们也不会不必要地消耗资源。项目的用户很好地属于中立类别，您希望留住他们。然而，消耗资源的人是需要被清除的有毒的人，原因有几个。
第一个原因很明显：他们是项目的负担。第二个原因不太明显：有毒的人经常赶走贡献者，他们认为没有必要花费他们宝贵的时间来重提旧的争论或遭受虐待。有毒的人让您的项目看起来不像是一个工作的好地方。如果一个新用户或可能的贡献者开始阅读您的邮件列表存档，而他们看到的只是充斥着琐碎的争论和恶意，那么这个新人不太可能在您的项目中走得更远，除非这是他或她绝对需要且在其他任何地方都无法获得的东西——而很少有项目符合这种描述。
摆脱项目中“有毒人物”的最佳方法是根本不要让他们进来。一些大型开源项目有一个导师制度，新贡献者只有在得到社区其他成员的认可，并在某种程度上融入或被教导项目的规则后，才能成为社区的正式成员。这种建议似乎只在处理贡献者时有用，但它也应该应用于决定允许谁加入您的邮件列表或其他沟通系统。如果有人具有辱骂性、有需求或以其他方式成为负担，那么请要求该人离开，而且越早越好。一个人继续成为负担的时间越长，以后就越难摆脱他或她。
要获得对这些观点以及更多观点的更长且可能更诙谐的阐述，请参阅 Collins-Sussman 和 Fitzpatrick 的完整演示文稿。
KV
亲爱的 KV，
在我们每周一次的工作项目会议上，我们试图找出如何处理我们的软件卡死问题。该系统是一个多线程服务器，没有面向用户的部分，它从我们的联网应用程序收集和排序数据。一个人（不是我）建议我们只需编写另一个程序，检测软件何时卡死并重新启动它。毕竟，在现代计算机上，重新启动程序不需要那么长时间，丢失少量数据总比系统卡死直到人工操作员来正确关闭并重新启动程序要好。这种程序常见吗？
随机重启
亲爱的 RR，
请，请，请告诉我您不是在银行、证券公司或信用卡公司工作。除非您丢失的少量数据是我的酒吧账单。
您提到的这类程序通常被称为看门狗程序，原因现在应该很明显了。看门狗代码在设备驱动程序中很常见，因为某些设备很容易混淆，如果卡死则需要硬复位。在设备驱动程序的情况下，一段特殊的代码——看门狗例程——被设置为定期调用，例如每秒一次。它的工作是唤醒、检查设备状态，并在设备似乎卡死时采取必要的措施。这种代码应该谨慎使用，我只愿意在处理难以更改的系统时容忍它，例如损坏但非常流行的硬件。我不会在这里点名，因为我不想与 律师交谈，但查看任何开源操作系统，您都会发现英雄般的设备驱动程序如何帮助有缺陷的硬件勉强运行的绝佳例子。
在纯软件系统中，看门狗程序不应该是必要的。虽然编程很复杂，而多线程系统编程则更加复杂，但软件系统应始终处于其程序员的控制之下。卡死应该是偶发事件。如果您的系统频繁死机，以至于您发现自己正在编写一个唯一的工作就是重置它的程序，那么您和您的团队作为程序员已经失败了。请到人力资源部领取解雇通知。
不，等等……实际上是时候调试、重写或重新设计您的系统了，您的首要任务应该是按顺序进行——而不是像许多牛仔程序员喜欢的那样反过来。“哦，程序又死机了。我们可以用 10 人的团队花两年时间来做好这件事吗？” 不！太多时候，人们认为一个错误是无法修复的，必须重写，仅仅是因为他们喜欢编写新代码胜过修复旧代码。不幸的是，这些人正是根本不应该编写代码的人。
KV
KODE VICIOUS，凡人称之为 George V. Neville-Neil，以编写网络和操作系统代码为乐，并以此营利。他还教授与编程相关的各种课程。他的兴趣领域是代码探险、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，自 1990 年以来在旧金山安家落户。
最初发表于 Queue 第 6 卷，第 1 期—
在 数字图书馆 中评论本文
© 保留所有权利。