l

2021年12月31日 星期五

2021年終心得:Coding & Learning

Dec. 31 20:34~22:08



上次寫年終心得是〈2019年終心得:突破〉,這兩年疫情爆發,也發生了不少事,加上晚上有空,寫個2021年回顧好了。
今年的心得可以用Coding & Learning兩個字來概括。

2021年泰迪軟體的重大事件有:

***

業績

今年泰迪軟體的營業額是成立以來最高的一年,比2019年的高點還要多一點點。雖然因為疫情緣故很多傳統的課程像是Scrum、Design Patterns公開班今年都只開了一次,重構與測試的公開班課程則是完全停開,但受惠於【領域驅動設計與簡潔架構入門實作班】頗受鄉民歡迎,開了好幾梯次的公開班與企業內訓,反倒是增加不少收入。

但【領域驅動設計與簡潔架構入門實作班】之所以受歡迎,源自Teddy在2019年說過的一段話:「研究許久的Clean Architecture(簡潔架構)Domain-Driven Design(領域驅動設計),今年結合了這兩者,發現無論是在架構上、problem modeling以及coding,軟體開發與維護變得比較容易也更系統化。」

加上從2020年6月底開始,Teddy與北科大軟體系統實驗室的ezKanban團隊開始mobbing,至今花了超過1500小時的時間一起開發ezKanban。在這個過程中大量套用DDD、Event Storming、Clean Architecture、Event Sourcing、CQRS、TDD、Design by Contract(DBC)、Exception Handling、Specification by Example(SBE)、Living Documentation、Continuous Integration、Refactoring等方法,幾乎快把Teddy畢生所學都用在上面。

Teddy很喜歡Kent Beck說過的一句話:「If you stop coding, you stop learning」身為一位軟體開發從業人員,不管到了什麼階段,還是應該持續保持寫程式的習慣。寫程式的目的不一定是要拚production code的數量,而是要從中學習。這種學習的深度,會與所寫的程式數量成正比。寫得越多,領得越多。啊,不對,是寫得越多,學得越多。

今年七月ezKanban幾位研二學生畢業之後團隊只剩下3位學生,後來OIS團隊加入,增加了一搏、二碩、三大,一共六個人。感謝這幾位學生今年和Teddy一起mobbing,度過許多美好的coding時光。

***

畢業

2019年Teddy提到Erica已經能夠獨立作業,在敏捷教練、引導、敏捷需求管理方面也有不錯的成績。今年9月底Erica從泰迪軟體畢業,回到她的家鄉生活與工作。

泰迪軟體一開始就只有「Teddy」一個人,Erica加入之後,幫了很多忙,很多事情是Teddy能力範圍以外,剛好是Erica比較擅長,兩人互補。Erica剛到泰迪軟體的時候,Teddy告訴她:「我沒有把你當成員工,而是把你當成博士生來看待。我對你的責任就是希望能夠讓你有一技之長,別人不是因為你是泰迪軟體的Erica而付你錢,而是因為你是Erica而付你錢。這一天到來,就等於你博士班畢業。」

其實Erica的「點數」在2019年已經集滿,達到畢業的標準,算是在泰迪軟體多幫忙2年。當年Teddy博士班唸了N年,雖然捨不得但終究還是要離開實驗室。「畢業」,是另一個成長的開始,不是結束。


泰迪軟體又回到只有Teddy的公司,反映公司的名稱,可能是當初取名子就已經決定好的宿命XD。

***

感恩


▲難得三喵同床

 

明年Teddy預計將ezKanban部署成微服務架構,在微服務架構上再多花點時間深入研究,同時準備這方面的新課程。另外,最近Teddy找到一個在DDD中簡單落實Living Documentation的方法,明年也會花點時間在這上面。

最後感謝2021年直接或間接金援泰迪軟體的所有鄉民與親朋好友。沒有金錢的幫助,泰迪軟體無法經營下去,當然也就沒有現在的Teddy。

對於一個不拉幫結派、不搞花俏行銷、不造神,相信把自己的專長持續做到最好就有一線生機的笨蛋,還可以在這片土地上生存下去,而且活得快樂、活的有尊嚴。除了感恩,還是感恩。

***

友藏內心獨白:想不到更好的,重複使用了2015、2019年的結語。

2021年12月23日 星期四

無痛將驗收測試文件寫在測試案例中

Dec. 23 20:18~21:45

▲新買的電腦還沒寫code先來寫部落格

 

前情提要

2017年Teddy寫過一系列關於行為驅動開發(Behavior-Driven Development,BDD)的文章,請參考以下列表:

  1. BDD(1):詳盡的文件就是可用的軟體
  2. BDD(2):大家來吃小黃瓜之Cucumber運作原理
  3. BDD(3):在Eclipse執行Cucumber-JVM
  4. BDD(4):第一個Cucumber-JVM範例,上集
  5. BDD(5):第一個Cucumber-JVM範例,下集
  6. 在IntelliJ IDEA使用Cucumber(上)
  7. 在IntelliJ IDEA使用Cucumber(下)
  8. BDD(6):讓Step找到Step Definition
  9. BDD(7):使用Transform讓稅金同時支援5%和0.05表達方式
  10. BDD(8):實作第一個開發票Scenario
  11. 在IntelliJ IDEA使用Cucumber(上)
  12. 在IntelliJ IDEA使用Cucumber(下)

 

當時學了一陣子Cucumber但後來一直沒有真正使用它。主要原因在於Teddy覺得「Cucumber將需求寫在feature file裡面,然後再轉成step definition程式碼,然後開發人員在這些step definition立面撰寫真正的測試邏輯」的這種流程不太流暢。完整開發一個功能,從寫feature file到寫完produciton code的過程會一直撞牆(卡住),尤其是feature file有參數要傳給step definition,真的不太直覺。

但當時Teddy也沒多想,就把這個問題放著。

***

活文件

前幾天讀了《Living Documentation: Continuous Knowledge Sharing by Design》,書中有一個例子如下圖所示:


▲圖1:Living Documentation書中範例

 

看到這個例子Teddy突然心中有感:「對了,就是這樣。應該要把Cucumber的feature file內容寫在程式碼中而不是與程式碼分離。」於是Teddy也試著修改ezKanban的測試案例看看效果如何,請參考下圖:


▲圖2:修改後的ezKanban驗收測試案例

 

Teddy覺得直接在測試案例程式碼加上Given-When-Than說明文字讓測試案例清楚很多,也免去了原本Cucumber在feature file與step definition之間做binding的麻煩。

至於圖2中Scenario(), When(), WhenFailure()是怎麼來的?其實很簡單,原本Teddy以為書中用了什麼工具,但找了一下沒找到。後來想到,自己寫一個不就好了。程式很簡單,長成下面這樣:


▲圖3:用來在測試案例中撰寫Given-When-Than說明文字的工具,算是一的超級簡單的DSL(domain specific language) 

 

這種做法,與程式語言和工具都無關。絕大部分的高階語言要寫出圖3中的程式應該是幾分鐘就搞定的事。

 

***

 

友藏內心獨白:本篇在新買的第12代i9電腦上撰寫XD。