程序员的工作不能用“生产汇海”这个词来衡量

　　英文原文：There's No Such Thing As Software Productivity

　　通过重复的攀谈，Bill Caputo最终说服了我，让我信赖了一些不行思议的事情。这些事情改变了我整个看问题的方式，也让我重新思索怎样更好的事情。

　　软件开发中没有“生产效率”。

　　险些正如10年前 Martin Fowler 发现的，用生产效率来权衡软件开发事情没有任何意义。缘故原由就在于，它们不属于统一领域。换句话说，生产效率不具有作为权衡软件开发事情的适用性。“今天缔造了几多代码/软件？”这是一个没有意义的问题。纵然可以这样丈量，软件开发事情上的生产效率也不能以任何有意义的方式预计出它的商业价值。

　　这是由于，软件开发这种事情并纷歧定非要生产出什么工具。让我来举个例子：好比说，恰巧有两个程序员划分在开发两个完全一样的项目，他们在统一天被分配了相同的使命。第一小我私家，弗兰克，回到电脑前，写出了一个有1000行代码的框架，完善的解决了问题。代码规范誊写，周全测试，有详细的文档形貌部署和操作的流程。第二个程序员，皮特，转身去了公园，在那里，他一边喂鸽子一边思索问题。或许在下战书4：45分，皮特溜达回办公室，删掉了200行代码，并部署了他的修改…问题就这样解决了。

　　这两个程序员，今天的“生产效率”谁的更高？谜底是：这无关紧要。紧要的是，皮特解决了问题，同时为团队消减了恒久维护的成本。弗兰克同时也解决了问题，但他由于生产了代码，提高了维护成本，以是，(在其它方面完全等效的情形下)他的方案差一些。而把皮特称作更有“生产效率”，则完全从实效性上扭曲了这个比喻。

　　我以为，优异的程序员，他所做的事情应该是去除问题。而相对的则是生产出什么。以是，手艺上的生产产物，例代码，文档，数据等，对于实现“去除问题”的目的来说，都是须要但有害的。这就是为什么有时间，这最有用的解决方案是5分钟的交流相同。

　　对这种思索模式最有力的支持：当你用这种头脑去看待软件开发后，许多棘手的、能看获得但无法丈量的问题突然间变得很容易明白。例如，为什么当程序员和他们的客户隔脱离时会显得缺乏效率。岂非让他们制止打扰不会提高事情效率吗？谜底是不会，按常理这会使他们更有用率…但也会造成他们更没效率。由于他们的事情是为客户解决问题，与客户的阻遏导致他们无法找到问题，确定问题。相反，跟有问题的人保持相同能更有用的解决问题，甚至有时间你一天8小时手指基础不需要碰键盘。

　　这将我们引向了另外一个问题：为什么软件开发中维护成底细比起其它方面的成本显得很难接受？为什么我们永远无法在第一次做出“准确”的工具？一种诠释就是，软件是一个对可能转变的问题的牢固解决方案。当问题发生转变时(或我们对它的明白发生转变时)，问题息争决方案之间就泛起了裂痕。这种随着问题的演变而一直的修补发生的漏洞的运动价格高昂。这也诠释了为什么相对于其它软件项目，视频游戏通常的维护成本较低。这是由于它们需要解决的问题(让人们去买这个游戏，玩这个游戏)基本上是凭据人类心理学，而这是不常转变的。

　　好的程序员和坏的程序员之间10倍之差的“生产效率”又是从何提及？每小我私家都说这是事实，但事实上没有人能直接的测评。我们的理论同样能诠释这个问题。相比起事情效率来说，“解决问题”是一种更容易“调控”(金融词汇)的工具，使得发生一个数目级差异的效果很容易实现。解决问题需要的是信息和洞察力。你要么有，要么没有。不需要原质料，没有生产能力限制。并不是差的程序员打字速率慢。并不是若是他们起劲就能做得更好。他们是缺乏这种高效解决问题的眼界和须要的信息。也许无法丈量好程序员和差程序员在生产效率上的差异的缘故原由就在于没有工具可丈量。

　　另有许多征象都可以用这个理论app开发来诠释。若是你去找，一定能发现一些。最近我一直在搜罗这方面的案例….试一试，看看这个理论是否也体现在你的事情中。每当发现自己在说提高“生产效率/事情效率”时，问问自己是否是在用准确的方式解决问题。铭刻在心：若是不通过

 1/2    1 2 下一页 尾页