寫到今天完成鐵人30的第一週內容，比起繼續開發下去我比較想要檢討一下前六天的文章

這篇文章沒有程式碼，沒有基礎架設等能推進度的內容

主要會是透過一個後端工程師的角度來review前面六天的內容，會儘量客觀。

然後為了補充內容，最後分享個小東西。

Day1 鐵人賽開場與介紹

開發內容定位清楚不複雜，整體來說沒什麼問題，但沒有提到技術的使用，對自己的背景也沒有描述

可能令人失去興趣，沒有繼續看下去的理由。

針對這個系統的亮點也沒有多加描述，比如這個活動管理系統，亮點應該是週報圖表，跟如何達到「感受到成就感」，但沒有這部分的描述。

還有，前面有一大段在講故事，但這個故事講完除了「想來完成這個我一直想做的東西」 沒有別的結論，也許可以把重點放在「想要做個能感受到成就感的系統」？ 這裡是ITHOME 不是我家客廳，讀者沒有必要在乎為什麼我想要做這個專案。

總結：

沒有寫到讀者為什麼要在乎這系列的文章，寫得像自己的備忘錄。

Day2 MyMomentum 的技術選型與架構

這篇寫了

「打造一個可以輕鬆紀錄、持續使用、不會造成壓力的工具…」

不同於Day1有個「感受到成就感」的主題，Day2重點改成了輕鬆紀錄 不會造成壓力。

其實這個系統最重要的目的，應該是「感受到成就感才對」，會出現這樣前後內容不符的問題，代表作者(我)其實對於這個專案為什麼要存在不是很確定，或者想要簡單了事。

「如果之後有需求，再考慮加入更進階的方案(或重構!?)…」

這段多講的，連我阿罵都知道這系列的文章不會有什麼”考慮加入更進階的方案”

然後這篇有圖片，就跟金城武很帥，我也有穿衣服是同樣道理。

最後一點，這篇的內容不是很多，因為作者也不知道要做什麼，所以內容不多算合理。

總結：

作者對於系統的定位還在茫，整體規劃不完善(但合理，也許變得更強之後可以規畫得更詳細)。

Day3 首頁設計：從使用者流程到前端雛型

這篇在講我設計畫面的過程

其實對於前端的畫面，不用講得太細，重點只要說為什麼這樣設計就好

日常操作流程 可以講得更符合實際使用狀況一點，可能改成用情境來說明，像是什麼小明今天打開APP想要認真工作.... 之類的。

然後”cursor協助開發..." 這段又再陳述了一次我們的前端畫面要有什麼，雖然對作者來說是順順的走，合理。

但對讀者來說，等於同樣的話說了兩次

這天的重點應該只有一個「我如何設計畫面，為什麼？」

也許有些讀者會在意如何實作，但也不要直接show程式碼出來，因為怎麼寫 每個工程師都不一樣

這部分應該帶過就行。

總結：

針對說明，只給讀者他們需要看的東西，不要重複

然後搞清楚該篇文章的重點，怎麼寫可以自由，但想說什麼應該是很明確的。

Day4 PostgreSQL 架設步驟（使用 Docker + Volume）

第一段的結尾「讓我們開始吧」有點唐突，讀者不知道你為什麼要突然介紹Volume 也不知道你為什麼就突然講別的了，要說明的話，先說為什麼要說明。

這篇把資料庫架設完成，應該再補一段測試。

總結：

搞清楚為什麼讀者要知道你寫的內容，如果回答不出來那就乾脆別寫了。

Day5 Activities 與 Records：資料表設計筆記

第一段：目標是先讓前端能打API到後端儲存資料到資料庫 這裡要先說明為什麼目標是這個

然後show圖片的時候可以標註一下目前的畫面上資料都是假的。

後半段產生DDL的部分可以補充是怎麼產生的，如果是請AI生成 就老實說沒關係。

總結：

跟讀者說清楚你現在想幹嘛，跟Day4一樣問題

然後不要怕說你是請AI生的，老實一點。

Day6 後端專案建置與資料庫串接

技術棧終於現身了，遲到總比不到好。

中間針對application.yml 做太多說明了，基本上到這邊還有再看文章的人都不需要學習application.yml怎麼寫。

也許可以改成技術選擇的說明，為什麼選用該技術(例如：為什麼不是純hibernate之類的)

還有這篇有個特別的東西：Swagger

至少對作者本人來說是這樣，那麼就可以針對為什麼要引入swagger做多一點說明

總結：

不要預設讀者看不懂，看不懂就不會看了，反而要預設讀者看得懂，不要寫一些人家覺得太基礎的東西

然後不是說明你懂什麼，反而要針對你比較不熟悉的做更多描寫、說明

這樣才有學習效果。

以上，在丟給chatGPT整理後，後續我需要注意的事情：

• 定位要一致（避免 Day1/Day2 的落差）。
• 系統亮點要提一下（成就感、週報圖表）。
• 解釋為什麼，而不是單純「怎麼做」。
• 避免重複或冗長（Day3、Day1 故事）。
• 圖片/程式碼要有註記（假資料、AI 生成）。
• 不要寫太基礎的內容（application.yml、Service/Repository）。
• 重點放在特別的東西或不熟的地方（Swagger、踩坑經驗）。

檢討完了，之後每七篇會有一篇review專門拿來反省

也麻煩有看到這邊的讀者有什麼建議可以提出，看到很煩也可以罵個兩句，別怕我傷心XD

最後小小分享一下，為什麼專案要導入Swagger

相信很多讀者已經自己問過GPT 或是看過網路文章了，你們可能看到什麼「文件化」、「自動化」「標準化」之類的話

但是我要說，其實沒有那麼高深

原本開發流程是這樣，假設我要開發一個API給前端用，我需要(細節省略)：

開發好API⇒上到測試環境⇒打開postman打打看API確認OK⇒
寫一份文件跟前端說這個API怎麼用、什麼時候用、接收什麼參數、回傳什麼參數等等⇒
打完發現API名稱打錯再打開文件修改⇒跟前端說好了可以串⇒User說這個不行 ⇒ 重來一次

麻煩對吧？ 這個時候用Swagger，流程可以變成

開發好API⇒上到測試環境⇒跟前端說⇒User說不行⇒叫他在Swagger上用用看然後

我拒絕你的要求！

最後你們就可以重新談一次需求，是不是簡單很多?