做一张故事卡时的感悟
今天和同事一起领了一个故事卡来做。看完用户故事卡中的描述和验收准则后一头雾水，不知道从哪里下手。由于卡中提到了几个模块都属于遗留系统中的功能，以前没有触及这些模块，对业务、对代码都不太了解。而且还要对这些模块进行修改，而这部分代码都是陈旧的EJB代码，复杂冗长，配置繁琐，修改点无法确定，影响范围无法预估。
那么接下来该怎么办那？
可能很多人都选择深入代码内部，从代码入手来搞清楚功能。我们刚开始想尝试这种方式，在EJB的代码群里跳来跳去，还是不明就里。我想这样不行啊，看到猴年马月去了。
这时候我就意识到我的方向错了。代码是业务逻辑的实现，应该先有业务逻辑，再有代码。我们这样反推只能会深陷细节，很难从中了解到整个业务逻辑的来龙去脉。
咋办那？找BA（需求分析师）呗。我们把BA拉过来，让她挨个把这张故事卡中的关联模块讲清楚。为什么我们要做这样的事情？这样做对用户来说能带来什么好处？做这样事情的场景是怎样的？…..
解答了这些问题以后，我们逐渐明白了这个故事卡的业务逻辑，也有信心来完成这张卡了。
接下来是不是要回到代码来看具体实现了那？非也，我们并没有急着看代码，而是消化了业务知识以后，打开了我们的功能性测试的项目，在里面查与该模块功能相关的功能性测试。由于这些测试是使用BDD框架写的，所以可读性非常强，并且本身就描述了使用场景与案例。看了这些功能性测试我们一可以加深对需求的了解；二知道了当前这张故事卡牵扯到的模块的覆盖率是个什么情况，有助于我们修改后不会破坏已有的功能；三是有助于我们为修改后的功能补上功能性测试。并且我们可以顺着功能性测试来查看该功能模块的调用情况，根据调用情况来深入该功能的代码细节，找到潜在的修改点。
通过功能性测试入手，我们阅读代码确实快了不少，很快就找到了潜在修改点。那么现在要动手修改吗？答案是否定的。我们又回到了功能性测试的项目，为我们即将要改变的功能加上了自动化测试。这个时候测试应该是跑不过的。然后我们才动手修改代码，完成功能修改。然后再次运行针对新功能的测试，一切OK。
完成了这个故事卡给我带来了成就感。不只是因为我们解决了这个故事卡上的问题，而是让我们学到了额外的知识。我们不能整天只为写代码而写代码，而是应该真正的以业务需求为核心，把需求吃透。一个程序员能够保证把事情做正确是远远不够的，而是能够确保他做的事情是正确的。
一个程序员在领到一个故事卡时，不应当急着写怎么实现，而是应该向业务分析师质疑，为什么我要做这个功能？加了这个功能能给用户带来什么价值？有没有其他简单的方式来达到甚至超越这个卡给用户带来的价值？只有当这些问题都被解决了以后，才能进行开发。现在你已经是了解需求的专家了，相信在编写代码考虑实现方式时，有足够的上下文了。
