2015-06-19

[Product Feature Enhancement Competition] 各位夥伴 我們奪下第一囉


公司在6/30將要舉行Engineer Day的活動 其中一項比賽 Product Feature Enhancement Competition則是提前在6/16舉行
我們是在前一個星期蒐集大家的Idea
一起Brain Storming Feature Enhancement的可行性
這邊要感謝HIE他們一口氣就貢獻了絕大部分的想法
才能讓我們有個討論的基底

[積極爭取]
在會議中要決定上台演講的人
講完一片沉默..............
於是我就又在腦中跑過了20秒鐘的勇氣
自願接下這個工作
這邊要感謝大家的承讓

其實這機會真的很難得
勇敢爭取 機會就是你的

[少即是多]
演講的時間是6分鐘 準備時間不到1個星期
確定接下演講的工作之後
我就以我自己的想法從10幾個idea裡面挑出4個當作草稿
當晚只是光把這4個想法描述一次就花了8分鐘
所以隔天的草稿練習就刪了其中一項idea

兩天後第一次彩排
這邊要感謝小白跟小亨利一直幫我找人來聽我的練習
這次彩排找了第一次來聽我們idea的同事
果然發現了一些盲點
我們雖然剩下3個idea
可是在6分鐘內仍是很難講清楚
導致講完了 觀眾也不清楚我們的主軸

所以根據討論結果 我們又刪掉一個idea
並且將焦點鎖定在
 1. 要描述問題
 2. 提供Solution
 3. 最後總結價值

比賽前一天 第二次彩排
到了第二次彩排 其實我講的內容大致上已經確定
也設計好要用一個故事貫穿全場
從故事中帶出問題,以及我們的Solution
這次彩排其實已經蠻完整的 但還少了點什麼
第一次聽的觀眾 在Q&A的時候也有搞混我們的訴求

就是少了圖 果然光用文字敘述還是不能深入印象

於是我們就分工合作 感謝Eason跟小白幫我生一些圖
其實這很困難的 因為我們在講的是一個Trend Micro尚未做出的產品
沒有對應的UI 其實是很難截圖的
最後我就把一些文字描述改成這些圖跟動畫

用兩個idea 幾張大圖 來表示我們的想法
結果論來說 少即是多的戰略是成功的

[從TED的啟示]

最近剛好才讀了一本書 : 破解!撼動全世界的TED秘技
於是我就想應用在這次的演講中
1. 練習練習再練習
2. 不要脫稿演出

於是我在賽前就練習了約40次 到最後果然那一張投影片到那一張 每張要講什麼都記得清清楚楚
因為時間只有6分鐘 所以我這次要求自己不要脫稿演出
以往我常常會脫稿 因為都不寫稿子 每次都照大綱發揮
這次是逼自己不能脫稿 就結果來看 果然是很順的把事前準備的東西講完

[比賽當天]
當天901滿滿的觀眾 加上評審都是公司的大頭們
其實越接近上台的時候 就越緊張

我是最後一組上台的 在台下其實就沒在準備了
一方面這樣也不緊張 一方面別組的演講也很精采
尤其我上一組的演講
講的真的很好 有深度有廣度
說什麼有塊很有門檻的藍海市場
是我們Trend Micro很有機會切入的一塊
超級打動人的

最後輪到我了 一開始真的還挺緊張的
因為第一次在大頭面前報告 面對滿場的觀眾(大都是很資深的)
但我準備的第一個笑點讓大家笑了之後
之後就講開了 一路順暢

結束之後的Q&A很熱絡
大頭們也還蠻欣賞我們其中一個Idea (幸好壓對了寶阿)

兩天後公布結果
結果我們跟上一組並列第一
恭喜大家 我們的辛苦沒有白費
接下來要在Engineer Day中跟台下1000名同事sharing我們的想法囉
看來賈格的故事要繼續走下去了XD

[心得感想]
這次的演講很有Startup公司在創投面前 爭取認同的感覺
我們提出了一個全新的Idea 希望公司會買單
在眾多Idea裡面要脫穎而出

少即是多

果然能把主軸描述清楚

各位 我們真的做到了
謝謝你們 謝謝各位的幫忙
這真的是一次很棒的成長~

2015-06-10

[CI] [Jenkins] Jenkins 初體驗

Jenkins初體驗

本周要demo用Jenkins建置第一個Build
試了一整天終於把內褲版成功了
筆記一下

