關於 #Rails 開發實踐 的內容

因為我們還沒有完善所有的邏輯，因此儲存到資料庫將狀態持久化的機制可以先不處理，接下來我們需要建構不同的「測試資料」讓訂閱狀態有不同的呈現，而不是像現在這樣只有寫死的訊息。

你有想過資料（Data）和資訊（Information）的差異嗎？在軟體開發的過程中，我們做的通常被叫做「資訊系統」然而大多數情況，我們很可能只是單純的把資料放到一個程序裡面，然後對這些資料做了一些調整，中間並沒有「資訊」的概念在裡面。

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

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

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

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

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

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

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