今天的文章要來回顧上一週寫的內容，然後總結一下心得與要改進的地方
最近真的事情很多，但還是維持更新到了Day16，感恩感恩
接下來就是繼續保持更新，鐵人賽是馬拉松、不是衝刺(加油！)
老實說我認為做登入機制這樣的「技術決策」，事前的 research 應該要再花更多時間，但我這邊參考完 AI 的建議就直接拍板定案了。
畢竟是做 MVP 嘛，我就想說遇到問題再處理，先讓專案的進度動起來，所以應該也算合理？而且時間真的不夠用（找藉口）。
這天的內容回顧下來，我自己覺得亮點是那張流程圖，圖上的分工很清楚，流程也很好懂。
可惜開頭有點太急了，可能可以再加一點敘述，會更容易理解這篇在幹嘛。
還有結尾排版也很隨便，應該是想睡了。
好長！回顧的時候我馬上就懷疑自己能不能讀完這篇，太長了。這麼多內容應該要有個類似大綱的區塊來說明這篇文章會有什麼內容。
像閱讀一本書一樣，可以讓讀者有心理準備，也可以在腦中稍微 process 一下為什麼文章要寫這些內容。可是這篇沒有，直接就進入實作了。
總之這篇有點「難」看，最好是加一點篇幅說明這篇所有實作的步驟，或是在中間加一點喘息區域，分享一兩個笑話之類的。
這篇亮點是幾乎把所有程式都講過一遍。
這一篇的重點就是把 前端拿到的 Google ID Token，交給後端驗證，並簽發我們自己的 JWT。
這篇沒那麼長了，可能因為自己比較常寫後端，看完比較不吃力。但這篇問題跟上一篇一樣：直接就進入實作。下次真的要先說明一下我實作的步驟，以及為什麼要這樣做才行。
個人覺得這篇亮點是 Google ID Token 驗證實作 還有 CORS 安全設定。因為沒有做過 Google 登入的話，肯定不會知道這些細節，也許獨立出來寫一篇比較好。
這篇應該是這系列第一篇，針對我實際開發遇到的問題來寫的文章，而這也是這篇最大的亮點：「從問題出發」。
比起一股腦地一直寫，更有在解決問題、開發功能的感覺。然後也把我的問題，延伸成別人會有的問題。
感覺這篇比起其他篇，更有可能幫到別人解決問題。
不過如果加個圖片，閱讀起來會更輕鬆。
又回到實作了，雖然是我寫的，但我得老實說，我自己不是很喜歡看這種實作的文章，就算看到也會快速滑過。
所以之後這類的實作文章可能要改一下，改成「實作中有碰到什麼比較少見的、特殊的點」拿來講。
像是這篇的 @Transactional(readOnly = true) 就可以單獨寫一篇，篇幅不會太長，但沒關係，文章不是長就有用。
這篇的亮點是 @Transactional(readOnly = true) 以及 @SecurityRequirement(name = "bearerAuth") 這兩段，可惜沒有更多描述。
這篇的亮點是沒有把內容都塞在同一篇，篇幅不會太長，但亮點就這樣而已。
我不是很會描述 UI/UX 怎麼設計的，這點讀者應該看得出來。也許有空可以特別學一下怎麼表達，或是看一下別人 UI/UX 怎麼分享的。
這篇延續前一篇的 UI/UX 設計，有特別針對「設計思路」跟「為什麼」做說明。前一篇的 UI/UX 設計應該就像這篇這樣寫，但不知道讀者那邊有沒有感覺到一件事。
那就是這篇文章，「AI味」，真的很濃。
可以說我針對「不懂如何說明 UI/UX」這個缺點修正得蠻快的，靠 AI 修正。
這篇的亮點是有針對「思路」跟「為什麼」做容易聯想的說明。
終於回顧到最後一篇，現在時間十一點三十四分，文章要來不及了。
這篇不是我遇到的問題，但確實是我開發過程中問過 ChatGPT 的疑問：時間型別到底該用哪個？
我認為分享的內容雖然簡單，但還算實用。
但也許針對程式碼的部分可以多做一些延伸。現在程式碼的範例太簡單了，感覺不出明顯的差異。
後續的文章會儘可能的挑一些自己不會的，或是自己覺得比較可以拿出來講的，而不是完全實作。
持續更新 GOGOGO
iThome鐵人賽
看影片追技術