搞笑談軟工

2017年3月15日星期三

使用Spock規範類別行為（上）：在IntelliJ IDEA使用Groovy

March 14 15:12~16:40

緣起

Spock是一種測試與定義程式規格的工具，經常使用在BDD/TDD中用來定義類別/方法層次的規格。在之前的BDD系列文章中Teddy直接使用JUnit來撰寫類別的規格，這兩集將簡單介紹如何用Spock達到相同目的。Spock是用Groovy所開發而Groovy是一種JVM語言，所以Spock可以在Java中直接使用。本集首先介紹如何設定IntelliJ IDEA開發環境以支援Groovy，下一集再介紹用Spock來規範Java Stack類別行為的例子，並且和Design By Contract方法作比較。

***

安裝Groovy

第一件事要先在作業系統中安裝Groovy，安裝方法很簡單，網路上Google一下就有了XD。這裡介紹在macOS安裝Groovy的步驟。

連到Install Groovy網頁就可以看到詳細的安裝方法，Teddy採用網頁上介紹的SDKMAN! (The Software Development Kit Manager)來安裝，有四個步驟，打開終端機之後執行：

curl -s get.sdkman.io | bash
接著再開啟一個新的終端機，輸入source "$HOME/.sdkman/bin/sdkman-init.sh"
然後輸入sdk install groovy
最後輸入groovy -version，如果看到以下畫面就代表成功了

▲安裝好2.4.9版的Groovy

***

新增HelloGroovy專案

▼在IntelliJ IDEA新增Groovy專案，此時Groovy library尚未設定。

▼按下【Create…】按鈕選擇Groovy安裝目錄。這時候傻眼了，SDKMAN把Groovy安裝在/Users/<username>/.sdkman目錄中，這是一個隱藏目錄，怎麼選啊？

▼按下【cmd】+【shift】+【.】，隱藏目錄就會出現。

▼點選/Users/<username>/.sdkman/candidates/groovy/current。

▼設定好Groovy library，按【Next】。

▼把專案名稱設為HelloGroovy，按【Finish】。

▼產生一個新的Groovy專案

***

印出Hello, Groovy!

▼新增一個Groovy Class

▼沒問題可以動，在console印出Hello, Groovy!

***

友藏內心獨白：歡迎來到JVM大家庭。

2017年3月14日星期二

BDD（17）Given-When-Then怎麼寫？

March 13 10:48~11:46

兩種寫法

在BBD中Given-When-Then格式被經常用來撰寫例子，撰寫的方式可分為兩大類：

Imperative：命令式，一步一步寫出使用者護系統互動的詳細步驟。
Declarative：宣告式、聲明式，著重在於使用者「做什麼」（What）而不是「怎麼做」（How）。

採用何種方式，對於可執行規格（executable specification）或驗收測試的可維護性有著很大的影響。在《Cucumber BDD How-to》書中有一個例子。

Imperative Step

Scenario: Write blog

Given I am on the blog homepage

When I click “New Post” link

And I fill “My first blog” as Title

And I fill “Test content” as content

And I click “Post” button

Then I should see the blog I just posted

相對於命令式的寫法，宣告式的寫法如下：

Declarative Step

Scenario: Write blog

Given I am on the blog homepage

When I write a new blog post

Then I should see the blog I just posted

***

有何差異？

採行BDD一般來說會推薦說使用宣告式的寫法，因為這種方法可以隱藏更多的實作細節，除了可讀性比較高以外，還可以更專注於描述系統行為而非系統如何實作。宣告式的作法會把實作細節放在測試自動化層，也就是Cucumber的step definition裡面。如此一來如果實作細節改變，例如網頁介面連結名稱改變，也不需要修改規格（不需要修改Cucumber的.feature檔案）。

命令式的方式也不是完全沒有好處，雖然採用命令式寫法很可能被使用者介面給綁架，但在某些情況之下命令式的寫法會比宣告式的寫法來的清楚。重點還是在於：

清楚表達系統行為而非系統實作
當實作方式改變時應該不需要修改系統規格，只需修改實作程式碼與測試自動化程式

***

小心怪味道

有一些鄉民在採行BDD的初期為了減少撰寫自動化驗收測試的時間，會等程式都寫好之後用「capture and replay」（擷取畫面，重複撥放）的工具來產生驗收測試案例。這種做法不能算是BDD，因為並沒有做到「測試先行」，也就是開發流程並沒有先撰寫一個失敗的驗收測試案例，而是反過來先寫production code，再用「capture and replay」的方式產生自動化驗收測試。

這種方式所產生的驗收測試，極度依賴於使用者介面，只要介面一修改，驗收測試往往也需要跟著修改，導致很高的維護成本，最終可能讓開發人員無以為繼，不想繼續維護大量與使用者介面緊密相關的驗收測試。

