程序猿的生产力始于需求而非工具

本文来源于我在InfoQ中文站翻译的文章。原文地址是：http://www.infoq.com/cn/news/2015/07/programmer-productivity

Marco Behler是一位资深开发人员与市场营销人员。同一时候也是Marco Behler GmbH的创始人。近日，Behler就程序猿生产力这一话题展开论述，在社区产生了较大的影响。

你真的知道影响程序猿生产力的关键因素是什么吗？是VIM、Emacs、最新的Haskell Web框架。还是钟爱的NoSQL数据库呢？遗憾的是，假设你将关注点放在工具、框架或是流程上，那就说明你还是没有真正理解这个问题。我觉得，影响程序猿生产力的关键因素在于起点：恰当的需求。

作为开发人员缘何要关注需求，这难道不是业务人员的事情？

当然了，创始人/产品经理/团队领导必须要关注这个问题：究竟开发什么才干让客户终于埋单呢？但假设从开发人员的视角看待这个问题会是怎样的呢？有时会出现这种情况，有人拍打桌子，大叫：如今就開始开发XYZ，立即，立马。假设中间出现故障。我们能够在开发过程中解决。这就叫做先发优势？其实。我们称之为：尽快開始，但永远不会结束。非常有可能你所开发的一半以上的东西都是不清晰的。

你怎么知道自己完毕了？

意料之中的。假设不能全然理解需求，那就会导致遗漏，当问起什么时候能够开发完。你可能会忘记这个，忘记那个。

那么该怎样測试不清晰的需求呢？这与你喜欢的BDD工具没有不论什么关系。假设输入不清晰，那么測试也不会清晰，输出就更不清晰了。

你总是自我激励。对吗？

只是更糟糕的是，频繁的不清晰的需求是个信号，表示业务人员不确定客户究竟想要什么。遗憾的是。这也表示你所开发的非常多工作都是徒劳无益的。假设这种情况频繁出现。就会对程序猿的生产力造成非常大的破坏，这将严重影响程序猿的效率。

究竟什么才是恰当的需求？

那么什么才是恰当的需求呢？我觉得恰当的需求的制定过程应该是以下这个样子的：

• 须要业务人员与程序猿共同讨论，而且经过两方充分的沟通
• 须要不断拆解、拆解、再拆解
• 不断打磨，经得起推敲

我是个程序猿，需求的事与我无关？

诚然，在大型组织中可能会有专门的业务分析师，他们的主要工作就是在将具体的需求规范传递给实现团队之前对其进行不断的完好。

在理想情况下。这么做是完美无缺的，你仅仅需坐在那儿编写代码即可，只是实际情况却并不是如此。

不管怎样。组织的规模越小。程序猿须要处理的事情就越多。公司的创始人可能会拍着桌子大喊：作为程序猿的你不仅要负责实现，还要关注需求的产生过程。

不管怎样。你都应该成为一名专家

对于你来说，可能阅读AngularJS 2.0的升级路径要比与客户讨论领域问题和需求更有趣。只是，我想说的是，你的技术、对框架或算法的理解仅仅是你每天工作的一部分。

对于全部开发工作来说，基础则是“恰当的需求”。

Behler的文章刊出后非常快就引起了众多开发人员的共鸣，非常多人也纷纷表达了自己的观点，以下摘录出一些典型反馈以飨读者：

Sasi Pallekonda说到：

说得太棒了！

开发人员不仅要考虑该使用什么数据结构，还须要思考需求是怎样匹配终于用户的，而且怎样实现需求，读了Behler的文章获益匪浅。

Erik Gollot说到：

非常允许文中的观点。我如今对怎样编写好的需求非常感兴趣，由于依据我的经验，用户故事是远远不够的。

Wes Higbee说到：

非常允许Behler的看法，对此我也做了深刻的思考。我觉得：方向要比速度更为重要，仅仅有确定了方向。速度才是有意义的，否则再快的速度也是徒劳无益的。

Jussi Laasonen说到：

非常多时候，人们都觉得敏捷软件开发仅仅只是是“立马開始构建XYZ”。但其实，这么做是全然错误的。

Fayez Naccache说到：

我已经在我们称之为精益创业的组织中工作6个多月了。在这期间，我们没有计划、没有具体需求、没有你所说的恰当的需求。我觉得工作起来非常困难，一点动力都没有。我非常喜欢文中的这句话：尽快開始，但永远不会结束；还有不管怎样。组织的规模越小。程序猿须要处理的事情就越多。这对我如今的工作来说真是再恰当只是的描写叙述了。

Eliseu Monar说到：

Eric Evans曾介绍过一种“普适语言”，能够消除团队成员之间沟通的障碍，我非常喜欢这本书。Martin Fowler对此也有过介绍：

普适语言是Eric Evans在Domain Driven Design一书中所使用的术语，用于描写叙述怎样在开发人员与用户之间构建出一种通用且严格的语言。该语言应该基于软件开发中的领域模型。因此它应该是非常精确的，由于软件是无法处理模糊问题的。

Evans表示在与领域专家沟通时使用普适语言是非常重要的，这有助于測试和领域模型的实现。此外，普适语言（以及模型）还应该随着团队成员对于领域理解的不断增强而不断演化。

普适语言的提出者Eric Evans对此则觉得：

通过大规模使用基于模型的语言。我们能够构建出一个完整且可理解的模型，该模型由一些简单元素构成，这些简单元素终于能够表达出复杂的概念。

领域专家应该对那些笨拙且无法传达领域含义的术语或结构持反对意见。开发人员应该警惕那些影响设计的模糊之处与不一致性。

Behler关于程序猿生产力的文章引起了非常多人的共鸣，同一时候他也专门编写了一本名为Customer Requirements的图书。

该书主要介绍了需求沟通的技巧、怎样恰当地进行估算、怎样防止模糊不清的需求产生、怎样与同事和客户沟通需求、恰当合理的需求对于开发与測试会产生哪些积极影响，同一时候每一章都提供了实际的样例供大家參考。

程序猿生产力这一话题是每个开发人员都津津乐道的，那么对于你来说，影响生产力的因素都有哪些呢。最好还是分享出来我们一同讨论。

转载于:https://www.cnblogs.com/ljbguanli/p/6999256.html