關於 #經驗 的內容

過去我在寫測試的時候經常會有「這裡該測試嗎？」的疑問，然而這個問題其實可以從另一個角度思考，那就是「這些測試組以完善規則嗎？」去想，以我們第一個 E2E Testing 的測試作為例子，雖然可以通過測試，然而實作的內容只是一些假資料，我們需要用另一條測試從其他角度去驗證，讓實作最終變成我們預期的樣子。

通過規格的分析我們準備好了 E2E Testing 的文件，以及對應的步驟實現，然而在這個狀態下是無法順利通過測試的，因此我們需要進行一些實作。在只有一條測試的狀況下，我們可以用非常簡單的方法通過這個測試。

當我們有了關鍵案例（Key Examples）後，規格已經相對的明確，如果還能夠被自動化測試的話，是不是一件更好的事情呢？我們可以利用 Cucumber 來實踐 E2E Testing（端對端測試）讓我們模擬使用者實際操作來驗證規格的完善。

最近工作上以及私下跟朋友討論時，剛好都遇到了 Null（不存在）類型的處理，通常我不會特別去在意這件事情，然而近年讀了一些關於 Null 的文章後（如：The worst mistake of computer science）對於這件事情的看法有不少改觀。

我們在工作的過程中大多是以需求（Requirement）當基準來進行開發的，然而要盡可能的接近規格（Specification）就需要多花一些力氣。大多數人其實下意識的都有實行這個動作，因為透過大量的溝通還是可以取得足夠的資訊，然而這樣做的效率跟成功率不一定足夠。

我們想要去「實踐」一個想法，大多數情況都是「做看看」來驗證是否可以成功，然而在這個過程中，我們需要有多少次的失敗呢？同時，為什麼有些人總是很容易的就成功，而自己卻總是沒辦法順利前進呢？

2021 年底，我開始思考什麼是「開心地寫程式」這件事情，如果單純是興趣也不跟其他人合作，那麼是很容易的。然而，如果想要將寫程式作為工作，就一定會面臨到跟其他人協力的問題，很多時候會是我們抱怨「寫這段程式的人在想什麼」的原因。

也就是說，如果能讓眾多的初階開發者（Junior Developer）寫出更好的程式，那麼對所有人來說都能夠更加專注在享受寫程式的過程。

最近在工作中對專案套用 google/wire 來處理依賴注入（DI，Dependency Injection）時，發現有非常多小細節需要注意。大多數語言其實都會碰到這類問題，然而 wire 的設計沒有採用大多數框架會提供的控制反轉（IoC，Inverse of Control）機制來處理，反而讓很多過去沒有考慮的狀況浮現出來。

過去一年花了不少心力在學習調整心理狀態，也慢慢的能夠理解「活在當下」的概念想要傳達什麼，同樣的概念也讓我想到了學習敏捷開發中的一些技巧，意外的能讓在寫程式的過程中更順利。

這幾年因為疫情的關係，大家都有不少生活上的改變，也因此我有四年沒有辦法親自到日本參加 RubyKaigi 這個對 Ruby 工程師來說最盛大的研討會。

終於在今年，我到日本重新感受了一次 Ruby 社群的活力。