首頁內容關於
Top 5
軟體系統的混亂常源於需求的演進，而非刻意為之。本文分享如何透過重構，將一個龐大混亂的程式碼包，依循 Clean Architecture 與 DDD 的原則，拆解成多個語意清晰、相互獨立的子領域，並探討拆分過程中遇到的挑戰與解決方案，如引入反腐層、處理資料結構複用等議題，強調測試在重構中的重要性。
本文探討如何在 Javalin 環境下，透過 Interface-based Typed Configuration 實現集中管理、型別安全、慣例優先、容易實作與隔離來源的配置管理方案，並與 Spring framework 的配置方式進行比較，強調此方案的輕量、實用與可擴展性。
開發系統過程中常遇到 race condition 問題，文章探討了樂觀鎖、Serializable Isolation Level 交易的限制，並提出 PostgreSQL Advisory Lock 作為一種方便且無需額外部署基礎設施的分散式鎖解決方案，以確保批次寫入與背景運算能按順序執行。
本文探討在軟體開發過程中，將原本並非 Aggregate 的設計，逐步重構成具有 Aggregate 精神的實作。作者分享了一個實際案例，說明如何在一致性問題和更複雜的協同作業需求出現時，透過引入樂觀鎖，並逐步思考 Aggregate 的設計原則，最終找到一個在滿足系統需求下的特殊解決方案。
作者分享了 B2B 產品在迭代開發過程中所遇到的挑戰，特別是在追求功能完整性的過程中，如何避免設計變得過於複雜，進而影響使用者體驗。文中探討了從使用者回饋、市場變化到團隊內部認知的變化，並提出了在產品開發中「踩煞車」的重要性，以確保產品能真正符合使用者需求，而非徒增複雜度。
分享在不同公司期間，與客戶進行實地拜訪的豐富經，這些故事不僅是單純的客戶訪談紀錄，更揭示了產品開發過程中可能遇到的挑戰、客戶的真實痛點，以及從數據以外的角度全面理解市場需求的洞見。文章強調了工程師實地訪談的重要性，並鼓勵讀者若有機會應多加嘗試，從中獲取寶貴的經驗與啟發。
本文探討了在團隊成長過程中，如何建立關注數據的文化，並從開發數據、工程營運數據、產品營運數據及使用者體驗數據四個面向，說明數據在產品決策、優化與進步中的重要性。讓團隊相信數據的價值是建立數據文化的關鍵，並鼓勵工程師不僅關注程式碼，更要關心產品的整體成效。
本文探討透過 EventCenter 抽象層，將核心邏輯與訊息佇列技術框架解耦，提升系統的彈性和可維護性。藉由建立一個僅包含三個函式的輕量級 EventCenter 介面，並提供 GCPEventCenter 作為具體實作，說明這種設計如何在不修改核心邏輯的情況下，輕鬆更換底層的訊息傳遞實現。
這篇文章探討了「軟刪除」的實現方式、優缺點，並解釋軟刪除如何解決開發與營運系統中常見的資料刪除難題，分享在實作時，讀取邏輯的修改、關聯資料的處理，以及「同生共死」原則在設計決策中的重要性。此外，軟刪除為「超級使用者」提供的「開天眼」能力。以增加系統複雜度換取資料處理的彈性。
在決定離開 Spring Boot 後，處理資料庫交易管理成了一個挑戰。本文探討如何在不依賴 Spring framework 的情況下，結合 HikariCP、Sql2o、Service Locator 和 ThreadLocal 來實現交易管理，並提供一個基於函式風格的聲明式範例。
軟體系統的混亂常源於需求的演進，而非刻意為之。本文分享如何透過重構，將一個龐大混亂的程式碼包，依循 Clean Architecture 與 DDD 的原則，拆解成多個語意清晰、相互獨立的子領域，並探討拆分過程中遇到的挑戰與解決方案，如引入反腐層、處理資料結構複用等議題，強調測試在重構中的重要性。
本文探討如何在 Javalin 環境下，透過 Interface-based Typed Configuration 實現集中管理、型別安全、慣例優先、容易實作與隔離來源的配置管理方案，並與 Spring framework 的配置方式進行比較，強調此方案的輕量、實用與可擴展性。
開發系統過程中常遇到 race condition 問題，文章探討了樂觀鎖、Serializable Isolation Level 交易的限制，並提出 PostgreSQL Advisory Lock 作為一種方便且無需額外部署基礎設施的分散式鎖解決方案，以確保批次寫入與背景運算能按順序執行。
本文探討在軟體開發過程中，將原本並非 Aggregate 的設計，逐步重構成具有 Aggregate 精神的實作。作者分享了一個實際案例，說明如何在一致性問題和更複雜的協同作業需求出現時，透過引入樂觀鎖，並逐步思考 Aggregate 的設計原則，最終找到一個在滿足系統需求下的特殊解決方案。
作者分享了 B2B 產品在迭代開發過程中所遇到的挑戰，特別是在追求功能完整性的過程中，如何避免設計變得過於複雜，進而影響使用者體驗。文中探討了從使用者回饋、市場變化到團隊內部認知的變化，並提出了在產品開發中「踩煞車」的重要性，以確保產品能真正符合使用者需求，而非徒增複雜度。
分享在不同公司期間，與客戶進行實地拜訪的豐富經，這些故事不僅是單純的客戶訪談紀錄，更揭示了產品開發過程中可能遇到的挑戰、客戶的真實痛點，以及從數據以外的角度全面理解市場需求的洞見。文章強調了工程師實地訪談的重要性，並鼓勵讀者若有機會應多加嘗試，從中獲取寶貴的經驗與啟發。
本文探討了在團隊成長過程中，如何建立關注數據的文化，並從開發數據、工程營運數據、產品營運數據及使用者體驗數據四個面向，說明數據在產品決策、優化與進步中的重要性。讓團隊相信數據的價值是建立數據文化的關鍵，並鼓勵工程師不僅關注程式碼，更要關心產品的整體成效。
本文探討透過 EventCenter 抽象層，將核心邏輯與訊息佇列技術框架解耦，提升系統的彈性和可維護性。藉由建立一個僅包含三個函式的輕量級 EventCenter 介面，並提供 GCPEventCenter 作為具體實作，說明這種設計如何在不修改核心邏輯的情況下，輕鬆更換底層的訊息傳遞實現。
這篇文章探討了「軟刪除」的實現方式、優缺點，並解釋軟刪除如何解決開發與營運系統中常見的資料刪除難題，分享在實作時，讀取邏輯的修改、關聯資料的處理，以及「同生共死」原則在設計決策中的重要性。此外，軟刪除為「超級使用者」提供的「開天眼」能力。以增加系統複雜度換取資料處理的彈性。
在決定離開 Spring Boot 後，處理資料庫交易管理成了一個挑戰。本文探討如何在不依賴 Spring framework 的情況下，結合 HikariCP、Sql2o、Service Locator 和 ThreadLocal 來實現交易管理，並提供一個基於函式風格的聲明式範例。
本書大多數的內容都以 OO 的概念出發，詳列了許多設計的臭味道，也有大量的例子。個人雖然不會這樣寫程式，但仍是覺得受益良多，至少在 code review 時能更清楚知道該怎麼描述問題。不過，即便不是用 OO 的概念，有些章節還是可以帶來一些想法，用 OO 概念寫程式的人更不該錯過這本好書。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
本書介紹了戰略設計、管理領域複雜度、實際應用領域驅動設計等主題。透過對核心子領域、支持子領域、限界上下文等概念的探討，提供了領域驅動設計的相關知識。這篇文章中還涉及了微服務、事件驅動架構和資料網格等相關主題，提供了設計系統和應用領域驅動設計的指導。
這本書如果是剛看完《Clean Architecture》這本書，想要直接看答案怎麼實作，是可以當作一個起始點，但我會比較建議，自己循著書中前幾個章節提到的 principles，思考看看怎麼設計出一個符合大多數 principles 的方案，這會比較有趣。
本文介紹了建立高效的工作團隊所需的要素，從激勵和溝通到目標設定和團隊文化。團隊中最有影響力的人通常是真誠且善於聆聽的人，而不一定是經理或領導者。透過激勵、測試、測試再測試和克服人為障礙的過程，可以建立一支高效的團隊文化，這對團隊的成功至關重要。
內容十分精實，一百多頁很薄的一本書，但含了很多有用的資訊，就算不是開發微服務，書中的內容也可以用在很多雲端服務的開發與維運上。中文版唯一可惜的地方，翻譯非常不通順，很多不像中文的句子，會看到好幾個「與」連在一起用，標點符號的用法也有點怪，閱讀的痛苦指數有點高...
今天的任務是找到獨一無案的方法創造新事物，不只讓未來變得不一樣，而且要更好，所以我們要從 0 到 1。最重要的第一步是自己獨立思考。唯有重新看待世界，像古人首次見到它那樣覺得新鮮古怪，我們才能重新創造，並將更好的未來留給後世。
這陣子比較有空可以去天瓏書局晃晃，正好看到這本剛上市不久的書，整體上大多數守則，也是我自己一直在遵循的，是相當不錯的一本總結書。但真的要仔細看每一節的內容，理解每個原則背後的情境與想要改善的問題是什麼。如果只是把每一節的標題拿來使用，很容易就會發現衝突的部分。
這本書從 docker 的角度出發，介紹很多可重複使用的 pattern，除了翻譯某些地方有點怪之外，算是很有趣的一本書，後面很多的 pattern 可以想成是 sidecar 的進階使用方式，在不改變應用程式的情況下，增加不同的功能，相當實用。
這本與《人月神話》都是軟體工程領域知名的書籍，曾從學校圖書館借來看過，但說真的，還沒進入業界，其實很難體會風險是什麼？但... 在業界打滾幾年後，再次回來看這本書時，你會發現風險... 不好說 XD
這本書不厚，就像開場說的，為進入職場前沒什麼感覺，現在卻是收穫滿滿，推薦給軟體開發相關從業人員。
本書大多數的內容都以 OO 的概念出發，詳列了許多設計的臭味道，也有大量的例子。個人雖然不會這樣寫程式，但仍是覺得受益良多，至少在 code review 時能更清楚知道該怎麼描述問題。不過，即便不是用 OO 的概念，有些章節還是可以帶來一些想法，用 OO 概念寫程式的人更不該錯過這本好書。
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
本書介紹了戰略設計、管理領域複雜度、實際應用領域驅動設計等主題。透過對核心子領域、支持子領域、限界上下文等概念的探討，提供了領域驅動設計的相關知識。這篇文章中還涉及了微服務、事件驅動架構和資料網格等相關主題，提供了設計系統和應用領域驅動設計的指導。
這本書如果是剛看完《Clean Architecture》這本書，想要直接看答案怎麼實作，是可以當作一個起始點，但我會比較建議，自己循著書中前幾個章節提到的 principles，思考看看怎麼設計出一個符合大多數 principles 的方案，這會比較有趣。
本文介紹了建立高效的工作團隊所需的要素，從激勵和溝通到目標設定和團隊文化。團隊中最有影響力的人通常是真誠且善於聆聽的人，而不一定是經理或領導者。透過激勵、測試、測試再測試和克服人為障礙的過程，可以建立一支高效的團隊文化，這對團隊的成功至關重要。
內容十分精實，一百多頁很薄的一本書，但含了很多有用的資訊，就算不是開發微服務，書中的內容也可以用在很多雲端服務的開發與維運上。中文版唯一可惜的地方，翻譯非常不通順，很多不像中文的句子，會看到好幾個「與」連在一起用，標點符號的用法也有點怪，閱讀的痛苦指數有點高...
今天的任務是找到獨一無案的方法創造新事物，不只讓未來變得不一樣，而且要更好，所以我們要從 0 到 1。最重要的第一步是自己獨立思考。唯有重新看待世界，像古人首次見到它那樣覺得新鮮古怪，我們才能重新創造，並將更好的未來留給後世。
這陣子比較有空可以去天瓏書局晃晃，正好看到這本剛上市不久的書，整體上大多數守則，也是我自己一直在遵循的，是相當不錯的一本總結書。但真的要仔細看每一節的內容，理解每個原則背後的情境與想要改善的問題是什麼。如果只是把每一節的標題拿來使用，很容易就會發現衝突的部分。
這本書從 docker 的角度出發，介紹很多可重複使用的 pattern，除了翻譯某些地方有點怪之外，算是很有趣的一本書，後面很多的 pattern 可以想成是 sidecar 的進階使用方式，在不改變應用程式的情況下，增加不同的功能，相當實用。
這本與《人月神話》都是軟體工程領域知名的書籍，曾從學校圖書館借來看過，但說真的，還沒進入業界，其實很難體會風險是什麼？但... 在業界打滾幾年後，再次回來看這本書時，你會發現風險... 不好說 XD
這本書不厚，就像開場說的，為進入職場前沒什麼感覺，現在卻是收穫滿滿，推薦給軟體開發相關從業人員。
在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。
這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。
這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。
在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。
當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。
會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。
在上回提到一些應該要避免的措施，以及時時梳理 product backlog 讓團隊有較好的估算，這回則是作為一位 scrum master，我們該如何自省與發現估算的問題，也是以自我反省的方式完結這個系列。
在上回討論 Scrum 對於估算的精神與常見的估算單位，這回就來討論一些應該避免的事項，讓團隊能有更好的估算，下回則是過去的自省與感想。要讓團隊有較高品質的估算，agile coach 或 scrum master 可以觀察一些徵兆，若有發現盡早排除，免得讓團隊成員有壞習慣或是對估算這件事有陰影。
這同是 2016 年的舊文，根據現在的閱讀習慣重新整理，文章分成三回陸續發布，本回先談談在 Scrum 中，為什麼要估時，然後談談比較常見的單位與用法。下回則是幾個小方法，讓團隊能有更好的估算。最後一回，則是一些過去的自省與感想。
這是 2016 年的舊文重新整理，這幾年應該很少聽到軟體生命週期管理了，裡面的部分概念被其他更夯的詞取代了，像是 DevOps，所以我在一開頭便選了張比較接近潮流的圖片，不過說真的，在這個領域，常常有很多新名詞出現，但真正落實的又有多少呢？
在上回，探討 WIP Limit 的設置，但如果當被 WIP Limit 卡住時，直覺的想法是放寬 WIP Limit 而不是想著如何協助他人讓工作順利完成，那就失去使用看板方法的意義了，這回將探討如何讓團隊自覺與改善。
在上回，我們已經把工作視覺化成看板，但這只是第一步，要想用看板方法優化工作的流程，我們得設置 WIP 限制，讓團隊開始知道瓶頸在哪裡，然後才能開始改善，這一回就來看 WIP 限制的設置。
當初上完課，很激勵地寫下當時的心得，不太符合現在閱讀的習慣，所以重新整理成較適合閱讀的系列作，這篇將主要分享看板方法的精神與原理，後續會陸續更新，第二篇則是視覺化的作法，第三篇是 WIP Limit 的使用，最後是落實與其他感想。
會後，我與其中一位創辦人聊聊他們 scrum 怎麼跑，以及程式、美術與企劃，這三種技能差異甚大的成員怎麼合作，他也苦笑，其實他們也花了很多時間磨合，但我們都提到，要引導團隊需要的不是 process，而是很多的軟技能，讓團隊自己能夠成長。
今天完全沒有行程，就只有去機場搭飛機回台灣，飯店的自助式早餐依舊是很豐盛，甚至還有一區是可以自由組裝海鮮丼，我沒裝飯，只拿了幾樣海鮮。飛機是 11:05 起飛，所以，雖然離機場很近，提早兩小時到機場，意味著九點多該到機場了。
行程簡述
岡山國際飯店 -> 四國高松港 -> 小豆島土庄港 -> 土淵海峽 -> 小豆島國際飯店吃午餐 -> 橄欖公園 -> 寒霞溪 -> 二十四瞳映畫村 -> 便利商店 -> 天空海盧飯店 -> 天使之路 -> 天空海盧飯店晚餐 & 休息
今天行程有點特別，因為要離開四國到本州島去。行程簡述：金治國際飯店 -> 跨海大橋 (瀨戶內海) -> 倉敷美觀 -> 岡山後樂園 -> AEON Mall -> 7-11 便利店 -> 岡山國際飯店。
上次四國的團沒開成，這次旅行社是包機且保證成團，加上日本氣象廳的預測，應該有很高的機率能看到滿山遍野的櫻花，於是就報名了。
桃園機場 -> 長榮包機 -> 松山機場 -> 纜車上松山城 -> 天守閣 -> 購物中心午餐 & Shopping -> 今治毛巾美術館 -> 今治國際飯店 -> 居酒屋晚餐
由於班機時間的關係，加上網友都建議提早到機場，第五天沒有安排任何行程，就是去機場準備飛回台灣。
第五天的早餐依舊是在飯店吃，第一盤選了這幾天我覺得好吃的幾樣料理，京煮、地瓜天婦羅、雞肉天婦羅、英式煎蛋、溫泉蛋，以及偽裝成水煮蛋的豆腐，說真的，這幾天早餐吃的比平時還要豐盛許多。
最後收拾完，準備
由於昨天的行程真的有累到，所以昨晚討論了一下，決定把介於稻荷大社與清水寺中間的祉園、八版神社和園山公園等行程移掉，另外，稻荷大社也決定不爬到山頂，千鳥居稻中間就折返，讓今天的行程輕鬆一點。
第二天晚上回到飯店後看了一下 Facebook，很多人都建議提早 2.5 到 3 小時到關西機場，因為人實在太多了，本來第五天早上有安排去東寺，擔心去了會趕不上火車，於是調整了第三天的行程，把第五天要去的東寺改成第三天，這是自由行的好處，但功課還是要多做一些比較好。
早上依然是六點就起床梳洗，六
回顧 2013 年的行程，有幾個景點當初有安排，但因為某些點逛太久了，因此也就捨棄掉了，天龍寺便是上次經過但沒有進去的景點之一。所以便特地安排進去，不希望二次來京都時又錯過了。
前幾年遇到疫情，完全沒出去，距離上次出國整整有四年了，帶長輩出國，跟團老實說是最方便的，七月多本來是報名四國的團，但苦等不到成團通知，但畢竟假都請了，九月決定放棄跟團，規劃一下帶長輩去京都走走吧！
今天完全沒有行程，就只有去機場搭飛機回台灣，飯店的自助式早餐依舊是很豐盛，甚至還有一區是可以自由組裝海鮮丼，我沒裝飯，只拿了幾樣海鮮。飛機是 11:05 起飛，所以，雖然離機場很近，提早兩小時到機場，意味著九點多該到機場了。
行程簡述
岡山國際飯店 -> 四國高松港 -> 小豆島土庄港 -> 土淵海峽 -> 小豆島國際飯店吃午餐 -> 橄欖公園 -> 寒霞溪 -> 二十四瞳映畫村 -> 便利商店 -> 天空海盧飯店 -> 天使之路 -> 天空海盧飯店晚餐 & 休息
今天行程有點特別，因為要離開四國到本州島去。行程簡述：金治國際飯店 -> 跨海大橋 (瀨戶內海) -> 倉敷美觀 -> 岡山後樂園 -> AEON Mall -> 7-11 便利店 -> 岡山國際飯店。
上次四國的團沒開成，這次旅行社是包機且保證成團，加上日本氣象廳的預測，應該有很高的機率能看到滿山遍野的櫻花，於是就報名了。
桃園機場 -> 長榮包機 -> 松山機場 -> 纜車上松山城 -> 天守閣 -> 購物中心午餐 & Shopping -> 今治毛巾美術館 -> 今治國際飯店 -> 居酒屋晚餐
由於班機時間的關係，加上網友都建議提早到機場，第五天沒有安排任何行程，就是去機場準備飛回台灣。
第五天的早餐依舊是在飯店吃，第一盤選了這幾天我覺得好吃的幾樣料理，京煮、地瓜天婦羅、雞肉天婦羅、英式煎蛋、溫泉蛋，以及偽裝成水煮蛋的豆腐，說真的，這幾天早餐吃的比平時還要豐盛許多。
最後收拾完，準備
由於昨天的行程真的有累到，所以昨晚討論了一下，決定把介於稻荷大社與清水寺中間的祉園、八版神社和園山公園等行程移掉，另外，稻荷大社也決定不爬到山頂，千鳥居稻中間就折返，讓今天的行程輕鬆一點。
第二天晚上回到飯店後看了一下 Facebook，很多人都建議提早 2.5 到 3 小時到關西機場，因為人實在太多了，本來第五天早上有安排去東寺，擔心去了會趕不上火車，於是調整了第三天的行程，把第五天要去的東寺改成第三天，這是自由行的好處，但功課還是要多做一些比較好。
早上依然是六點就起床梳洗，六
回顧 2013 年的行程，有幾個景點當初有安排，但因為某些點逛太久了，因此也就捨棄掉了，天龍寺便是上次經過但沒有進去的景點之一。所以便特地安排進去，不希望二次來京都時又錯過了。
前幾年遇到疫情，完全沒出去，距離上次出國整整有四年了，帶長輩出國，跟團老實說是最方便的，七月多本來是報名四國的團，但苦等不到成團通知，但畢竟假都請了，九月決定放棄跟團，規劃一下帶長輩去京都走走吧！
