程序员的生产效率源于需求，而不是工具！

程序员的生产效率源于需求，而不是工具！

　　你确定你真的知道到底是什么促使一个程序员高效率的吗？是因为使用了VIM和Emacs这些强大的编辑器，还是因为应用了最新的Haskell Web框架，抑或是你最喜欢的NoSQL数据库？ 　　很抱歉，如果你注重的是工具、框架，甚至是进程，那么我不得不说，你搞错了！程序员生产效率的真正起源是：正确的需求。

　　为什么你作为一名程序员也必须关心需求——而不仅仅是业务人员！ 　　显然，产品负责人必须满足客户的需求，因为这样才能让客户心甘情愿地付出报酬。对此，开发人员又是怎么看的呢？ 　　曾经有位开发人员说出了大多数人的心声：“直接构建。出现了问题，就放到开发过程中处理。这样，至少我们开了一个头，不是吗？“ 　　我们将这种做法称之为：马上启动，永不结束——一开始构建的时候没有什么准确的目标，至少有一半的内容是尚不清楚的。 　　你怎么知道你已经搞定了？ 　　由于并不是100％了解，所以在开发过程中状态百出——不知道接下来该做什么，自以为快完成了却这里忘记了，那里有遗漏，功能不匹配，等等等等。 　　再问一句，请问你打算如何去测试模糊不清的需求呢？对此，你最喜欢的BDD工具可是束手无策的哦。 　　如果输入是不明确的，测试也是不明确，那么输出就更加不明确了。 　　你总是特别有积极性，可能吗？ 　　所有开发人员都非常讨厌的一种情况是，业务人员频繁地给出不确定的需求。这表明业务人员本身也不知道客户真正想要什么功能。 　　而这也意味着，很多你构建的东西会被弃之于垃圾桶。一鼓作气，再而衰，三而竭，程序员的积极性就是这样给磨灭的。 　　那么什么样的才算是正确的需求？ 　　现在说说什么样的才是正确的需求？是不是一句写在索引卡上的话——“作为一个用户我希望能够使用亚洲建行信用卡”，好了，over，就ok了呢？ 　　一个正确的需求包括（1）经过业务人员和程序员双向的沟通和研究；（2）反复解构，解构，再解构；（3）论证，其中包括我们常说的”angling“和”skinning“。 　　拜托！我是一个程序员，需求不是我的工作！ 　　的确，在一些大型的公司中，通常会有专门的业务分析人员，其唯一的工作职责就是在递交给实施团队之前先整理出详细的需求说明。在理想的情况下，你只要照着说明编码就行了，但是，这在现实中显然是不可能的。 　　而且，企业越小，程序员的工作就混杂。可能你的老板就是这么认为的：你，作为一个”程序员“不仅要知道怎么实施，也应该清楚需求。 　　无论如何，你都应该专于此！ 　　升级AngularJS 2.0路径肯定比研究客户的问题领域和需求要有趣的多——这是毋庸置疑的。 　　但是，你的技术技能，你的框架，还有你的算法都只是你每天日常工作的一部分。而所有开发工作的依据却是：正确的需求。