這個書單討論的是一個人怎麼把軟體寫好、改好、維持得住。它跟 軟體管理與組織 書單的差別在討論的主題放在哪裡：軟體管理與組織書單討論的主題放在人與制度上，這個書單討論的主題放在產物上。分界不在「有沒有離開編輯器」——系統架構那篇的取捨要跨越團隊、資料與既有承諾，代價有一半落在組織上，但讀者在那裡決定的仍然是系統長什麼形狀。另有 財務與投資 與 媒介與輿論 兩個書單，討論的主題分別放在讀者自己的錢上與讀者自己對世界的判斷上，跟這裡不共用讀者位置。各書單為什麼按這個軸分開，說明在 書單推薦怎麼用。

書的描述沿用同一套維度（證據來源、時效狀態、處境相容性、讀得出價值的前提），定義與這些判定的來源說明在 書單怎麼描述一本書。這四篇的起點書用的也是同一組判斷標準（涵蓋面優先、其次證據來源夠不夠支持那個用途、再其次可操作性），判斷標準寫在 起點書的選擇標準：涵蓋面、證據與可操作性的優先序。驗證那篇是唯一的例外：它的起點取 Beck，理由是 Freeman 與 Pryce 那本、Khorikov 那本都在跟它對話，那條「歷史先行性」不在三層判斷標準裡。

技藝類書的時效判讀：主張與示範程式碼分開看

技藝類的書比管理類更容易局部過時，因為它們的例子綁在語言、工具與當時的工程環境上。判斷方式不變——問這一段的論證依賴什麼前提——但套用時要多分一層：主張本身（模組該怎麼切、重複意味著什麼）通常比示範它的程式碼活得久。看到過時的語法不要連著把主張一起丟掉，那是這類書最常見的誤判。

反過來也成立：一本書的示範用了最新的語言特性，不代表它的主張比較新。

工程技藝的主題表與各主題的起點書

設計、改既有的程式與系統架構之間的尺度關係

這個書單有四個主題，其中三個是同一組概念在三個尺度上運作。耦合與內聚這兩個概念貫穿它們，只是作用的範圍不同。Kent Beck 用它們算「這幾行現在要不要整理」，Ousterhout 用它們判斷「這個模組的介面該多深」，Richards 與 Ford 在元件層用同一組概念談切分與粒度。三個主題是同一組概念的三個尺度，而不是三種學問。這三個尺度的代表作跟各篇的起點書只有一本重疊：架構那一層兩者都是 Richards 與 Ford，最小與模組兩層不同——照各篇起點書讀的讀者，在最小尺度讀到的是 Fowler 而不是 Beck，在模組尺度讀到的是 Pragmatic Programmer 而不是 Ousterhout。Fowler 那本與 Pragmatic Programmer 各自是所屬主題涵蓋面最廣的入口，而不是這組概念的代表作。要看這組概念本身，最小與模組兩層直接取 Beck 與 Ousterhout。

知道這件事有一個實用後果：換尺度是一種可以主動做的判斷。同一類問題反覆出現而每次都在原尺度處理，通常代表問題不在那一層——整理這段程式碼整理了五次而它還是難改，該往上看模組邊界；模組怎麼切都不對，該往上看系統的責任分配；而系統怎麼切都有人抱怨，那可能已經不是技術問題，該讀的書收在 組織結構與團隊設計的選讀書目。

反過來也成立。架構圖畫得再乾淨，落到每次修改仍然要有人決定先整理還是後整理，而那個決定沒有架構層的答案。

驗證自己寫對了 不在這三個尺度上，它橫跨三者——每個尺度都要回答「我怎麼知道自己沒弄壞」，而那個問題在一次修改、模組邊界與系統拆分上會得到不同的答案。

不按職涯位置分眾的理由

軟體管理與組織書單按讀者對什麼負責分成五個位置，這個書單刻意不這樣分，理由是技藝問題跟職涯位置的相關性遠低於管理問題。

資深工程師與剛入行的人在重構同一段程式碼時，需要的是同一本書；差別在讀得出多少，而那個差別已經寫在每本書的「讀得出價值的前提」裡，不需要再開一層路由來分。更根本的是這個書單的主題本身就是分眾機制——讀者依當下在做什麼自己選尺度（我正在改這幾行、我在切模組、我在決定系統形狀），而那個選擇比職稱準確得多：同一個人在同一週可能三個尺度都碰到。

