這篇是整個 Blog 的全站索引，如果您是第一次來這裡，可以先看看這篇索引，大概知道 Blog 的全貌：

• [理念] 思考本質、實踐、抽象、想像力、教育
• [目錄] 經營管理: 整理管理經驗談、管理哲學、經營、領導、用人之道、學習方法、專案管理
• [目錄] 軟體工程實踐: 包含軟體架構、開發、測試、維運等 … 實踐的心得。
• [目錄] 分散式系統，包含分散式系統理論、Cloud Native - Kubernetes、AWS。
• [參考] 參考書、資訊技術與工程專有名詞、計算機科學專有名詞、經營管理專有名詞
• [系列文] 公車隨筆、寫作與閱讀系列文、溝通、會議效率
• [關於] 學習法則、經營之道、一些領悟、分類哲學
• [站內記事]: 文章更新紀錄, 點閱率統計

不管是程式、文章、資料、還是房間，我都會定期重新整理 / 重構，核心概念來自於 分類的哲學

底下整理 Blog 更新的文章記錄，提供給想知道哪些文章有更動的朋友。

C4 model 是一個 2018 年之後發展出來的 架構描述方式，我在 2017 年底也在組織內部弄了類似概念的表達架構方式，很巧不巧，概念很 C4 model 很像，這段想法在我的著作 SRE實踐與開發平台指南 有提到，底下用 FB 寫的草稿，讓 ChatGPT 幫我整理的想法～

整理我個人這幾年來 (Since 2017) 接觸 API 有關的議題，共分成以下的大議題：

1. API 設計：重點在於滿足業務需求、控制範圍，包含資料模型、設計方法、流程與驗證
2. API 架構：API Gateway、快取、效能、通訊協議、監控 …
3. API 治理與管理：版本控管、導入策略 (API First / Spec First / Contract First)、上架政策、訂閱管理、問題排查
4. API 實作與模式：包含常見的機制，像是 async、pagination、tracing、idempotence、batch、bulk … 等
5. API 軟體工程：開發方法、測試方法、開發流程、跨團隊協作、文件

以及寫在 FB 的隨筆，包含 API 在當代軟體開發的重要性、設計方法論、實務經驗談，以及一些背後的思路。

整理一下我個人開發環境的資訊。

我在開發時，很習慣用 Linux 當作主要的運行環境，然後用 Windows or macOS 當作作業環境 (IDE)。主要的工作配置是：

