今天轉貼一篇我很喜歡的文章，在嘴人的場合很好用：
一窩蜂驅動開發 - Northern Wind

原文：Hype Driven Development

一窩蜂驅動開發，又能稱作「Reddit 驅動開發」、「研討會驅動開發」、「講話最大聲的說了算」等等。

基本上就是看什麼最夯就用什麼，把新工具視為一切解決方案，然後馬上跌坑的開發方式

一窩蜂會造成錯誤的決策。架構設計錯誤與技術選用錯誤都會困擾團隊數個月甚至數年之久。 最壞的情況會造成另一個很糟糕的行為：砍掉重練，這樣做永遠不會有好結果的。

在這篇文章中，作者提出了一窩蜂開發的五個階段：

• 第一階段：真正的問題與解答
• 第二階段：曝光、瘋傳、關鍵字
• 第三階段：狂熱開始
• 第四階段：失望
• 第五階段：多麼痛的領悟

看說明不如看例子，這篇文章提了五個範例，我轉其中兩個我平常比較有感的出來：

範例一：React.js

第一步： Facebook 遇到一個問題－有些複雜的單頁應用，像是 Facebook 本身，有著大量會改變狀態的事件。會變得很難去追蹤到底觸發過什麼事件或是很難確保程式的狀態保持一致。

第二步： Facebook 開始推廣新的設計，夾帶著一些關鍵字：函數式程式設計（Functional）、Virtual DOM、Components。

第三步： 狂熱：Facebook 創造了跨時代的網頁框架！從今天起所有東西都該用 React.js 來寫！

第四步： 等等，這東西工程浩大，短期之內卻沒有什麼回收！

第五步： React 對於有很多即時通知的單頁應用很棒，但是用在簡單的網頁應用上卻不一定會獲得回報。

範例三：Microservices

第一步： Monolithic application 難以擴展。現在有個做法是把它拆解成很多小服務。這樣每秒能處理的需求量可以更方便做擴展 ，跨團隊的擴展也更容易做到。

第二步： 關鍵字：可擴展性（Scalability）、低耦合（Loose coupling）、Monolith。

第三步： 我們把所有東西都成寫成服務吧！我們的程式一團亂都是因為我們用的是 Monolith architecture！我們必須把所有東西都改寫成 Microservice 。

第四步： 挫賽！現在開發變得超慢的，部署也變困難了，然後追 bug 要橫跨多個系統。

第五步： Microservices 需要有經驗的團隊還有在正確的時間點投入才有可能在系統與團隊擴展時有所回報。當你在遇到真正的擴展問題前用就是過度投資。Microservices 往往是拆解出來的而非直接寫成，你要這麼大才能用 Microservices。

今天看到一篇標題引起我興趣的文章，這邊也轉貼上來給大家：
Global Game Jam 2024 - 軟體架構適用遊戲開發嗎？ | 弦而時習之 (aotoki.me)

我的看法和作者一樣：遊戲也是軟體的一種，所以軟體架構的思維當然也可以在開發遊戲時派上用場

並且在這篇文章中，作者也提了把 CA 套進去 Unity 遊戲開發的思路（拆成 Presenter 跟 Core，在 Unity 用 Reflex 這套工具來處理依賴注入等等）以及對狀態維護的一些心得

不過我個人身為一個 CRUD 工程師，並沒有開發過遊戲（用過 RPG 製作大師應該不算吧），所以看這篇就是來長見識的

今天朋友拋了一篇文章過來，覺得不錯所以整理一下轉貼上來：
Development slowness in big and legacy applications [and how to hurry it up]

這篇文章整理了一些作者觀察到大規模老舊專案（或是大公司）之所以變「慢」的原因，一口氣列了八項，這邊也稍微貼過來給各位朋朋：

• 複雜度
• 跨團隊溝通
• 安全與隱私
• 程式碼標準
• 開會
• 金絲雀帶來的麻煩
• 數據驅動決策
• 花在開發的時間變少

