通用化功能 - 重新思考 Rails 架構
在專案初期客戶有提到,第一階段要處理的客戶是最複雜的,只要能夠解決這個客戶的需求,未來就能夠讓客戶服務的其他客戶都能夠使用這套系統。
在專案初期客戶有提到,第一階段要處理的客戶是最複雜的,只要能夠解決這個客戶的需求,未來就能夠讓客戶服務的其他客戶都能夠使用這套系統。
報表功能也是非常常見的情境,大多數時候我們都會直接使用 Rails 的資料庫內容,搭配 JOIN 類型的查詢進行處理,然而這並不總是個好辦法。
在整個系統的開發過程中,因為客戶的服務是世界性的,因此還需要考慮到時區問題。然而只是單純的時區換算並不會造成問題過於複雜,而是在時區的呈現上並不像我們平常理解的那樣。
現代大部分的軟體都會考慮到使用者體驗(User Experience)因此都會盡量設計成簡單易懂的操作,然而仍有一些例外的狀況,像是有高度專業需求的系統,或者一些傳統產業長久以來的習慣,當時客戶就屬於這一類型。
當時收到新客戶的需求時,表示是一套很老舊的系統無法維護,急需開發一套新系統來維持業務的運作。客戶自己的工程師已經忙不過來,因此找到我當時任職的公司協助開發這套新系統,並且表示他們已經分析完畢,只需要依照 ERD(Entity-Relationship Diagram)實作即可。
約 2010 年左右,我開始接觸到許多程式語言的社群、研討會,因此大量吸收許多軟體開發的知識。當時,在業界中一個很常被提到的職稱「架構師」對當時還是學生的自己似乎有點遙遠。而我直到十多年後,才意識到「架構」的意義。
經過一系列的實作,Cucumber 的特色讓我們很容易的在不同語言、環境中轉換,同時又能夠扮演文件的角色,更難得的是他可以在不同語言中使用,這讓我們在未來對應不同需求時能有更大的彈性。
經過調整成 ViteRuby 的專案結構後,我們已經讓 Vite 所撰寫的前端恢復基本的功能。然而我們使用 Grape 所撰寫的後端行為還無法正常運作,因此接下來我們要用類似的方法將後端重新實現,並且通過所有的 Cucumber 測試。
我們在前面的練習中大部分的實作都是可以直接沿用,唯一需要重新處理的是 Cucumber 的步驟定義,他會受到使用的語言、框架需要重新撰寫,接下來我們會先將前端的實作搬移到 Rails 中讓專案能夠運作起來。
在前面的實作中我們將前端跟後端分別獨立進行開發,這是很常見的一種方式。然而在 Rails 7 的生態系裡面,透過 jsbundling-rails 可以很輕鬆的整合在一起,接下來我們會使用類似基礎的 ViteRuby 把前端的 Cucumber 測試搬移到 Rails 上重現一次性整合完畢的實作。