1. VS Code runs on macOS
2. Application (java, golang, rust, C#) runs on Linux

主要是確保應用程式的 runtime 的 development and production 是一致的。

之前注意到 UTM 是因為想在 iPad Pro 上跑 Linux，但實驗後效果不如預期，所以放棄這個念頭。最近嘗試把執行環境在 Macbook Pro 上，用 UTM 跑 Ubuntu 24.04 Server，運行了差不多一個月左右，感覺還可以。過去我比較熟悉的 Virtualization 是 VMWare，連假期間順手 VMWare 兩者在 Intel 與 Apple Silicon M1 環境的效能差異。

這篇是 2022/09/12 寫下的隨筆，主要是整理軟體版本在軟體開發團隊內部、外部的意義。

版本的概念在我的職涯生涯裡，對個人來說幾乎是常識，而且大部分 Open Source Software (OSS) 也都是這樣，如下圖。但實際上在軟體開發團隊的經驗裡，很難直接套在團隊上，因為普遍的團隊，無論怎樣的角色，對於版本是沒有概念的。

特別感謝 DevOps 艦長 陳正瑋 幫忙整理文字的摘要，如下：

• 版本號是溝通的介面
• 為何需要版本號
• 何時決定版本號
• 為何需要版本號的管理原則
• release 的生命週期
• 程式需要向下相容嗎

其中，商業思維學院 院長 Gipi 也參與了討論，交換了不少想法，很有共鳴～

這篇是我在 2023/09/07 聊到關於 Code Generator (底下簡稱 codegen or CodeGen) 的經驗與想法。

整理自 FB 20200615 的隨筆，針對底下這段話的延續探討：

系統思維好系統有三個特徵：抗打擊、自組織、以及中央控制和子系統自治要有一個平衡關係 —— 這三個特徵明顯更符合生態系統的特徵。

這些三點，背後有各自的問題與實際案例。

整理一些設計 Identifier 要考慮的事情，特別是要揭露給使用者的時候，像是 RESTful API 的設計。原文來自 facebook 寫的草稿。

繼續整理資料備份原則，整理自 Facebook 寫的草稿。

上一篇 整理了 資料備份還原 的 第一原則：分層原則，設計出發點是 Durability。接下來第二原則則是資料的 重要性 與 存取頻率 矩陣，如下圖：

聊聊 NAS 的一些心得，整理 Facebook 寫的草稿。

討論 NAS 這種「解決方案」之前，應該先好好想清楚，資料對於自己而言，到底有多重要？

NAS 對我來說核心價值就是 備份資料 與 還原資料，所以對於「資料」的存放，過去從早期用光碟備份資料，到後來使用 NAS，這麼多年的經驗累積下來之後，我設計了一些原則，定義備份與還原資料的原則，如下圖，第一原則：資料分層原則 (如圖)

多租戶架構 (Mulit-Tenancy Architecture, 以下稱作 MTA) 是 SaaS (Software as a Service, 軟體及服務) 設計的核心議題，也是我過去幾年工作研究的題目之一，大部分的人針對這個題目討論的多是 K8s 的 Namespace 劃分、或者資料庫的拆分方式、使用 Single or Shared / Hybrid … 等策略。

多租戶架構背後需要討論的，除了這些技術架構的議題，更重要的是往前一步：

SaaS 的 多租戶 應該怎麼定義？以及能夠解決那些問題？

基於這些討論與實踐，最後我提出設計 MTA 的關鍵抽象概念，我把它稱為 Isolation Factor (隔離因子)。

這篇文章嘗試解釋與探討 多租戶 背景與核心議題，同時用真實世界的租賃關係，剖析設計 SaaS 時必須要知道的概念，嘗試帶出 Isolation Factor 的重要性。

相關文章：

• 摘要 Eclipse 設計的啟發：當代 SaaS 分散式架構的關鍵設計
• API 設計 - 摘要 API 通訊模式與協議
• 聊聊分散式架構的服務治理

去年 (2022) 受邀 AWS Career Exploration Day 分享職涯的想法，今年因為個人因素，無法到現場。但是在主辦單位熱情的邀約以及協助下，改用錄影的方式，延續去年分享的想法～

Updated: 20231122 媒體的報導: 迎向 AI 與雲端共融世代，如何校準自身技能成長策略？

這篇整理自今年二月跟朋友分享的內容，主要是關於溝通效率的目錄、總整理。

這篇整理自 2022/10/12 Software Engineering at Google 這本書的讀書會的 筆記與摘要。

這段 筆記 是 2020 年聽 podcast 寫下的心得筆記、跟朋友討論的東西。這整個過程，也是我過去 凝聚團隊共識、人才養成 的實踐方法。

如果你希望買一本書，照著裡面說的步驟走，事情就搞定了，那這本書一定不適合你。

如果你希望買一本書，可以隨意翻閱，然後有種「啊！就是這樣啦！」，那這本書應該適合你。

銷售通路：

• 天瓏書局
• 博客來書店

原文是我在 fb 寫下 草稿，主要針對靠北工程師 鄉民提的問題。幾乎一面倒的狀況之下，分享我自己的經驗與看法，提供不一樣的思路與前後文。

整理一段關於 SRE 問題的訪談紀錄，歡迎大家提供不一樣的經驗與想法。

API 存在的目的，最早期是程式邏輯可以重複使用，例如 時間相關的工具，透過標準的介面定義，以及模組化的概念，每個人在開發應用程式的時候，都可以引用同一個函示庫，透過標準介面就可以調用。像是 Java 語言的 java.util.Date 這樣的標準介面，所以 API 的概念就出現了。

API First 在跨企業的系統交互越來越頻繁的今天，提供有效的擴展業務的方法。過往什麼功能都要自行開發，但卻因為內部資源不足；亦或錯估新業務規模的深度與需求層次，造成投入沒有成效、或者必須不斷的加碼投入，最後才意會到，這是個獨立領域，需要獨立的專業團隊，像是 MarTech、支付、通訊 …

API First 的概念，背後是雙方在技術上彼此溝通的通訊協議，透過這層協議，雙方可以更快速的仰賴彼此的擅長的領域，進而拓展業務。最常見的就是電商與支付系統、廣告服務、電信系統、物流業、與 ChatBot / AI … 等整合。

開放 API 是個策略性決策，背後代表著要與合作夥伴達成策略聯盟，本質上是 B2B 的商業行為；同時開放 API 也意味著內部系統需要有高度整合，提供對外統一介面與標準，讓合作夥伴在開發過程，可以有一致性的使用介面與理解。

基於這樣的前提，只要是 API 對外開放、或者是內部整合，都要面對本文要提到的問題：API 通訊模式與協議

原文是 2021/06/14 寫下的 memo，摘錄一場失敗的會議有哪些現象，與另一篇 一場有效的會議 成對比。

2022 年初的時候，經過朋友的介紹認識成大資工系 李信杰 教授，因此才有了這本書的誕生。

李老師對軟體工程非常有熱情，特別是軟體測試領域，是全球最熱門開源測試軟體 Selenium IDE V3、Katalon Recorder 與 Qualys Recorder 原型創造者。

在 Macbook Pro M1 (Apple Silicon) 安裝 K3s 的筆記。

這是一場很特別的活動：雲端職涯探索日 (104專區)，第一時間 AWS 的邀請我就毫不猶豫的答應了 XDD

只要是軟體開發，不管 Web Services、還是 Mobile 或 Desktop Application，都會需要建置 (Build) 與交付 (Delivery) 兩個核心過程。Web Services 的交付稱為部署 (Deployment)，應用程式稱為發佈 (Publish)。而這些過程，也伴隨著一些衍生的任務 (Task)，組成一連串的行為，隨著時間的推進，架構的改變，這些任務的組合，往往是工程師們的夢靨的開始。

工作上經常問題還沒被看清楚，只求快，要有成果，往往都只是做表面工作。

這篇整理自 2022/09/08、2022/07/22 我自己的思考的筆記，延伸 QBQ (問題背後的問題) 以及 如何意識到問題的存在，我自己深度體悟與昇華後的心得。

架構師的工作到底是做啥？用一張十年前 (2012) 我自己在 Plurk 寫下的定義，然後再真實經歷之後，重新回顧這段話。

Plurk Permalink

這篇是我在粉專寫下的 隨筆文，放在 blog 做個紀錄。

上一次的分享 之後，開始有 QA 的朋友找我聊很多他正在面對的問題。其中一個問題是：

Backend 開發人員說建立環境很難？是這樣嗎？

本文針對這個問題，整理背後可能的問題，以及實際可行的方法。全文整理自 09/18 在 FB 寫的草稿。

在 “淺談軟體測試的階段與策略“ 整理了各種測試的 “階段”，其中 #整合測試 (Integration Test) 是常見的階段之一，針對 “整合” 我的脈絡有以下：

1. 功能對功能 的整合
2. 系統對系統 的整合
3. 功能對系統 的整合

引用我 上次分享 整理的文字描述，如下圖：

Source: 演講：從理想、到現實的距離，開啟品味軟體測試之路

20230523 更新: 本文部分收錄在 共同著作《軟體測試實務》 第一冊 第五章之中，歡迎大家彭場指導。

整理對 Development Experience (DX) 的看法，原文草稿發表於 Facebook。

之前 很常跟朋友分享這段想法，底下把想法記錄下來。

我把工作上遇到的問題分兩大類：

1. 雜 (Complicate)
2. 難 (Defficult)

每個人對於寫 Blog 這件事情，都有自己背後的動機，我的初衷跟寫程式一樣，透過不斷的重構精練，這個過程是我學到最多的。

今天很高興在 台灣軟體工程協會，成功大學 李信杰 老師的邀請之下，讓我第一次分享關於軟體測試的想法與心得。

在投入 軟體測試 (Software Testing) 與 軟體品質 (Software Quality Assurance, SQA) 之前，我主要的工作角色是 軟體開發 為主，程式語言以 PHP / Java / Python、開發大型 Jave Enterprise Application 應用程式與 Eclipse Plugins 為主。過程中因為協助測試團隊改善 Application UI / WebUI 測試，因而踩入測試領域。

因為本身是具備開發背景，踩入軟體測試有別於一般人經歷，因此開啟不一樣的路。實際軟體測試的經歷，包含 WebUI / Desktop UI / Unit Test / E2E … 等自動化測試，設計與開發大型 “Test Framework and Architect for Regression Test“ 實務經驗。

這段經歷讓我對軟體測試的 技術與工程面 有很完整的歷鍊，所以後來也挑戰 在新創事業 (IoT 領域) 從零開始 建立軟體測試團隊，從團隊建立、制度、流程、工程、協作，建立完整的開發流程，其中領悟出最重要的 心法 就是 品質 的想法，因此寫下以下領悟：

品質不只有測試，而是整個 (開發) 過程。
品質從需求開始，測試只是種手段
用品質建立數量，由數量產生速度。