接著我們也簡單看過每一項的內容。首先是複雜度，有很多可能會發生的問題：

• 沒有人熟悉這個產品（有太多的功能或細節，沒有人能夠全面了解，就容易出錯）
• 複雜的架構和抽象化（持續堆疊功能從不重構，直到專案變成一團混亂）
• 客製化的建置和自動化（雖然應該是自動化的，但實務上常常會需要調整，導致菜鳥需要花更多時間了解）
• 工具過剩（大量的內部工具，例如自製測試小工具。導致菜鳥要上手的時間變得更長，還需要額外維護）
• 衝突（越多人做同個專案，就會有越多衝突要解，越多的內容要溝通，產生更多的延遲）
• 建置時間（專案越大，就跑得越久。而且相關優化的優先度通常都不高）

針對以上問題，作者也提出一些可能的解決方案：

• 分配一些資深人員專門處理建置優化、內部工具和持續整合等 DX （使用者體驗）部分
• 把內部工具當成公開工具（產品）一樣地維護
• 建立菜鳥入職流程和文件，幫助他們上手
• 不要忽視技術債，合理地安排重構還債
• 讓工程師去參加一些黑客松或創意週之類的

除了複雜度的篇幅比較長以外，其他七項相對就短一點。這邊就整合在一起（我就不需要再開一張卡片，哈）

跨團隊溝通 現在的大公司常常會有全球工程師分批進行維護，導致溝通時間也會因為時差被拉長。這時候就可以限制負責同個功能的團隊所在位置（例如把某功能的工程師集中放在某兩個區域，美國或印度之類的）

安全與隱私 為了保證符合資安和隱私規範，需要等待很多審查時間。這時候可以聘請一位資安相關的專業人員負責，並且盡可能簡化審查流程

程式碼標準 使用靜態程式碼分析工具，例如 JavaScript 的 ESLint 或 C# 的 StyleCop（沒有用過，過幾天再來研究）

開會、開會、開會 設定議程、限定會議時間、只邀請必要的參與者、事先發送會議文件、事後發送會議摘要

金絲雀ㄟ麻煩 現在常會看到先給小部分使用者使用新功能，OK 之後再增加使用者數量。但逐步增加使用者數量 = 花更多的時間，雖然使用 feature flags 可以緩解（切換速度變快，不用等重新上板），但作者唯一解是同時推進多項工作 QQ

數據驅動的決策 小公司可以冒險，但大公司的決策通常需要看到數字才能進行，例如提出 A/B 測試，並且有成效說服上層之後才可以繼續推。這一項作者沒有提出解決方案…

花在工作的時間變少 員工必須要參加團隊活動、全體會議、培訓、1 on 1 之類的，累積起來佔用了許多時間。這一項也沒有提出處理方式，可能無法迴避

以上人工簡短地整理了文章提到的內容，但每一項作者都有用兩三段來說明他觀察到的部份，有興趣的朋友推薦可以閱讀一下，然後想想自己家有沒有遇到相似的狀況，又是怎麼解決的（或可以怎麼解決？）

雖然我家沒有插 reCAPTCHA，不過今天看報紙的時候看到這則訊息，決定還是先轉貼上來，有用到的朋友就可以參考一下：

• Google reCAPTCHA 暴改收費政策，強制升級 Enterprise 版本，用量太大要付費 – 要改的地方太多了，那就改天吧

這篇文章裡面提供了免費仔該做的動作：

• 先檢查用量有沒有超過 100 萬（注意是整個帳戶一起算）
• 什麼情況下可以舒服地升級

以及轉移之後的 reCAPTCHA Enterprise 有哪些新功能（檢查使用者密碼有沒有外洩這條挺微妙的）、部份 API 的改動等等

最後也提供了其他替代服務，例如 hCaptcha、Cloudflare Turnstile

今天忙了一天，按照慣例(?)就是該分享一些有趣的東西水過去了：

