<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Reading on omegaatt</title>
    <link>https://www.omegaatt.com/tags/reading/</link>
    <description>Recent content in Reading on omegaatt</description>
    <generator>Hugo -- 0.164.0</generator>
    <language>zh-TW</language>
    <managingEditor>raiven.kao@gmail.com (Raiven Kao)</managingEditor>
    <webMaster>raiven.kao@gmail.com (Raiven Kao)</webMaster>
    <copyright>Raiven Kao 2020 - 2026</copyright>
    <lastBuildDate>Thu, 19 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.omegaatt.com/tags/reading/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Clean Craftsmanship：在 LLM 時代重拾軟體工匠精神</title>
      <link>https://www.omegaatt.com/blogs/develop/2026/clean_craftsmanship/</link>
      <pubDate>Thu, 19 Feb 2026 00:00:00 +0000</pubDate><author>raiven.kao@gmail.com (Raiven Kao)</author>
      <guid>https://www.omegaatt.com/blogs/develop/2026/clean_craftsmanship/</guid>
      <description>&lt;h2 id=&#34;為什麼在這個時間點讀這本書&#34;&gt;為什麼在這個時間點讀這本書&lt;/h2&gt;
&lt;p&gt;最近對於如何在 LLM 時代帶領團隊一起提昇生產力感到困惑。當 AI 能在幾秒鐘內生成幾百行程式碼，「寫程式」這件事的門檻似乎降到了前所未有的低點。但門檻低了，品質呢？&lt;/p&gt;
&lt;p&gt;當「每個人」都在養龍蝦，有了生產力焦慮，TypeScript 寫的 &lt;a href=&#34;https://github.com/openclaw/openclaw&#34;&gt;OpenClaw&lt;/a&gt; 才剛出現，Python 的 &lt;a href=&#34;https://github.com/HKUDS/nanobot&#34;&gt;NanoBot&lt;/a&gt; 馬上跟上，接著是 Golang 的 &lt;a href=&#34;https://github.com/sipeed/picoclaw&#34;&gt;picoclaw&lt;/a&gt;，然後 Rust 的 &lt;a href=&#34;https://github.com/zeroclaw-labs/zeroclaw&#34;&gt;ZeroClaw&lt;/a&gt; 也來了。&lt;/p&gt;
&lt;p&gt;根據 ZeroClaw 做的 &lt;a href=&#34;https://github.com/zeroclaw-labs/zeroclaw?tab=readme-ov-file#benchmark-snapshot-zeroclaw-vs-openclaw-reproducible&#34;&gt;benchmark&lt;/a&gt;，這些 Agent 已經降到小於 5MB 的記憶體佔用與 10ms 的啟動時間，「種族」為人類的我們對於產出軟體來說還剩什麼？&lt;/p&gt;
&lt;p&gt;帶著這個問題，我決定先從自身出發，找出在 LLM 時代還能保持軟體工程「工匠精神」的誘因。於是翻開了 Robert C. Martin 的 &lt;a href=&#34;https://www.tenlong.com.tw/products/9786263339941&#34;&gt;&lt;em&gt;Clean Craftsmanship&lt;/em&gt;&lt;/a&gt;。&lt;/p&gt;
&lt;p&gt;這本書分為三個部份：&lt;strong&gt;紀律、標準、道德&lt;/strong&gt;。一半以上的篇幅在講述 TDD 這個老生常談的開發方式，但透過 TDD，我們更能知道何謂軟體的「品質」。以下是我特別書籤的幾個段落。&lt;/p&gt;
&lt;h2 id=&#34;紀律&#34;&gt;紀律&lt;/h2&gt;
&lt;h3 id=&#34;童子軍規則&#34;&gt;童子軍規則&lt;/h3&gt;
&lt;blockquote&gt;
&lt;p&gt;離開營地時，要比你來時更乾淨。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;這也是在 &lt;em&gt;Clean Code&lt;/em&gt; 一書就提到的概念。每次微小的重構，都能小程度的減少技術債的產生。不需要一次大刀闊斧，只要每次經過一段程式碼時，順手讓它變得更好一點。&lt;/p&gt;
&lt;p&gt;讓我想到 &lt;a href=&#34;https://www.approachwithalacrity.com/claude-ne/&#34;&gt;Claude is not a senior engineer (yet)&lt;/a&gt; 這篇文章中提到的 Sweeks——一位被稱為「園丁」的 distinguished engineer，他不斷地重寫、收緊抽象，讓經過他手的程式碼都變得更乾淨。我們都想成為 Sweeks，對吧？&lt;/p&gt;
&lt;p&gt;在 LLM 時代，AI 擅長的是「組裝」現有解決方案，但它缺乏 Sweeks 那種「看到可以更好的地方就會忍不住動手」的靈魂。童子軍規則提醒我們：這份靈魂不能丟。&lt;/p&gt;
&lt;h3 id=&#34;test-doubles-的正名&#34;&gt;Test Doubles 的正名&lt;/h3&gt;
&lt;p&gt;書中透過實戰的例子講述了所有 test double：&lt;strong&gt;Dummy、Stub、Spy、Mock、Fake&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;坦白說，我曾經在諸多 repo 中看到這些名詞卻沒有實際使用它們。頂多在 DI 時製作了一個「用於模擬 database repository 的 implement」，或是使用了 &lt;code&gt;gomock&lt;/code&gt; 這種套件來產生 mock，然後把所有替身都統稱為 mock。&lt;/p&gt;</description>
    </item>
    <item>
      <title>Agile Testing 閱讀筆記</title>
      <link>https://www.omegaatt.com/blogs/develop/2024/agile_testing/</link>
      <pubDate>Sun, 24 Mar 2024 00:00:00 +0000</pubDate><author>raiven.kao@gmail.com (Raiven Kao)</author>
      <guid>https://www.omegaatt.com/blogs/develop/2024/agile_testing/</guid>
      <description>&lt;iframe src=&#34;https://gamma.app/embed/8r0jqfc8k78lads&#34; style=&#34;width: 100%; max-width: 100%; height: 450px&#34; &gt;&lt;/iframe&gt;
