關於 #經驗 的內容

假設我們繼續確認訂閱的需求，發現現有的功能無法記錄使用者在何時進行延展，因此希望加入「在 2023-03-14 延展」的資訊在畫面上，然而我們現在是使用整數儲存在 Subscription 的 #items 屬性中，除了無法明確表達意義外，也不容易再繼續擴充。

到目前為止，我們已經透過驗收測試保護了我們想實作的功能，然而有一些實作如果不儘快重構，很快就會變成難以維護的技術債，因此在提交部分程式碼後，我們需要盡快的對這些地方做處理。

大多數的訂閱功能都會希望有紀錄的機制，假設我們也收到了同樣的需求。那麼，我們現在除了訂閱之外，還需要加入「訂閱紀錄」的設計，讓我們的使用者可以知道訂閱了多少次，或者可以手動延展訂閱。

近期因為 DHH 提到要把 Turbo 的 TypeScript 移除（Turbo 8 is dropping TypeScript）引起不少討論，當天就有人發了合併請求將 TypeScript 全部都拔掉，卻引起不少反彈，後續也有許多不理智的行為，讓 DHH 又發了一篇 Open source hooliganism and the TypeScript meltdown 講這個現象。

在自己約 20 年的程式經驗中，大多是使用動態型別的語言，覺得很適合跟大家聊一聊。

我們對在不明原因重複訂閱的情況加入了 DuplicatedSubscription 的例外，然而這種情況是無法在驗收測試的狀況下被重現出來，因為使用者無法在正常狀況做到這件事情，在這種狀況下單元測試就非常適合。

有一些情況，並不會在規格上被描述出來，我們該去測試嗎？舉例來說，目前的實作在建立訂閱的時候，並不會檢查「重複訂閱」的狀況，雖然在介面上使用者是無法進行這樣的操作，我們應該去測試這樣的情況嗎？

最近因為公司有提供 GitHub Copilot 給我們當作工具，我也就順勢將 Copilot 在 Vim 中啟用。這幾個月體驗上跟當初釋出試用版相比，反應速度雖然有提升然而仍然沒有比自己思考的速度還快，但也有改變了開發習慣。

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

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

十年前 WebConf 在台下聽演講，十年後自己也成為講者的一員。經過思考，我決定用之前在商業思維學院中的讓知識有光課程中，我沒有選擇的「（工程師）自我學習」這個題目作為這次 WebConf 的心得。