中文文案排版指北 (Github)

「有研究顯示，打字的時候不喜歡在中文和英文之間加空格的人，感情路都走得很辛苦，有七成的比例會在 34 歲的時候跟自己不愛的人結婚，而其餘三成的人最後只能把遺產留給自己的貓。畢竟愛情跟書寫都需要適時地留白。

與大家共勉之。」

以後誰中文和英文之間沒加空格，記得把這篇甩在他臉上

禮拜一不想上班，決定繼續消化收件閘當個薪水小偷。今天看到一篇持續創作和自我懷疑的心得文章，其中一段讓我頗有共鳴，決定轉貼上來：

• 當我覺得自己做的很爛時，我會做些什麼？ - hyuanverse
• 原文：What I Do When it Feels Like My Work Isn’t Good Enough

在公開分享我的作品幾個月後，事情開始有了變化。

隨著我開始有了第一位受眾，我注意到我開始評估我的產出。起初，我只是很開心的把我的想法寫下來，但現在我會希望他們都是「好的想法」。我開始拿新的文章跟那些最熱門的文章比較。我不斷地用心中那把「好壞尺」來衡量我所寫的一切——即使我不知道那究竟是什麼。

這讓我想到我們在 1/22 分享的「公開學習與部落格」裡面的心魔。而這篇的作者最後也成功跨過了心魔：

幸好，我並沒有讓自我懷疑阻止自己的腳步。我把這視為任何一位持之以恆的創作者都會遇到的創作歷程。我告訴自己，批評和自我懷疑只是一個在「創造好內容」這條旅途上持續前行的過路費。

而作者在閱讀《比賽，從心開始》的時候，其中一段讓他重新思考了上面的心魔，也是這段讓我決定今天分享這一篇：

當我們把一個玫瑰種子埋在土裡時，我們知道它還很小，我們不會批評它怎麼還沒有長出根和莖。我們把它當作一顆種子來看待，提供它作為一個種子所需要的水和養分。

當它逐漸破土而出，我們不會為它冠上不成熟或發育不全的罪名，也不會因為還沒有發芽而批評它。我們會為它正在發生的成長感到驚嘆，並且在每個成長階段中提供它需要的所有照顧。

從它還是顆種子到它凋謝，這株玫瑰一直都是它自己。在成長過程裡，它永遠都蘊含著完整的潛力。它看起來隨時都在變化，然而在每一個階段，在每一個瞬間，它都是完美無瑕的，如同它所是的那樣。

當作者再度覺得自己「做得很爛」、陷入批判自己的陷阱裡時，他就會告訴自己：每一個結果都只不過是「重複光譜」上的一個點

今天躺了大半天，沒有繼續消化收件閘的文章，決定簡單轉貼一下之前看到的〈三次原則〉文章：
程式設計心法 三次原則（Rule Of Three principle） - 璇之又璇的網路世界

我們都知道程式碼整天複製貼上、散得到處都是會變得很難維護，所以我們需要把重複的程式碼抽象出來

但如果太早就進行優化，又很容易陷入過度設計，替未來的開發加上一些根本不必要的約束和成本

那麼我們到底什麼時候可以動手重構，把重複的程式碼抽出來呢？這時候就可以參考三次原則：

“Three strikes and you refactor”

昨天的轉貼有提到「正確」和「適合」這件事，決定轉貼一下前幾天滑到的推文：
和年轻朋友聊天的总结 (Part. 1) - Xiaowen

其中有一段我覺得很不錯：

同一個技術棧，在不同的行業，不同的場景里，可能有完全不同的工程形態，技術生態。

理解業務，才能讓自己橫向的去比較技術在行業里的不同，更立體的建立自己對技術的理解，未來真的需要你做技術選型，架構決策的時候，你的出發點才能是：「選擇最合適的技術」，而不是「選擇我最熟的技術」

因為我是個懶惰的人，因此在決定要怎麼解決某個需求的時候，很自然就會選擇已經熟悉慣用的方法

