zoukankan      html  css  js  c++  java
  • 行为驱动开发学习心得(一)

    最近在看《The Rspec Book》这本书,主要讲的就是行为驱动开发,先不说这种方式的优劣,通过我看了前2章,觉得这种开发方式目前解决了我以前遇到的问题

    一 业务分析需求了解的情况

     问题 1 口口相传

      我以前做开发,需要和产品经理或者项目分析人员,反复交流 ,首先我先听产品经理和分析人员描述需求,然后再把我理解的和他讲,确保我们的理解没有偏差,然后再开发,但是有时候两个人说完了。没落实到纸面上,有可能过了2天,2个人会忘了细节,或者写着写着忘记了真实的需求

     问题2 画流程图+口口相传

      还有一种就是更好的方式,就是产品经理把流程图画出来,或者把交互UI画出来,但是这些交互都是图,没有语义,并不能表达真实的用户需求,还是需要和产品经理交流,重复上面的口口相传,好处是起码有了交互图或者流程图,或者UI图,产品经理可以把细节画出来,但是开发人员未必会注意到这些细节

    问题3 只有需求文档

      这是最差的一种方式了,特别是处在定制的软件开发中,甲方给了一份文档,只有文字,如果好一点公司会有懂业务的项目分析人员来分析文档再和开发人员交流,差的公司就直接丢给开发人员,自己弄去吧。最严重的情况,就是开发人员看了文档,然后自己的理解和文档的真实描述南辕北辙。最后开发出来的东西不是客户想要的,或者好一点开发过程中,反复修改项目推进很慢

    二 新人进公司对业务不了解,光看代码无法了解业务

      问题4 我曾经在一家公司短暂工作,使我最困惑的是不了解业务,但是又没人给我讲解,导致无法快速融入开发,光看代码,根本不足够了解业务各种细节和场景,只能遇到一个问题问一个,对业务的了解支离破碎,特别是产品还不断改进情况下,业务你还没等了解,或者刚了解一半业务需求就变了。

      问题5 还有一种就是无人可问,同事没时间给你讲,只能自己想到了一点问一点,还得同事有时间情况,或者他简单几句,有些细节照顾不到,自己烦恼,还效率低下。

    行为驱动开发的方式帮我解决了什么

      以上两个问题,是我暂时通过学习BDD觉得可以帮我解决的,有2个框架叫做一个叫cucumber,一个叫rspec

         我们使用Cucumber来描述应用程序的行为,使用Rspec来描述对象的行为,或者说,cucumber来秒数宏观上软件的解决问题,rspec来具体解决实现上的描述

    事例

    1 我们先看Cucumber是如何描述的,这也是书中的例子

      

     1 Feature: pay bill on-line   #Feature就是应用的特性,或者说程序要做的事,pay bill on-line在线支付账单
     2    #下面一段文字就是场景描述或者需求描述
     3     In order to reduce the time I spend paying bills
     4     As a bank customer with a checking account
     5     I want to pay my bills on-line
     6 
     7     Scenario: pay a bill  #这个就是基于特性和场景,要解决问题采用的剧本或者理解为步骤
     8        Given checking account with $50
     9        And a payee named Acme
    10        And an Acme bill for $37
    11        When I pay the Acme bill
    12        Then I should have $13 remaining in my checking account
    13        And the payment of $37 to Acme should be listed in Recent Payments

    这段代码,最好是开发人员和产品分析人员一起来写

    好处1 开发和需求人员采取同一种语言表达形式,交流方便 特别是场景的描述可以解决问题 4 和问题 5,如果新人假如公司,没有时间来讲解业务,起码信任看需求场景描述能了解大概,然后 知道采取的解决步骤(剧本),就是scenario的描述,然后再看代码会帮助很大。

    好处2 有流程图或者只能口口相传,无法让开发人员了解整个场景,描述完场景后,产品人员可以自己写出具体脚本。这就类似伪代码,然后开发人员也可以参与,这样使实现方案更好,如果两个人对实现步骤有歧义,可以讨论,防止再代码开发一半的时候才发现,

    好处3 有时候产品经理自己想不清楚操作逻辑,这时候写剧本(scenario)既可以帮助自己审视自己的逻辑,也可以理清实现思路

    好处4,如果是定制开发,如果甲方可以参与写剧情和剧本,我想可以最大限度减少沟通不明确造成的问题

    下面看一块具体代码实例,这也是书中的例子

    假如我们目的就是开发一个程序打印"Hello Cucumber!

    那我们先写特性和场景描述和剧本

    1 Feature: greeter says hello
    2     In order to start learning RSpec and Cucumber
    3     As a reader of The RSpec Book
    4     I want a greeter to say Hello
    5     Scenario: greeter says hello
    6        Given a greeter
    7        When I send it the greet message
    8        Then I should see "Hello Cucumber!"

    根据上面代码,来写实现

      

     1 class CucumberGreeter
     2     def greet
     3         "Hello Cucumber!"
     4      end
     5 end
     6 
     7 Given /^a greeter$/ do
     8       @greeter = CucumberGreeter.new
     9 end
    10 When /^I send it the greet message$/ do
    11       @message = @greeter.greet
    12 end
    13 Then /^I should see "([^"]*)"$/ do |greeting| #这里的greeting就是上面剧本中   Then I should see "Hello Cucumber!" 中的"Hello Cucumber"

    14 @message.should == greeting #这是旧版本rspec使用should,新版已经不推荐了

    15 end

    下面是rspec测试代码

     1 class RSpecGreeter
     2     def greet
     3       "Hello RSpec!"
     4     end
     5 end
     6 describe "RSpec Greeter" do
     7     it "should say 'Hello RSpec!' when it receives the greet() message" do
     8         greeter = RSpecGreeter.new
     9         greeting = greeter.greet
    10         greeting.should == "Hello RSpec!"
    11     end
    12 end

    以上事例可能不是很详细,如果具体了解可以看《The Rspec book》这本书

       

  • 相关阅读:
    Java 中常用缓存Cache机制的实现
    Spring普通类获取bean
    系统升级shell
    shell 操作文本内容(修改增加)
    接口实践;接口与抽象类
    Java中@Override的作用
    类实现多个接口的例子
    java 反射实践
    对象主要属性及识别
    java抽象类实践
  • 原文地址:https://www.cnblogs.com/or2-/p/5186377.html
Copyright © 2011-2022 走看看