系列文章的內容在昨天就結束了，今天主要寫寫參賽的心得。

在這系列的文章裡，我們簡單認識了 Spring 框架裡面的幾個核心組件，並嘗試用它們構建出 Spring 在啟動時的各種細節。就像之前說的，寫文的目的主要是整理一些自己這段時間蒐集到、整理到、消化到的資訊。以結果而言，大方向的結果是有達成的！雖然在一些細節的把控上有點沒做好，但整體而言還是可以打上一個及格的分數，再來可以聊聊這 30 天寫下來針對文章品質、取捨的東西、和參賽的心情跟感想。

• 品質

首先是心態的問題：系列開篇之前，自己大概屯了 25 篇左右的文章，雖然不到完稿，但至少在 Spring MVC 環節之前的文章草稿都是有的。因此開篇前幾天的心態都在還算愉悅的階段，早上起來先貼個文章，同時修修字、潤潤稿、加點粗斜、加點圖片，盡可能讓文章在視覺上可以相互搭配，不會有講了很多東西，但因為沒有圖片輔助所以有些東西對不起來的感覺。

但大概在 10-15 天之後，這樣的餘裕逐漸消失，一方面是後來發現這樣調整佔據了早起後的大量時間，會壓縮到原本在早晨舊有的一些既定規劃，因此不得不件少潤稿的時長；另一方面，大概在九月底左右身邊也開始出現一些預期以外的事件，為了能解決那些事情，我也不得不擠出一些多餘的時間把它們整頓好。這一來一往間接造就了 15 天左右之後的文章開始沒有圖片的輔助、也沒有比較細緻的分段跟潤稿。

直到大概第 25 天？原先屯好的文章已經被消化完了，加上上段說到的突發事件，使得原先預期的後續寫文 + 持續潤稿計畫沒有辦法如期運行，最後呈現出來的狀況，就是 Spring MVC 後段和 Spring Boot 篇章的粗糙內容了。整體而言，這算是我在這系列裡面覺得最可惜的事情，如果後續有持續雕琢的打算，第一步就會從這邊開始，然後慢慢把原本的期待給重現出來。

• 取捨

再來講講文章的規劃。最一開始的計畫，其實是打算以 IoC 容器作為開篇的組件介紹，然後往下講 Bean 工廠、Bean Definition、跟其他的組件細節 ...等。但那時候大概寫了 5 篇文章後發現，有很多段落都必須要有「這部分的內容後續會再提及，先有個概念或粗略的認識就好」這類的文字，後來想想這樣應該很影響閱讀上的體感，所以最後才上下翻轉，先從 BD 開始說起，然後延伸到 BD 的相關組件、工廠、容器 ...等。

但無論是哪種語序，容器核心篇、AOP、Spring MVC 的那幾個組件都是在一開始規畫的時候就打算放上來的。Spring Boot 原本只打算寫 SpringApplication 和 WebServerFactory，但後來考慮到組件的數量跟其他兩個（Spring 原生、Spring MVC）比起來實在是太少，所以才決定加上 Condition 相關的內容，和 SPI 在 Spring Boot 上的相關應用（Auto-Configuration-Import-Selector）。

Part 2 的容器基礎設施篇，是考慮到 MVC 篇章的架構是講了 Dispatcher-Servlet，也講了它的相關依賴與構成。所以就想能不能用同樣的格式仿造在 IoC 容器上而誕生的篇章。然後組件進行到這裡，大概有了 25-26 篇左右的草搞，剩下的問題就是最後的 2-3 篇要放什麼內容。

以結果而言，最後被加進去的組件是 CCPP, Import-Selector, 和 Filter 這三篇。CCPP 的原因很單純，因為它是「加了註解的 Java 類別怎麼被掃描成一個 BD」的重要推手，講了它就可以把 Java 到 IoC 容器的橋樑給搭建起來；Import-Selector 則是 SPI 機制的核心，考慮到 MVC 篇和 Boot 篇有很多基於 SPI 的應用，也把它給放進來了；Filter 則是單純因為用得多。它是這系列文章裡唯一不與 Spring 框架強掛鉤的 Java 類別，但因為很常用，所以也放進來了。

至於取捨掉的組件，Handler-Method-Argument-Resolver 絕對是一顆閃亮的遺珠。「參數是怎麼被綁定到 DTO 裡」這個問題可以說是我最開始會接觸底層核心的契機之一，但後續因為篇幅的原因，加上我的步調是「盡可能多講點核心組件，MVC 跟 Boot 講個大方向就好」就沒有被放進來了，是我覺得很可惜的一個地方，然後用同樣理由沒捨棄掉的還有 Binder，它也是一個我覺得在 MVC 裡面很重要的組件。

除此之外，Conversion-Service, Spring-Factories-Loader, Response-Body-Advice 這幾個組件也曾在考慮之內，尤其是 Spring-Factories-Loader，當初有專門設計一天的文章內容，是在比較 2.x 和 3.x Spring Boot 的底層差異，就會連帶講到一些 SPI 機制、Class-Loader 的相關改動，但後來發現內容可能有點太刁鑽了，加上大多數的人可能不是很在意這種不常用的細節，後面就停滯了。

• 心態

最後聊聊參賽的態度和心情。這次是我人生中定二次參加鐵人賽，第一次參賽是在大學的時候，莫約 6-7 年前有寫過一次設計模式的系列文章，但後來因為意志力的原因沒有成功完賽，加上學校帳號後來被停用了，這次才會開一個新帳號來挑戰。這次也因為是團體參賽，因此多了一個「必須要完賽」的責任在裡面。很謝謝這次陪我一同參賽的 Mike 跟 Alley，如果沒有跟他們成立團體組，可能我這一次又會在 25 天左右就棄賽了吧？最後有完賽真的是太好了。

此外，無論是參賽期間，還是現在的完賽期間，整體的心情都是很愉悅的。一方面很高興自己達成了之前沒有完成的里程碑、一方面讓更多的人懂了 Java Spring 的啟動原理、一方面也多了一個可以在履歷上添增的項目、也很開心自己還是可以疏裡大量的文字跟觀念，認真來說的話，這次的參賽經驗有點像是以前寫碩論的那種感覺，大量考證、大量實驗、然後大量寫文、再經歷大量的修改，最後端出一個沒有完全滿意，但仍可接受的成品。

• 感想

整體而言，承接這次的團體組的成員介紹，我自己是 0% 的人腦派，當然啦，說 0% 絕對是浮誇了，還是要老實說我有用 AI 做到一些文字上的修改或潤飾，但絕大多數的內容仍是我自己手打出來的，因此我相信這裡的文章讀起來的「人味」還是比較多的。但我也相信像我這類的人往後可能會越來越少，畢竟效率的指標就擺在那邊，因此後續要考慮跟鑽研的，應該就是怎麼用 AI 寫出有高品質的文章跟程式了。

最後，還是再次感謝這次團體組的同伴 Alley 和 Mike，就像上面說的，沒有他們我的完賽之路會再坎坷跟陡峭許多；同時也感謝這次的鐵人賽舞台，讓我有一個可以嘗試展現的舞台；也感謝幫我閱讀草稿的一些朋友們，這裡的人數有點多就不詳列了；最後感謝讀到這裡的你，讀者永遠都是寫文的最大動機，如果沒有你們，我相信我最後也不會有完賽的動力的。

期待後續各位的閱讀與分享，我是 Pax，我們下次見。