Step1 安裝Jenkins
Windows上安裝蠻簡單的,直接install即可

Step2 安裝對應的Plugin
我目前裝了 P4 Plugin以及MSBuild Plugin


Step3 建置第一個Build
先用Local Build
P4的連結等下一次

Step4 Command
因為用MSBuild Build Fail
所以我只好先用script裡面寫的devenv


因為環境變數設了都抓不到 所以先用絕對路徑

[補充 : MSBuild的設定]
當裝完MSBuild Plugin時 要去Configure System設定MSBuild


設完之後就能在Job的設定中找到



Step5 Build Now
可以開Console Output看過程
最後可以到首頁看結果


追蹤Issue
Q1 : 相對變數怎麼使用
Q2 : 如何跟P4連結
Q3 : 設定通知
Q4 : 查查MSBuild為何會Build Fail?


2015-06-07

[心得文] 自動測試與TDD實務開發 Day2

Day2 的教學順序是先教我們怎麼使用SeleniumWeb-Testing;中間則是介紹了FluentAutomation以及Page Objects;最後則是帶到了Refactoring

而我的觀戰重點則是在於Refactoring。還記得以前我的Refactoring都是耗時費力,由上往下的設計模式。Refactor完也不敢保證有沒有side effectDay2則是學到了如何有效攻克Refactoring。確實相當實用阿~

Joey提供的Lab很寫實地反映了一個可以執行卻是寫得很爛的設計。你不能說他錯,前輩們的智慧讓這段code是可以執行的。但是它的確設計的很爛,邏輯全都包在一個btnXXX_Click Method中,很眼熟吧?是不是很多人都這樣設計呢?

還是要說,Joey這份Lab : lab6-RefactoringWebStie,著實設計的不錯,讓我們一步一步地Refactoring。這份Lab的題目是根據貨品的重量、長、寬、高以及不同的物流商,我們提供不同的運費。接下來就看看一步步該注意的原則吧。

1. 首先,必須要建立測試。

通常我們若沒有寫Unit Test的習慣,Refactoring就像之前我的耗力費時的作品一樣,是沒有效率的。我常常聽到別人不寫測試或是不敢Refactoring的理由是:
    (1) ~ 以前就沒寫UT了阿~ 現在想要也來不及加了~
    (2) ~ UT很好,但適合New Project,我們不適合。
    (3) ~ 我們都是Legacy code,沒辦法測的啦~
    (4) 這影響範圍太大,我怕有Side Effect。先不要動好了。

很高興在這堂課我看見了曙光。沒有Unit Test沒關係,我就建立一個外圍最大包的測試。這樣總行了吧?藉由一個外圍最大包的整合測試來保護,我們就能夠安心地Refactoring了,一旦Refactor失敗,測試就告訴你Fail。經由這快速的回饋,我們就能夠一步步把Refactoring做好。
於是乎,Joey就帶到了Web-Testing。如果我們的ProjectWeb類型的,就可以利用Selenium這套Tool來錄下WebUITesting Script並驗證一些行為。而Selenium更強大的是,它能夠將Testing Script轉變成NUnitTesting Code,並由Test Project去驅動這個測試。這樣就能在Test Case中自動化地驗證Web的行為。

如此,你最外頭已經有測試保護了,接下來就能放心地做Refactoring

補充:或許QA會覺得Selenium轉化成的Testing Code不夠直覺,所以可以參考能提高Testing Code可讀性與維護性的FluentAutomationPage Objects Pattern (Selenium官方推薦的方式)

2. 讓程式邏輯與網頁UI分離。
很多人習慣讓WebForm控制項的邏輯寫在cs中。
For example

這些code都跟UI耦合,從控制項中取得值,並運算一些邏輯之後再填回去控制項。

其實我們可以考慮從這裡將WebForm控制項抽離,用一個自行定義Object (方便抽換),來取代,這樣可以降低耦合
For example :


3. 重構-擷取方法 : 先將一大串code 擷取成Method

下一步則是將混在一起的邏輯運算擷取出來變成一個Method

4. 重構-職責分離(主動詞分離),將商業邏輯從網站抽到 library


原本計算運費的商業邏輯跟網頁混在一起,很難去各別測計算運費的,所以我們可以將商業邏輯抽到Library去,這樣就能測它了。這邊要注意的是,主動詞分離的原則。
For exampleUser選擇黑貓這個物流商,那麼根據商品屬性以及黑貓的運算邏輯,我們可以設計出Blackcat這個Class以及它有一個計算運費的MethodCalculateFee。而這個Method的內容就可以塞入Step3剛剛擷取的Method

