文章目录

今天和同事一起领了一个故事卡来做。看完用户故事卡中的描述和验收准则后一头雾水,不知道从哪里下手。由于卡中提到了几个模块都属于遗留系统中的功能,以前没有触及这些模块,对业务、对代码都不太了解。而且还要对这些模块进行修改,而这部分代码都是陈旧的EJB代码,复杂冗长,配置繁琐,修改点无法确定,影响范围无法预估。

那么接下来该怎么办那?

可能很多人都选择深入代码内部,从代码入手来搞清楚功能。我们刚开始想尝试这种方式,在EJB的代码群里跳来跳去,还是不明就里。我想这样不行啊,看到猴年马月去了。

这时候我就意识到我的方向错了。代码是业务逻辑的实现,应该先有业务逻辑,再有代码。我们这样反推只能会深陷细节,很难从中了解到整个业务逻辑的来龙去脉。

咋办那?找BA(需求分析师)呗。我们把BA拉过来,让她挨个把这张故事卡中的关联模块讲清楚。为什么我们要做这样的事情?这样做对用户来说能带来什么好处?做这样事情的场景是怎样的?…..

解答了这些问题以后,我们逐渐明白了这个故事卡的业务逻辑,也有信心来完成这张卡了。

接下来是不是要回到代码来看具体实现了那?非也,我们并没有急着看代码,而是消化了业务知识以后,打开了我们的功能性测试的项目,在里面查与该模块功能相关的功能性测试。由于这些测试是使用BDD框架写的,所以可读性非常强,并且本身就描述了使用场景与案例。看了这些功能性测试我们一可以加深对需求的了解;二知道了当前这张故事卡牵扯到的模块的覆盖率是个什么情况,有助于我们修改后不会破坏已有的功能;三是有助于我们为修改后的功能补上功能性测试。并且我们可以顺着功能性测试来查看该功能模块的调用情况,根据调用情况来深入该功能的代码细节,找到潜在的修改点。

通过功能性测试入手,我们阅读代码确实快了不少,很快就找到了潜在修改点。那么现在要动手修改吗?答案是否定的。我们又回到了功能性测试的项目,为我们即将要改变的功能加上了自动化测试。这个时候测试应该是跑不过的。然后我们才动手修改代码,完成功能修改。然后再次运行针对新功能的测试,一切OK。

完成了这个故事卡给我带来了成就感。不只是因为我们解决了这个故事卡上的问题,而是让我们学到了额外的知识。我们不能整天只为写代码而写代码,而是应该真正的以业务需求为核心,把需求吃透。一个程序员能够保证把事情做正确是远远不够的,而是能够确保他做的事情是正确的。

一个程序员在领到一个故事卡时,不应当急着写怎么实现,而是应该向业务分析师质疑,为什么我要做这个功能?加了这个功能能给用户带来什么价值?有没有其他简单的方式来达到甚至超越这个卡给用户带来的价值?只有当这些问题都被解决了以后,才能进行开发。现在你已经是了解需求的专家了,相信在编写代码考虑实现方式时,有足够的上下文了。

文章目录