稍微好一點的，會先用Given-When-Then寫scenario，但很可惜寫出的例子也是從使用者介面思考，依然會造成不易維護的問題。這些都是在落實BDD的初期很容易發生的現象，也是要做好BDD需要突破的一個重要關卡。

***

友藏內心獨白：寫Use Case也不應該有太多介面細節。

2017年3月13日星期一

價值 VS 技術

March 12 21:10~22:28

敏捷方法是一種價值驅動（value driven）的開發方式，強調團隊注重交付給使用者的價值勝於計算完成功能的數量。唯有交付對使用者有價值的產品或服務，滿足使用者的需要、解決問題，使用者高興之後爽快且持續買單，與公司之間建立良性循環，公司才可長久經營。

價值驅動、價值驅動，口號人人會說，但請鄉民們想一下，（軟體）產品的「價值」來自於哪裡？

***

老闆觀點

大部分的老闆或高階主管，已經很少動手寫程式。他們把軟體開發視為一個「黑盒子」，主要只關注兩點：

輸入：接了多少案子
輸出：開發多少功能、賺了多少錢、增加多少客戶

至於產品是怎麼做出來的，只要東西可以動，錢收得到，其他都不是那麼重要。

曾經聽到不少老闆與主管跟Teddy抱怨：「開發人員過於注重技術，不管開發時程」。這種人雖然技術能力很好，但卻不一定是老闆心目中最佳戰將。

***

開發人員觀點

開發人員也想把產品做好，無奈軟體開發有太多「歷史共業」要處理。軟體雖然叫做「軟體」，但其實一點也不軟，而且還非常的硬，硬到開發人員改不動。有經驗的專業開發人員都知道，軟體要能要軟，一定要讓程式碼處於「乾淨」（Clean Code）的狀態。這絕對不是「只管技術不管時程」，而是為了走更長遠的路所以要打好基礎。

很多開發人員經常抱怨：「手邊的程式碼一團亂，公司也不給我們時間整理，每天看到這麼髒的程式碼真的很痛苦。不但開發快不起來，而且很容易出錯。」

***

有價值沒技術，有技術沒價值？

從「黑箱」的角度來看待軟體開開發，推到一個極致可能會變成「我只管交付給使用者的價值，技術不重要」。但這世界上有多少產品或服務是「不需要技術又可以帶給使用者很高的價值」？

反之，過於注重技術，只求用最新、最酷的技術來開發軟體，往往會因為低估新技術帶來的風險而導致時程延誤，影響價值交付的即時性。

N年前有個朋友想在一個產品開發中導入自動化驗收測試，但產品的開發時程很緊，不可能暫停開發只做自動化驗收測試。最後朋友想到用「預算制」的作法，開發團隊與Product Owner協調出每個sprint「編列若干小時的預算」來落實自動化驗收測試。這種作法關照到產品開發的需求，也漸進式的滿足開發人員對於「讓軟體變軟」的渴望。而這些自動化驗收測試，也在一年後某次軟體元件升級中「回報」開發團隊，快速找到好幾個bug，大大縮短了那次升級所花的時間並且也保證了釋出軟體的品質。

***

有一次一位畢業沒多久的學弟跟Teddy聊天，因為在學校學了一身「功夫」，上班之後想要好好施展，但公司主管卻不准他重構系統。他看到亂如義大利麵的程式碼卻又不能重構感到非常痛苦，於是心生離職的念頭。

Teddy：為什麼主管不讓你重構系統？

學弟：我也不知道啊，反正我提出來說程式很髒要安排時間好好重構一下，就被打槍了。

Teddy：如果只是小幅度重構，你在開發功能的時候直接重構不就好了，為什麼要主管安排額外時間？

學弟：當然不可能小幅度重構啊，整個系統運作了好幾年，一定要大大的重構才有可能改善。

Teddy：你才剛來公司沒多久就提出要「大大重構」，如果我是你主管我也會「大大害怕」啊。

學弟：總之我覺得這個公司不行，軟體開發方法過於落後，我已經決定要換工作了。

Teddy：下一間公司…不一定會更好。

***

軟體開發是一個經濟問題，要得到最佳的投資報酬率，要考慮的因素（force）很多。能力越強的人，越知道如何動態平衡這些因素。價值愈高的產品，通常需要越強的技術作為後盾。「技術」不光是寫程式的能力，軟體生命周期的每個環節都需要關照。

各行各業所需要的核心技術不同，找到自己行業的核心技術，不斷增強這個技術以支援價值交付，最後培養取捨的判斷力。剩下的事情，就只能交給老天爺了。