上一週參加的 Meetup 講師有把內容寫成部落格文章了，有興趣的可以看看他們故事 @@

Event storming 是個好東西：幫助團隊看見全貌，引發團隊變革新契機 - 艦長，你有事嗎？

當你想要導入 CI/CD、DevOps 或 OOXXOps 時，你會如何幫助所有的夥伴建立相同的共識？讓大家可以看見相同的全貌及痛點？

當團隊開始重視 DevOps 核心精神中的「交付價值、持續改善」時，我們確實需要一些不同於傳統會議與組織溝通的方法，來輔助不同的部門及團隊打破 silos 共同看見整體流程的完整面貌，畢竟我們都知道 DevOps 從來都不是一條龍工程師自己的事情。

在本次的 Meetup，我將會聊一聊幾個來自真實場景的小故事，分享這段由 Event Storming 所觸發的團隊變革旅程。

題外話，講者提到他帶著同事用便條紙，把到職到離職之間遇到的事、做的專案、學到的東西等等都整理出來

想到可以在牆上弄個時間軸、把便條紙貼一貼，就能直接看見自己負責的專案和學到的技能，感覺也挺不錯的

唯一的問題只有：好像沒多少東西能貼🥲

延伸閱讀：2/29 - 認識 Event Storming

Numbers Everyone Should Know - Everything is Data

這篇文章引用了 Jeff Dean 在 LADIS 2009 演講時提到的一些「每個人都應該知道的數字」，例如命中快取、傳輸資料等等，作為設計系統時的一種參考資料：

我更在意的是作者提到設計系統時會有用的兩個技能：

• 能夠針對不同設計方案的效能培養出直覺，才能拒絕不合理的設計
• 能夠動手測試，比較不同方案的效能，才能累積經驗、磨練直覺

有種藉由練習來磨練判斷力的感覺 🤔

今天挖到礦了 ，決定先挑一篇出來看。

今天要轉貼的是 X (Twitter) Enginering 在 2019 的這篇：
Deterministic Aperture: A distributed, load balancing algorithm

文章裡介紹了 Twitter 朋朋搞負載平衡的歷程，這邊也簡單筆記一下。有興趣的朋友可以直接進入文章閱讀，畢竟有圖還是比較好理解。

在介紹的過程中，先讓我們假設是「 Client – 呼叫 –> Backend 」這樣的關係

一開始他們是簡單粗暴地讓 Client 各自插負載平衡的東西，然後噴到 Backend 的服務上。但在服務擴展到幾千個實例之後，就開始出現了一些問題，例如分配 socket 啦 buffer 等等。

接著他們嘗試搞點隨機，雖然看起來好像不錯，但實際上變得更不平衡，一部署上去就讓服務們咚咚嚨咚鏘：

Before the deployment we see a nice collection of traces neatly stacked atop one another. After the deployment: pandemonium!

接著他們重新想了一下他們需要的東西：輕量、而且盡量不要被 Client 和 Backend 的數量變動干擾。

於是他們嘗試了環狀座標系統（Ring coordinates）

圖片來源：今天轉貼的這篇

從圖片上來看，每個 Client 和 Backend 都是圓圈上的一個點，假設有 3 個 Client，他們就會被各自畫在圓圈上 1/3 的位置；同時如果有 6 個 Backend，這些 Backend 的實例也會被各自畫在圓圈上 1/6 的位置，然後 Client 在圓圈上找到最近的 Backend 就打下去。

這次嘗試雖然已經比前面的隨機好很多，但仍然發現分配不均的狀況

最後他們延伸出了連續環狀座標

圖片來源：同樣是今天轉貼的這篇

連續環狀座標不是畫在圓圈的點上，而是圓圈的一段。假設有 3 個 Client，他們就會各占 1/3 圈

如此一來 Client 和 Backend 就會形成兩個圈。而外圈的 Client 就會按照比例對應到內圈的 Backend，達到非常舒服的平衡(?)

最後這篇文章列了一些實測的數據和使用上的限制（例如有突發性的高流量可能還是會讓壓力集中在某些 Backend 上）

The flexibility and performance of deterministic aperture has been successful and general enough to cement its place as the default load balancer algorithm at Twitter. Most services have been migrated to the new load balancer with only a handful of exceptions. With that comes a few small operational changes and limitations to consider.

Deterministic aperture 的靈活性和性能已經取得成功，並且足夠普遍，以至於在 Twitter 上鞏固了它作為默認的負載平衡器算法的地位。大多數服務已經遷移到新的負載平衡器，只有少數例外。隨之而來的是一些小的操作變化和限制需要考慮。

今天看到黑大前幾天發了索引破碎的文，順手轉貼上來；