因此這個書單的入口是主題表，不是位置表。要按職涯位置選書的讀者，按位置分的選書收在 依位置選書，而那裡的五篇也會在需要技藝內容時指過來。

各主題的公開課涵蓋狀況

讀者讀不動長篇文字時，同一份知識可以改從公開課的影音取得，收錄門檻寫在 公開課的收錄門檻與它服務得了的處境。這個書單套用知識本質恆定與實際有影音這兩條門檻之後，有公開課可收的只有 系統架構的選讀書目，設計判斷標準、改既有的程式與驗證三個主題都沒查到，而這三個主題沒有課的理由各自不同：設計判斷標準與改既有的程式的理由寫在各自那一篇講各書分工與沒收錄書類的那一節內，驗證自己寫對了 另有一節（公開課以外的影音路徑與檢索關鍵字），因為那一篇後來查出它有影音路徑，只是落在別的關鍵字底下。這個書單與 財務與投資 書單的差別在沒查到的主題數：財務與投資書單四篇都有課，所以它不需要這樣一段書單層的說明，各篇自己交代就夠。

那三個主題的共同點只到觀察為止：跟它們最相關的學院課都只有文字材料。這裡不往下推論知識類型，因為最順的那個推論不成立。順的推論是「判斷標準沒有可以對答案的形式，所以進不了以作業與考試為骨架的課程」，而 MIT 的 6.005 Software Construction 直接否證它——大綱涵蓋規格、測試、抽象資料型別、物件導向設計模式、並行與函數式程式設計，跟這個書單的設計判斷標準主題重疊得最多，而它在 OpenCourseWare 上放的資源是考題、考題解答、習題與程式作業，判斷標準出得了題也評得了分。它缺的只有影片，成因與知識類型無關：課程的 FAQ 自陳刻意不把課堂時間花在講課上，改成課前讀、課堂做練習，於是沒有可錄的講課。

更廣的反例在同一所學校：Sloan 的 15.401 Finance Theory I（2008）與 15.S50 Poker Theory and Analytics（2015）都有完整的 lecture videos，可見同院同期的判斷型題材拍得出來。所以能說的只有結果——照這一輪的門檻，這三個主題沒有可收的公開課——而成因逐篇不同，寫在各篇自己的收錄段。這裡要跟「沒有影音路徑」分開：驗證那一篇後來查出符合它主題的影音內容存在，只是落在 TDD 與 craftsmanship 這些關鍵字底下、且多數是頻道與部落格而不是成套的公開課，因此過不了收錄門檻而不是不存在。軟體管理與組織書單把同一件事分成三類成因（見 主題書單的公開課段），這個書單對得上其中兩類：設計判斷標準是「學院有課、只是沒有影片」，驗證是「市場供給充足而形態不對，成套公開課以外另有影音路徑」；改既有的程式對不上任何一類，那正是這裡不往下推論的部分。

學院以外、由市場提供的課程供給充足，而它們問的問題不同。以軟體測試或軟體工程為題的公開課數量不少，2026 年 8 月這一輪查到的多半是職涯訓練與面試準備，它們交付的是怎麼當一個測試工程師；驗證那一篇要交付的是幾本立場書彼此不同意在哪。驗證那個主題因此不是被本質恆定那一條擋下來的——它是搜到的那些課與該主題不在同一層，逐篇的說明在各篇自己的收錄段。

中文側的落差落在更前面一段。台大開放式課程的 程式設計（孔令傑，資訊管理學系，15 講，C++）教的是寫得出程式，課程頁自陳不預設任何程式背景，目標是讓學生之後能自學任何一種語言；這個書單的四本起點書都預設讀者已經寫過一陣子程式，所以這門課排在這個書單的入口之前，不在書單裡。程式經驗還沒建立起來的讀者從那裡開始，YouTube 播放清單 有全部 15 講。

工程技藝書單跟教學系列的邊界

書單給選讀判斷，實作在教學系列：各語言的寫法與慣例看 Python、Go、Flutter，測試分層與 mock 判斷看 Testing 測試策略，領域模型的切法看 DDD 領域驅動設計指南。