所以看到上面的『「選擇最合適的技術」，而不是「選擇我最熟的技術」』這句話，有種敲響警鈴的感覺

今天持續消化訂閱箱的文章，看到一則標題蠻有興趣的，也轉貼上來給大家：
Git 版控到底有沒有正確的用法? - .Net Walker

這篇文章中，作者大大先從 Git Flow 大爆發(?) 的歷史背景提起：

Git 的使用，一般來說，有爭議或選擇的是兩個部分：Repo 大小的分割 (專案顆粒度)，以及 git working flow…

拿 git working flow來說，如果是早年的 Git 使用者，多半選擇 git flow，那是有當年時空背景因素的。

Git 發展初期，需求是開源專案，開發人員可能並不在同一個辦公室協作，常有跨國合作的需求，當時網路狀況也不像現在品質那麼好，那時分支的建立就相當多且頻繁。

但馬上就帶到現在常用的開發狀況，以及持續整合的部份：

最近幾年，我們是不建議切出具有 長生命週期 且 數量多的分支的，因為分支本身就是一種程式碼隱藏。

Continuous Delivery 的作者 Dave Farley 就說過， 從頻繁交付的角度來看，具有長生命週期且多分支的 git flow 是個不好的選擇: https://www.youtube.com/watch?v=_w6TwnLCFwA

所以，如果要實踐敏捷的頻繁交付 (一周數次，一天數次) 那我會建議 git 分支數量愈少愈好，分支生命周期愈短愈好，以便能有利於持續整合，實現頻繁交付

如果你想實踐真正的持續整合(CI)，就要盡可能地減少不力於頻繁整合的程式碼隱藏，而分支，毫無疑問是一種程式碼隱藏

這邊讓我學習到一件事：分支也是一種程式碼隱藏

上班第二天終於有心情來消化一下訂閱箱裡面的文章，結果看到一篇德魯大大的文驚為天人，馬上轉貼上來：[架構師觀點] 開發人員該如何看待 AI 帶來的改變?

在這篇文章裡，德魯直接拿 API 給 GPTs 作一個訂單 BOT。除了一般的查詢商品和下訂單以外，還嘗試在對話中刁難它、叫它推理出某項商品有折扣，或是整理歷史訂單之類的。而 GPTs 雖然偶有瑕疵，但還是達成了任務。

前半段的實作和 Demo 頂多讓我覺得：「GPTs 有點香ㄟ」，但後半篇的火力更是讓我驚訝。

從 GPTs 的測試，德魯大大延伸了 API 的設計和德魯覺得後續開發人員該做什麼等議題。例如說 API 的設計將比以前都更講究合理可讀，因為：

未來的 API 會越來越重要，服務不再是 UI first, 而是 API First…

因為，掛上 LLM 後的 API ( Plugins ), 呼叫你 API 的不再是其他開發者了, 會變成 AI 來呼叫你的 API。你已經無法 “預測” 或是 “約束” 對方該怎麼呼叫。這時你只剩兩條路可以選擇，一個是把你的 API 設計的合情合理，完全符合現實世界的運作邏輯 (就是我常講的 OOP 精神: 模擬世界 加以處理)，你只要用 Prompt 就足以交代 AI 該怎麼使用 API。

另一個就是把你的 API 做到邏輯無懈可擊，滴水不漏。不論 AI 用什麼順序呼叫，傳遞什麼參數給你，都不會發生意料之外的結果。這個非常吃嚴謹的設計，我曾在 API First 不斷強調 “有限” 狀態機的重要性，就是預防這種錯誤。

我先前從沒想過 API 在未來很可能是由 AI 來呼叫，我很可能不能再走去串接對象的座位旁邊，拍拍他的肩膀跟他說「你就給我這樣打，懂？」

這強迫了我的 API 畢竟設計得更乾淨，以避免 AI 「誤會」我的意思。