程序员生产力提升之路——Step1：需求分析

9:00 AM，你的老板突然冲进办公室，说：“市场希望我们的网站能够做一个新的花式登录框。只需要提供用户名和密码字段成不？也许加上恢复链接也成。时间应该不用超过两天。哦，我得走了，赶紧的！”

碰到这样的情况，通常会让人瞬间变身咆哮帝，但是，这一会，你可以保持冷静了：因为你学会了如何解构。

什么是解构？

解构就是将需求分解成尽可能小的片段，然后对这些片段予以整理和阐述，最后成为你（程序员）和你老板/客户之间的共识。

如果有人给你的是一个现成的规范，也没关系。一切始于解构！

我已经在编码了，为什么还要解构呢？

是的，也许你已经在使用AngularJS捣鼓如何ng-submit()你的登陆表单了，并且感觉比按部就班地先进行Struts 1要容易得多了。哦，no，赶紧悬崖勒马吧！

我们首先要做的是对需求做稳健性的检查。分解。 “我希望用户能够通过框来登录”并不是一个正确的需求。

听起来特别easy，有木有？我的意思是，你可以在短短的几分钟的时间内搞定，是不是？好吧，让我们继续往下看…

有没有一些关于现实生活中的实例呢？

这个还真有，从我的经历来看，这个真实的例子就发生于2011年2月，德国的一家汽车制造商对于他们新网站的需求。

请看下面这张图片的左下角。请注意看那个登录框。看上去多么小巧简单啊，但实际上是非常复杂。让我们来看看为什么…

首先，关于如何解构？

你应该和技术驱动和业务驱动人员一起携手。所以需要说服老板获得更多的INPUT！

哦，对了，如果必要的话，可以加人。不过，根据我以往的经验来看，整个团队来做解构工作将会大大浪费时间、金钱和精力——但这是另一个话题了。

接下来，打开你喜欢的书写工具，可以开始问一些“幼稚”的问题了。然后将答案一一记下来整理。这些“幼稚”问题是什么呢？—— “那是什么？”，“是什么造成这样的后果？”,“为什么我们需要它？”,“还有没有其他部分？”。

至于要问多久？要么问完问题，要么其他人嫌弃你了

关于实例？

继续回来说上面的例子：“我们需要一个登录框”。首先进行分解： 1我们需要2登录[3]框。假设1在那个时候已经给出，那么可以从2开始。

关于[登录]部分的问题

你：“登录是什么？”
商务人员：“嗯，用户名和密码应该就足够登陆了。 ”
你：“用户名亦或是电子邮件？”
商务人员：“都可以！”
你：“等一下，谁是我们的用户呢？”
商务人员：“这么笨。想要我开掉你么？每个通过网站注册的就是用户。”
你：“每个都是吗？”
商务人员：“嗯，是的。不过，高层管理人员这么提过，如果是那些已经买了宝马车的用户，就可以通过客户编号登录到网站，并自动获取访客帐户。”
你：“呃，那我们怎么获取这些客户的表单呢？”
商务人员：“从CRM系统。平行于我们自己新建的用户数据库。哦，顺便说一句，有几种不同的CRM系统，所以需要说明原因。”
你：“呃，客户编号，然后给他们发送密码，还是他们已经有密码了直接登录就可以了？”如果CRM系统不可用的时候怎么办？什么是自动访客帐户？他们怎么知道他们突然就能登录？……救命！

=>继续问问题

先暂停会，来看看[框] 部分

你：“框是什么？”
商务人员：“差不多都已经设计好了。用户名/密码字段，登录按钮。还有什么难的呢？”
你：“框只要显示在首页上吗？”
商务人员：“不是的，我们要在若干网页上显示，如有些活动页面。所以在你的CMS系统中应该将它做成一个组件。”
你：“组件？啊哈。呃，你知道HTTP/HTTPS的区别吗？我们的网站是运行在HTTP上的，这有点棘手啊（https的内联框架放到http页面上，有点小脑袋爆炸的感觉）……嗯……是不是我们一定要确保用户安全地传输数据呢。”
商务人员：“是啊，是啊。你可以的，我相信你。说到安全，我顺便说一句，也可以禁止用户。他们需要接受新的“条款和条件”，才可以登录到相应的层。否则，我们的律师又要叫了。”
你：“天哪！禁止用户？条款和条件？层？嵌入到内联框架的层还是放到父页上的层？”

=>继续问问题

拜托！我们才刚刚开始！

还有很多很多的内容是没有覆盖到。比如说，基础设施，SSL-Loadbalancers，忘记密码的工作流程，错误消息/信息消息，等等等等。以及究竟是谁说“我们需要登录框”的？客户？那么，谁才是真正的客户呢？

关于HTTP/HTTPS的问题，在制定需求之前，技术和商务人员得先坐在一起讨论。如果没有双向交流，那么你就真的只能在梦里实现了。

最后但并非是最不重要的，关于这个例子，我们甚至还没有完全解构——相反，这还只是冰山一角而已。

森林森林森林，没有树哪来的森林？

在问了一系列的问题之后，我们首先需要整理阐述这些问题。在没有整理阐述之前，你不能规划，亦无法估算，否则，差之毫厘，谬以千里。

自然，在没有完成这些步骤之前，先去敲代码肯定是不正确的。先好好提炼这些问题吧，就像淘金一样，去伪存真。

下一步：是的，离完成任务还远得很呢。这还仅仅是解构的开始。

在以后的文章里，我会继续写解构以及后面的步骤，敬请期待。如有不同意见，也欢迎指正。

译文链接：www.codeceo.com/article/programmer-productivity-step-1.html
英文原文：A PROGRAMMER’S ROAD TO PRODUCTIVITY – STEP 1 : DECONSTRUCTION OF REQUIREMENTS
翻译作者：码农网– 小峰