GUID 叢集索引測試 2：索引碎片化分析與資料表虛胖問題
延伸閱讀：GUID Primary Key資料庫避雷守則

PK使用頻率很高，設成叢集索引對效能最有利，故慣例上會設成叢集索引以提升效能。

然而，因為GUID具有不連續的隨機性，即使循序寫入資料，常常後寫的資料GUID排序較前，依叢集索引特性，實體儲存位置應擺在前段，造成每次寫入資料都需挪動調整既有資料造成索引破碎，拖累寫入與查詢效能。

備註：我現在都無腦用 NEWSEQUENTIALID 了，好香好香

avg_fragmentation_in_percent 可視為碎片化的程度。Logical fragmentation 官方翻譯為邏輯片段，我覺得譯成「邏輯碎片」更體切，指的是索引資料分頁邏輯順序與實體順序不一致，邏輯上依索引順序應該連續的資料分頁，被放在不連續的實體位置，如此存取將需要更多 IO 動作，拖慢效能。此值介於 10 到 15 之間時建議做索引重組，大於 15 時應考慮進行索引重建。

avg_page_space_used_in_percent 則是資料分頁存放資料的比率，比例過低將造成空間浪費(本案例的狀況)，代表要走訪更多分頁才能蒐集完所需要資料，勢必影響效能。這個值介於 60 到 75 之間時建議做索引重組，低於 60 時應考慮索引重建。

敝司也有一張每天會有排程拋一卡車資料進去的表，也是使用 GUID 當 PK。DBA 才剛重建完沒兩天，avg_fragmentation_in_percent 就衝破 70

但因為年久失修綁定古蹟，也不怎麼查詢，現在就當成負面教材來宣導(?)，也算是加深印象了

今天跟朋友去聽了場 Event Storming 的分享，回家趕快查點資料補一下。如此如此這般這般，今天要轉貼的是這篇：

Event Storming Part 1 - 簡介與事前準備 - Think in Domain-Driven Design

既然這篇文章有 Part 1 的字眼，當然就還有後面幾篇。這邊也一併附上來（我之後要回來查資料也比較好查）：

• Event Storming Part 2 - 風暴展開
• Event Storming Part 3 - 軟體設計
• Event Storming Part 4 - 可以做的更好

看起來 Event Storming 是個揪團一起貼便利貼的歡樂活動，還能幫助團隊從彼此的視角找出盲點、建立共識等等

大家先自由地把事件（Event）貼出來，讓我感到比較新奇的是在於事件要用過去式來寫，身為一個平常用詞很模糊(?)的人，覺得這看法蠻有道理：

根據 Alberto Brandolini 本人的敘述，使用過去式代表著系統的狀態。如果你今天使用的是「註冊」這類詞時，你代表的是一個流程。相對的，用「註冊已開始」、「註冊已完成」會有更好的清晰度且顆粒度，避免過度設計。

然後大家嘗試從一條路徑（通常從 Happy path 開始）把事件串成一組故事，過程中也會請領域專家重新整理順序，在這過程中對焦彼此的理解：

這個過程中，大家可以發現不管是團隊間還是個人間對於同一份商業流程的理解有多麼的不同。

而在領域專家整理時，也可以讓大家知道哪些 Event 重要哪些不是我們需要關注的，加深大家對於系統責任邊界的了解。

第三輪的時候讓大家按讚跟標出問題，針對問題進行討論；第四輪再加上 Command（使用者或軟體所做出的決定，例如 買早餐 Command -> 已經買早餐 Event）、發出 Command 的角色、外部系統…等等。這整段讓我有種把故事越補越完整的感覺，也許還會讓團隊產生一種協作的成就感？

最後兩篇則提了從 Event Storming 到軟體建模，以及列了一些可能會翻車的問題（例如變成個人秀、突然噴一堆技術細節等等）。

