行為驅動開發學習心得(一)

c3tc3tc3t發表於2016-02-11

最近在看《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》這本書

 

 

 

 

　　 

相關文章