ACM通信
Kode恶性
外包责任
亲爱的KV,
我被指派帮助一个新项目，并一直在查看团队放在内部wiki上的公认的简短文档。我花了一天左右的时间，盯着项目团队成员打算集成到他们正在构建的系统中的一长串开源项目列表，但我找不到他们最初工作的描述。我问了一个项目团队成员，我可以在哪里找到文档，并被告知他们真的不需要太多的文档，因为他们需要的所有功能都可以在github上的不同项目中找到。
我真的不明白为什么人们不理解外包工作也意味着外包责任在软件项目中，责任和责任是最重要的。
有责任感
亲爱的负责,
虽然“在github上叉我”风格的系统设计似乎是一个新事物的出现，但不幸的是，我必须向你保证它不是。自从软件库的发明以来，在我出生之前的某个时候，可能在你出生之前，一个人可以通过获取所需的比特来构建一个系统的想法一直是构建软件的方式。我们都依赖于我们没有写过的代码，经常依赖于我们甚至无法阅读的代码，因为它是以二进制形式出现的。就算我们能读懂，对吧?OpenSSL的代码是开源的，任何关心或敢于阅读的人都可以阅读，但“心脏出血”漏洞却被埋没了两年之久。问题不仅仅在于是否能够看到代码;它更多的是与你可能要拖进去完成工作的内在复杂性有关。
我们都依赖于我们没有写过的代码，经常依赖于我们甚至无法阅读的代码，因为它是以二进制形式出现的。
你可以询问其他团队成员，为什么没有任何文档说明他们打算如何将下载的各个片段拼接在一起。即使许多部分是由预先存在的软件组成的，也必须有一个如何集成它们的体系结构。在没有建筑的情况下，一切都是混乱的，在有机模型中建立的系统只能运行一段时间，但最终它们会腐烂，它们发出的恶臭是即将到来的末日的恶臭。
软件系统总是由其他组件构建而成，您需要问的问题是:我正在使用的组件有多可靠?API有多稳定?我了解如何使用这个组件吗?我来给你解释一下。
软件的可信性不仅仅是知道某人是否以窃取信息为目的而编写它的问题，尽管如果您从一个由三个字母组成的机构获取椭圆曲线代码的因子，您可能需要认真考虑这一点。要说软件是值得信任的，就是要知道它有一个良好的跟踪记录，经过多年的良好测试，在面对滥用时保持稳定。人们总是会在软件中发现漏洞，但是当我们使用一个值得信任的软件时，我们都知道它是可靠的，因为它很少在运行中出现故障。
api的稳定性是我在其他回答中提到的，但是它需要，或者应该说似乎需要，频繁地重复。如果你在开车，给你指路的人每隔一个街区就修改一下方向，你会认为那个人不知道他或她要去哪里，你可能是对的。类似地，如果一个软件的api具有Jell-O的稳定性，则说明构建这些api的人在项目开始时并不真正知道他们在做什么，现在可能仍然不知道该软件已经有了用户基础。我经常遇到这样的系统，它们看起来是为了快速解决问题而编写的，并且在某种程度上让谷歌或Facebook为用它们创建的任何可疑服务支付大量现金。一个API不需要写在石头上，但它应该足够稳定，你可以依赖它超过一个点发布。
理解组件的使用是github一代最容易失败的地方。有些程序员会根据他们想要解决的问题进行搜索;在堆栈溢出中找到指向问题解决方案的网页或条目;然后，在不做任何尽职调查的情况下，将该组件拉到他们的系统中，而不管该组件的大小、复杂性或最初的预期用途。举个简单的例子，我在github的搜索框中输入“红黑树”。然后它说:“我们找到了259个存储库结果。”这意味着红黑树有259种不同的实现。当然，它们跨越了不同的语言:
我们如何评估所有(任何)这些实现?我们可以根据用户评分(也就是“星星”)和分叉(即某人尝试扩展代码的次数)对它们进行排序。这两种测量方法都不客观。我们仍然不知道代码的大小、API的稳定性、性能或代码的预期用途，而且这是针对相对简单的数据结构，而不是针对一些巨大的代码块，如Web服务器。
要知道一段代码是否适合您使用，您必须阅读作者是如何使用它的。如果作者提供了文档(是的，我会等到你不再笑)，那么这可能会给出他或她的目标的暗示，然后你可以看看它是否与你的相匹配。所有这一切都是在每天用小小的手指输入的软件海洋中航行所需要的尽职调查。
最后，有一点你说得很对:你可以把工作外包出去，但说到底，外包责任要困难得多。
KV
亲爱的KV,
当调试器失败时，您该怎么办?在过去，您已经谈到了不用打印语句就可以发现错误的工具，例如printf ()但当工具出现故障时，我发现我必须使用某种形式的蛮力来发现问题并解决它。
我正在处理一个程序，当我们为一个应该没有副作用的操作转储系统状态时，状态明显发生了变化;但是，当然，当调试器附加到程序时，状态保持不变。在我们诉诸于打印声明之前，也许你可以再提一个建议。
蛮强迫
亲爱的蛮,
工具，就像编写它们的人一样，都不是完美的，我不得不求助于各种形式的强制调试，放弃调试器而使用低级的print语句。
不过，从您所写的内容来看，另一种形式的蛮力可能更合适:二分搜索。如果您有一个导致副作用的长时间运行的操作，要找到给您带来麻烦的操作部分，最简单的方法是将操作分解为多个部分。您可以用只有一半的输出触发错误吗?如果是，是哪一半?一旦识别出有bug的那一半，再将该部分分成两半。继续一半的过程，直到你缩小了问题的位置，好吧，不是完全瞧，但你肯定会比诅咒你的调试器取得更多的进展，如果你调试的系统段真的很大，这将比添加大量的打印语句花费更少的时间。
工具，就像编写它们的人一样，并不是完美的，我不得不求助于各种形式的强制调试。
打印语句通常会掩盖计时错误，因此，如果错误与计时有关，添加打印语句可能会误导您认为错误已经消除。我见过太多程序员在发布软件时启用了调试和打印语句，尽管消息会进入/dev/null，只是因为“它在打开调试时工作”。不，它不能“在调试打开时工作”;调试掩盖了错误，您很幸运。当正确的时刻到来时，软件的用户将是不幸的，无论打印语句如何，都有一个计时错误。我希望你不是在研究制动系统或航空电子设备，因为，好吧，砰。
如果您的目标是找到bug并修复它，那么当您的更好的工具失败时，我可以推荐分而治之作为调试方法。
KV
相关文章
在queue.acm.org
外包:设计一个游戏计划
亚当Kolawa
http://queue.acm.org/detail.cfm?id=1036501
在活动系统上调试
乔治Neville-Neil
http://queue.acm.org/detail.cfm?id=2031677
动态环境中的事后调试
大卫·帕切科
http://queue.acm.org/detail.cfm?id=2039361
数字图书馆是由计算机协会出版的。版权所有©2014 ACM, Inc.
没有发现记录