&lt;h2 id=&#34;鋪墊敏捷開發價值觀原則與實踐&#34;&gt;鋪墊：敏捷開發價值觀、原則與實踐&lt;/h2&gt;
&lt;p&gt;有什麼開發，就有什麼測試，傳統開發就有傳統測試，敏捷開發就應該要推行敏捷測試。在討論敏捷測試前，應該先理解敏捷開發模式，否則理解敏捷測試會很困難。&lt;/p&gt;
&lt;p&gt;敏捷開發是一種思想或稱作方法論，通過不斷迭代與增量發布，最終交付符合用戶價值的產品。&lt;/p&gt;
&lt;p&gt;書中提到一些敏捷開發的歷史、演進與框架&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;PDCA 循環&lt;/li&gt;
&lt;li&gt;輕量級軟體開發
減少複雜的文件，強調人員的互動&lt;/li&gt;
&lt;li&gt;敏捷宣言&lt;/li&gt;
&lt;li&gt;XP（eXtreme Programing）：較多是著重在軟體開發，例如 TDD、pair programing、CI 等等。&lt;/li&gt;
&lt;li&gt;BDD（行為驅動開發）：使用「通用語言」來描述測試案例，將 User Story 的細節進行完整地描述。
&lt;strong&gt;Feature（特性）&lt;/strong&gt;: 購物車功能
&lt;strong&gt;Scenario（情境）&lt;/strong&gt;: 添加商品到購物車
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Given&lt;/strong&gt;（假設）: 用戶已經登錄到購物平台並且正在瀏覽商品&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;When&lt;/strong&gt;（當）: 用戶點擊某個商品的「添加到購物車」按鈕&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Then&lt;/strong&gt;（那麼）: 該商品應該被添加到用戶的購物車中&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;And&lt;/strong&gt;（並且）: 購物車中的商品總數應該更新&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;FDD（特性驅動開發）：使用制式結構來建構特性列表&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;code&gt;&amp;lt;action&amp;gt; the &amp;lt;result&amp;gt; &amp;lt;by|for|of|to&amp;gt; a(n) &amp;lt;object&amp;gt;&lt;/code&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Scrum：確保每天、每個階段都向著目標明確進行的一種「方法」。
推薦看 Scrum 提倡者自己寫的 &lt;code&gt;SCRUM：用一半的時間做兩倍的事&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;devops-與敏捷的關係&#34;&gt;DevOps 與敏捷的關係&lt;/h3&gt;
&lt;p&gt;DevOps 可以看作是敏捷的延伸，打通軟體開發、測試、交付、維護中的層層牆壁。&lt;/p&gt;
&lt;h3 id=&#34;敏捷宣言&#34;&gt;&lt;a href=&#34;https://agilemanifesto.org/iso/zhcht/manifesto.html&#34;&gt;敏捷宣言&lt;/a&gt;&lt;/h3&gt;
&lt;p&gt;藉著親自並協助他人進行軟體開發，我們正致力於發掘更優良的軟體開發方法。透過這樣的努力，我們已建立以下價值觀：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;個人與互動 重於 流程與工具&lt;/li&gt;
&lt;li&gt;可用的軟體 重於 詳盡的文件&lt;/li&gt;
&lt;li&gt;與客戶合作 重於 合約協商&lt;/li&gt;
&lt;li&gt;回應變化 重於 遵循計劃&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;也就是說，雖然右側項目有其價值，但我們更重視左側項目。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;敏捷測試之道&#34;&gt;敏捷測試之道&lt;/h2&gt;
&lt;p&gt;敏決測試不是一種測試方法，而是為了適應敏捷開發而設計的一套軟體測試解決方案。&lt;/p&gt;
&lt;h3 id=&#34;敏捷測試宣言&#34;&gt;敏捷測試宣言&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;Full Lifecycle Testing &lt;strong&gt;OVER&lt;/strong&gt; Isolated Testing Phase&lt;/li&gt;
&lt;li&gt;Team Shared Responsibility &lt;strong&gt;OVER&lt;/strong&gt; Testers Ensure Quality&lt;/li&gt;
&lt;li&gt;Continuous Targeted Automation &lt;strong&gt;OVER&lt;/strong&gt; Widespread Regression Testing&lt;/li&gt;
&lt;li&gt;Quality Built-in &lt;strong&gt;OVER&lt;/strong&gt; Defect Detection&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;full-lifecycle-testing&#34;&gt;Full Lifecycle Testing&lt;/h4&gt;
&lt;p&gt;強調測試左移與右移，並非將測試「移動」到兩個端點，而是全程測試的介入。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