但因為我沒跑過，只能先看過記錄下來:( ，比較不像前兩篇有 wow! 的感覺。

如果有跑過的朋朋能分享，或是丟更多資訊上來，我會跟你說聲甘溫

趁休假把系列文嗑完。今天要轉貼是和昨天同樣在「敏捷聖徒」系列的這篇：
「我們不交付大便」– 談開發步調與質疑成長 - Kuma

這篇文章先從一位估算很準朋友的故事開始說起，並帶到了估算的要點：持續而穩定的步調

各位有聽過 PDCA Cycle 嗎？這是指我們要完成一件事的四個流程：

• Plan：計劃
• Do：做
• Check：檢查
• Act：行動（指改善行動）

說穿了，敏捷開發從頭到尾其實是一個快速而持續的 PDCA 的過程。我們把一個很大的長期產品切割成一塊一塊的小部分，每個小部分做完的時候都回頭去看產品新的樣貌，並且決定下一個小部分要做什麼，什麼東西要加進來、什麼東西要丟掉，什麼事是我們這次沒做好，下次可以改善的。

而這組 PDCA 的過程，背後重視的是開發者的軟實力，例如說溝通能力，或是紀律：

Kent Beck 曾經說：「我不是一個很優秀的開發者，而我是一個還不錯的開發者，但有非常好的紀律。」

這些敏捷開發的框架，例如含 Scrum、看板、Extreme Programming 等等，他們強調的都是個人的紀律、團隊成員間的紀律、團隊對外的紀律，都沒有在強調硬實力。

你從來不會在任何一個敏捷開發的書或文章裡面看到資料結構、演算法、計算機系統，或網路底層原理。 為什麼？因為要完成你的工作，你本來就需要這些東西。就算別人不講，你不會的話本來就做不到。

敏捷開發想要做的事情其實是：在你開發時，把其它一些能夠阻礙你的外部因素全部排除掉，讓你能夠專心的發揮你原本就擁有的硬實力，進而助你取得持續而穩定的步調。

每當你違反開發人員的軟體紀律的時候，你交付出來的東西都是大便。

那如果我們沒有持續而穩定的步調，或是沒有把這些紀律落實呢？那麼我們也許就會把軟體弄得硬硬的(?)：

敏捷開發、軟體重構、單元測試、整合測試等，這些方法都不會幫助你提升硬實力，你寫程式的速度也不會變快，但是這些事情如果做得好，你的軟體每次的改動範圍都會跟你的需求的大小成正比。

什麼意思？你有沒有遇過一個情況：當客戶請你改一點點小東西，但是你實際上程式內部的改動卻會很大？ 如果有，這很有可能代表你前面的這些軟體紀律的事情沒有做的很好，你才會因為一個改動需求而不得不修改很大的範圍。

身為軟體工程師，當我們想要對 Stakeholder 提出一個反駁叫做「這個改動很大，我們很難做」的時候，我們其實應該要檢討自己，是否我已經把軟體給做硬了。

繼續把收藏著的鐵人賽文章消化掉。今天想轉貼的是 2023 敏捷聖徒系列的這篇：

「你要釐清責任，還是想解決問題？」– 談上游思維 - Kuma

這篇文章裡 Anna 和 Roy 的故事非常眼熟，可能有跨團隊協作的朋友都遇過。

但在『上游思維』這本書提到：當問題發生的時候，你可以選擇找出負責的人（下游），或是找出根源的解決方法（上游）

上下游的概念可能很模糊，作者也和前輩有一些討論，我覺得蠻好理解的：

上游的人用水卻同時也弄髒河裡的水，住在下游的人當然遭殃，而且責任不在下游的人而是上游的人。

下游的人當然可以抱怨，但上游的人其實不痛不癢，甚至根本不知道有什麼問題。

如果你是下游的人，會選擇怎麼做？換條河流嗎？如果換條河流仍然在下游，通常事情不會改變的。

而整篇最讓我感到衝擊的是這兩段：

你的工作內容的確是行銷企劃與執行沒錯，但其最終目的，也還是「為公司帶來營收」。

如果你放著你與 Anna 部門的矛盾不管，只想趕快把責任推出去，趕快回去寫下一份企劃案，這樣也只會造成本地最佳化，也就是一個等著馬上要造成下一次與開發部門爭吵的未爆彈。

對 KPI 也許有益，但對你的工作產生的價值沒什麼幫助。

因此，你這不叫回去做你的工作，你這叫「工作挑簡單的做」。

理想狀況下，平常大家各司其識，各自做各自的事是很美好的。

但環境總是會變，人也會變，當遇到問題（不一定是你造成的）不想從根本解決，而只是想趕快把責任推出去，回到你的小天地，繼續做你本來就擅長的事，這不是「工作挑簡單的做」，什麼才是？

老實說，我之前從來沒有從這個方向想過。對我這個後端 API 仔來說，最理想的狀況就是讓我在座位上搓八小時的程式碼。但事情總是沒有憨人想的這麼簡單

但當我們必須先解決一些不在我們專業的事情，才能專心地回去做我們的專業，而我們選擇不去處理的時候，是不是就像這篇文章說的「工作挑簡單的做」呢？

這篇文章成功地引起我去思考這些問題，雖然我還沒有一個明確的答案，但還是決定轉貼上來給大家，有相似狀況的朋友們也可以想想

同時也提供文章內的解決方式，供各位參考(?)

1. Change your company, or
2. Change your company.

今天繼續把之前提過的鐵人賽看完。今天抽出來轉貼的是聊技術債的這兩篇：

• 技術債是糙 code ?? (上) - 可不可以不要寫糙 code
• 技術債是糙 code ?? (下) - 可不可以不要寫糙 code

技術債的產生可能有很多原因，例如為了趕快上線所以先妥協實作方式，又或者是複製貼上而產生更多債務。

在這篇文裡也引用了許多前輩的文章來介紹技術債。例如：

抄捷徑的技術債，遲早要還的 - 王建興

技術債和財務領域中的債務觀念，有一些可以類比的地方。人們會產生財務上的債務，通常是因為對於立即性資金的需求，也就是說，可以在短期內得到好處。但是，無論是向銀行或是其他個人借貸，總是需要付出代價，也就是利息。

無論是不夠完備的架構設計，或是具有壞味道的程式碼，都會隨著時間，持續地讓開發團隊付出代價。但是，只要付出的代價是可以接受的（小於得到的好處），那麼，欠下技術債的決策就很有可能是個合理的決策。不過隨著債務積欠愈來愈多，或是固定的債務始終沒有償還，那麼就得付出愈來愈多的利息，或是持續長久的付出利息，最終就可能發生得不償失的情況。

技術債（Technical Debt） - 看到 code 寫成這樣我也是醉了，不如試試重構？

Martin Fowler 把技術債產生原因分成了兩種維度，分別是魯莽（reckless）、謹慎（prudent）與有意（deliberate）、無意（inadvertent）

依欠債方法來看，技術債有以下種類：

• 設計缺陷，這也是一般最常見的技術債。
• 文件不足，包括沒寫註解或是專案文件等。
• 缺少測試，原本應該要正確的功能，會因為沒有測試好而產生 bug 。
• 明知該實作，卻沒實作。比方說：明知沒實作快取，會讓服務反應時間過久，但沒實作也能動，就先交貨了。

廣義來說，只要技術上會難以修改的理由，都可以算是技術債。

但我更喜歡內文對技術債直接粗暴的介紹：

只要是留給別人修改的 code 都是糙 code

這篇文也列出了前面幾種技術債該面對的心情，例如文件不足、設計缺陷等等。搭配作者引用的相關參考，應該能對技術債的概念有些認識

看了這些文章的時候，呃，對後續維護我的 Code 的朋朋們還真是不好意思 xD

最後，提到技術債一定要引用最經典的這篇：工程師應該放心大膽地創造技術負債

如果你在一家公司寫了一大堆完全不考慮耦合關係、程式邏輯糾纏不清、命名混亂、使用大量 anti-pattern、到處都是怪氣味、效能極差而且宛若天書的程式碼，而你開始為了繼續維護這樣的技術負債感到痛苦的時候，其實只代表一件事情：你已經在這家公司獃得太久，而且還沒有升上去當主管。

太痛苦了。

前幾天跟朋友聊天的時候，剛好聊到地址定位。其實除了常用的地址和經緯度以外，還有一種神奇的地理編碼方式：三詞地址

用三個詞找到你！what3words 一種全新概念的定位方式

三詞地址會將地圖上切成很多個小小的方格，並且替每個方格用三個詞取一個名字。例如台北１０１捷運站的四號出口就是「地瓜、安全、燈泡」

因為這些方格非常小，精準度達到三公尺，因此當遇到地址難以標示、荒郊野外或是建築物很大一座的時候，就可以使用三詞地址。

例如和朋友約在某個廣場，但又沒有顯眼的地標，就可以直接使用三詞地址約在某一格見面。目前三詞地址也應用在緊急救援、物流公司等等，對目標地點要求比較精確的場景。

有興趣的朋友也可以到以下網址玩玩看： https://what3words.com/

那麼，今天的轉貼就到這邊，明天見～

延伸閱讀：

• Three random words saved Cornelia on a cold, wet day of bushwalking
• 聰明救人新科技：三個詞，天涯海角找到你
• 三詞地址 - 維基百科

今天想轉貼的是 2019 鐵人賽的這篇：
實務上的高內聚與低耦合 - 可不可以不要寫糙 code

其中有一小段我很喜歡，當時解決了我某種「消除重複！」的迷思：

「程式碼沒有要重複使用，為什麼要弄成一個 function？」

但是，反問一下這個問題

「難道需要變成 function 的都只是因為重複使用而已？」

除此之外，這系列的開頭也很棒：

良好程式碼的優點大同小異。
不好的程式碼的糙點卻各有巧妙之處。

搭配這篇閱讀風味更佳：如何寫高品質 function (內聚性篇) - 可不可以不要寫糙 code