gstreamer编码效率_两个人的编码效率是原来的两倍，对吗？

gstreamer编码效率

站在理性上，不是吗？ 如果一个人每小时可以制作5个小部件，那么两个人每小时可以制作10个小部件。 这只是事物的自然方式。 你不能与科学争论。

软件显然也是如此，不是吗？ 如果一个开发人员每小时可以编写10行代码，那么显然两个开发人员可以每小时编写20行代码。 如果要编写更多代码，只需雇用更多开发人员。 我的男人几个月没有什么神话。

但是……以某种方式……软件仍然是不可思议的东西 。

这周我有一次有趣的经历。 我和另一个开发人员一直在进行一个新的未开发项目。 我们一直在努力地工作，以不错的速度摘录故事。 直到现在，它已经进入了艰难的阶段，原始的设计思想正在Swift让位给新的问题和新的思想。 随着我们讨论解决问题的更好方法，正在进行实质性的重构。 这看起来很好，很健康。

然后，在那些日子里，有一天我到处转弯都遇到了设计问题。 没有我对设计的脾气暴躁，就不可能编写任何一行代码。 最糟糕的是，我的同事刚刚完成的代码显示了原始设计中的缺陷。 引起很多讨论。 有一次他感叹他“只要能在计算机上运行30分钟，就可以完成任务（这使我无法取得进展）”。 快到下午五点了。

很难找到30分钟的高效编码法则的日子，并不是写太多代码的日子。 噢，我们的工作效率很高，到今天结束时，设计有了很大的改进。 代码？ 这里什么也看不到，请继续前进。 那天我们真的是生产力的两倍吗？ 一定不行。 我整整一天都在分散他的注意力，使他无法完成讨论设计问题的任务。 他整天都在尝试合并一个我的设计重构困难的分支。 我们整天都在互相对抗。

我们可以做些什么？ 好，第一个问题是试图通过相同（小的）代码库维护两个开发活动流。 我们像疯了一样互相绊倒。 放松几天，我们可能只需要一个人就能完成更多工作。 这样，代码中将只有一个叙述线程，一次只有一个重构步骤序列。

等等，再说一遍：如果只有一个人在做这项工作，我们上周会做得更多。 好吧，这只是个疯狂的话题，让我告诉您有关制作小部件的想法，男孩……

我认为我们在构建软件时大大低估了协调和沟通的成本。 从外面看，它很容易错过：用行话进行5分钟的快速对话。 但是……这是魔术发生的地方：这是设计的来源。 但是，如果那5分钟的交谈打断了某人的工作，那么接下来的45分钟可能会丢失，因为他们尝试将正在处理的内容重新加载到内存中。 在您的一天中会堆积一些干扰，也就不足为奇了。

显然，我们应该做的却不是配对。 这样，只有一个叙述线程。 一次应用一个想法序列。 只有一个键盘，整齐地序列化更改。 当然，通过配对，我们仍然可以进行设计讨论-但它们会在我们俩都陷入困境的时候出现。 当您俩都已沉浸在问题中时，没有中断的代价。 通过配对，我们将停止彼此合作，并为设计讨论创造了一个无中断的空间。

所以实际上：两个人可能比一个人更有生产力。 两人结对绝对比一个人独自工作要好。 让我意识到，我们一直在解释所有错误的配对：我们试图证明配对的“成本”合理，好像我们必须以某种方式解释为什么让两个人在同一台机器上工作实际上并不会使生产力减半。 所有这些都是基于错误的假设：在不同机器上工作的两个人的生产力是一个人工作的两倍。 一旦您意识到此假设存在根本性缺陷，配对的“成本”就会消失。 相反，配对消除了两个开发人员之间协调的成本：无间断，无分歧的想法，无合并冲突。

结对编程实际上是一种节省成本的工作。

翻译自: https://www.javacodegeeks.com/2015/06/two-people-coding-is-twice-as-productive-right.html

gstreamer编码效率