到了這一步之後,我們就能確保網頁應該不包含任何計算運費的邏輯,因為我們已經將計算運費的職責委託給Blackcat這個Class來處理

5. Unit Test - Library建立Unit Test

Step4將邏輯切到Library之後,我們就能對它做Unit Test。看吧!到了這一步,是不是就能做測試了呢?

6. 持續Refactoring
有了最外圍的整合測試加上Library的單元測試,我們就能放心地持續一直Refactor下去,無論你是想要擷取成介面或是考慮將生成物件的職責獨立出來都能放心地做了。只要測試有通過就好。

以上幾點原則,就是攻克一大坨code的方法。
補充一個我很欣賞Joey的一個手法:Focus on the current content

TipsFocus on the current content
由小處著手,從這段code出發,不會跳來跳去。這實作其實蠻難描述的,但就是藉著IDE的協助,當需要某個PropertyMethod或是Class時先用手刻一個Name,再透過IDE自動產生對應的code。讓programmer不須跳來跳去地自己產生。如此專注的結果也反映了寫code的效率

Extract and Override
解legacy code的暫時解,非正統解
將切不掉的東西,放到private method,並更改為protected virtual
Test Code再繼承這個Class之後覆寫掉
我們可以先用這個解法先建立起測試,之後再用正統的方法Refactoring這段。

最後想說的是
原則是這樣沒錯,但還是需要練習練習再練習
練習是不會騙人的。
也不要再說範圍太大不可以測了,如何一步步把範圍縮小到可以測就是我們接下來的事了。

補充: Selenium其實是一種化學元素 - 硒
補充: 可用CodeMaid來分析Method的複雜度

系列文章
[心得文] 自動測試與TDD實務開發 Day1

2015-05-27

[瀑布底下玩SCRUM] 即將導入 Continuous Delivery 的心境

[不 要 覺 得 目 前 沒 有 用 就 不 學 了]

前一陣子想在公司開Unit Testing的Study Group
結果人數不夠開不成 我就趕緊找了另一個Group抱大腿
這個Group是在讀 Continuous Delivery
讀了幾個星期之後 發現可以導入部門改進目前遇到的一些問題

還真的機會來了 !!!

今天早上邀請了幾個相關的Developer跟QA
一起Brainstorming大家要怎麼去做Continuous Delivery

在諾大的白板上用mind map的方式圈起了一大塊一大塊的Feature
就覺得遙遙無期的藍圖已經轉變成可以執行的Product Backlog了
頓時心中燃起了希望之火

對了!!

在白板上用mind map做planning 也是向其他Team偷學來的
JIRA Sharing 筆記

SCRUM Planning Meeting 是參加社群學來的

總之
不要覺得目前沒有用就不去學它
因為你不知道那天真的會用到喔~



2015-05-22

[心得] Improvement Kata工作坊 - 讓員工自己變優秀的解藥(之一)

2015.05.21
Improvement Kata工作坊 - 讓員工自己變優秀的解藥(之一)

今天的主題是講Improvement Kata

主要的重點在於 : 

1. 了解現況
2. 確定目標
3. 持續改進

改進的重點在於套用kata的套路 
持續練習固定的節奏與步驟來達成目標






























隨後玩的Workshop 總共三組數學題要玩3 run
1. 第一線員工計算三份數學題 (可用計算機)
2. 三份算好之後再交由Team Lead加總 (心算)
3. 副總確認內容無誤簽名負責
4. 總經理簽名

我們這組第一次run的結果是花了約143秒
接下來大會訂下一個目標 : 下次執行正確率需達60% 速度需快30%


於是大家就開始Brainstorming要如何改進
我們這組想到了以下方法:
1. 第一線員工幫Team Lead一次算好好, Team Lead只要簽名
2. 只寫兩份考券就好 (因為大會要求60%正確率 完成兩張考券的正確率是66%)
3. continuous delivery, 原本第一線員工要完成三張考券才能上傳,現在完成一張就上傳

結果我們省下了86%的時間 還仍保有100%正確率
還不賴

不過整個過程的重點應該在於
員工們要先發覺現況是有問題的
再來一起Brainstorming solution
再經過每一次的實驗 逐步改進
跟SCRUM 是不是很類似呢?