-
替你的應用程式加上智慧! 談 LLM 的應用程式開發
圖片來源: DALL-E, 這篇都是過年期間的研究心得, 就用龍(年) + 未來都市當主題吧
上一篇文章 架構師觀點 - 開發人員該如何看待 AI 帶來的改變?，展示了我嘗試的 安德魯小舖 GPTs 整合應用，實現了讓 AI 助理的嘗試，我開始真的可以用自然語言就完成整個購買流程的操作了。過程中，AI 也幫我 “腦補” 了部分我 API 沒有提供的功能 (指定預算跟購買條件，AI 自動幫我思考購買組合)。這結果其實比我預期的還理想，完成之後，我開始探索接下來的這兩個問題:
- 未來的應用程式，會怎麼運用 “AI” ?
- 未來軟體開發的流程與角色，會變成甚麼樣貌?
因此，這篇我就要面向應用程式的開發面，來探討該怎樣把 “智慧” (我暫時把 “智慧” 解讀為能理解語意的能力，拿 LLM / Large Language Model / 大型語言模型 當作代表) 加到你的應用程式內。雖然目前 LLM 還有很多缺點，但是應該開始把 LLM 當作 “人” 來看待了，溝通的方式都要把它當作 “人” 的方式溝通 (因此要善用 prompt, 而不是 function + parameters)。這其實跟傳統的軟體開發結構完全不同，也是我這篇想繼續往下挖的主題。
-
[架構師觀點] 開發人員該如何看待 AI 帶來的改變?
(圖片來源: DALL-E, 不過我參不透 AI 想表達啥 XDD)九年前 (2016)，寫過一篇文章: .NET 開發人員該如何看待 Open Source Solutions?，當時會想寫這篇的動機很單純，那是個 Microsoft 新 CEO 剛上任, 策略大幅改變的年代, 所以我寫了這篇文章來說明我的看法。
到了 2023, 整個軟體資訊業，都被 AI 翻了一輪，Microsoft 大舉跟進 AI 相關應用與服務，我覺得另一個軟體開發領域的大改變來了。我去年本來也打算再寫一篇，無奈當時還是個 AI 的門外漢，應該寫不出什麼東西.. 不過累積了一年，加上最近想通了一些事情，就有了這一篇文章。
在開始講我的看法前，第一段就先來看看我的 PoC 吧，我自己刻了線上商店的 API，很單純的瀏覽商品、加入購物車、結帳這些動作。這 PoC 的重點在於，我想打造了一個 安德魯小舖 GPT 的應用專案，看看 GPTs 能否完全代替店員，讓我用聊天的方式完成整個購物的過程。
這篇文章後面我的心得，跟我想表達的觀點，都可以從這個簡單的 PoC 得到驗證。想看我到底做了什麼 PoC 的，就繼續往下看；想直接看觀點的可以跳到 第二段 開始。
-
架構面試題 #5: Re-Order Messages
好久沒有來練習解題的技巧了，這次來聊個有趣的題目:
如果我透過 API 短時間收到大量的 Request, 我如何保證訊息必須按照順序處理?
順序問題，我常碰到的是都不分青紅皂白的就丟到 Message Queue, 結果塞進去的順序就已經不對了，才來問我順序該怎麼辦, 我只能雙手一攤說我也沒轍啊 XDD! 如果你沒辦法一開始就用對的順序放進 Message Queue，你就必須自己面對這問題了。這篇我就是想來聊聊，當 “必要” 時，你會如何處理這種問題?
當年在學網路通訊時，TCP 跟 UPD 的差異就是會處理封包順序 & 重送問題，也剛好讀過背後的作法，你懂原理後就會有機會自己解決。類似例子其實很多，QoS 的應用也是，先前研究過的 微服務基礎建設: 斷路器 #1, 服務負載的控制 那篇，你懂 QoS 怎麼做 Rate Limit，必要時你就能自己解決商業需求。
-
架構師觀點 - API Design Workshop
最近這陣子，我對外分享的主題，其實都集中在 “API First” 身上。碰到一些朋友給我的 feedback, 我覺得挺有趣，我挑一個，放在這篇實做篇的最前面:
Andrew 你談的技巧 (例如: 狀態機, 認證授權, API 開發與測試) 其實我都懂，但是為何你能把這些技巧串再一起? 用這方法來開 API Spec, 我連想都沒想過，而且外面也沒多少人是像你這樣組合起來用的… blah blah (以下省略閒聊的 800 字)
是啊，這老兄講得沒錯啊，這的確是我自己的經驗談。我擅長的就是只靠幾樣精通的基本功夫，善加利用組合，就能拿來面對許多未知的問題。先前一篇聊職涯發展的文章，我就談到 “知識的連結”，這就是我展現出來的應用。當你每一項技巧都熟練到某種程度以上，你就有自由變化的能力了。能夠達到這種層次的技能不用太多，但是你只要多掌握一個，你能應付的範圍就是別人的好幾倍。我拿來應用在 API First 這主題，就是其中一個案例。
API 的成功與否，規格定的好不好 (這是設計議題) 占了 70% 以上，規格定對了，後面的實做 (效能，可靠度等等) 做得好才有加分。而 API 的規格怎麼定，講白了很吃設計者的經驗。前陣子 FB 都在分享一篇 “一流工程師可以用很簡單的方法解決問題”，這情境套用在 API 的設計上再洽當也不過了。你如果能看透 API 背後要解決的問題，開出適合的介面，並且用恰到好處的技術跟工具把她實現出來，這就是個成功的 API。對我而言，我的手法就是 OOP，如何用物件導向的想法去分析 API 背後要處理的問題，然後把物件的介面 (interface) 翻譯成 API 的規格。
因此，正文開始之前，我就加一段在正式演講都沒有談到的內容: 物件導向的思考方式 吧!
-
架構師觀點 - API First 的開發策略
這篇的內容，是我在 DevOpsDays Taipei 2022 的 Keynote 演講的主題: DevOps 潮流下的 API First 開發策略。這場次的內容，正好是我近期正在努力的方向，演講的時間有限，沒能 100% 表達我想講的內容，於是我還是用我最習慣的方式: 文章，重新來闡述一次這個主題吧。
API First, 講的是在你的開發流程內，API 應該被擺在第一順位思考的開發策略。一開始就瞄準 API 為主軸的開發方式，你會發現整個流程跟思考方式都不一樣了，這就是我這篇想要傳達的主軸。我在第一部分先花了點篇幅，說明 API 為什麼應該要 “First” 的理由。API 是很講究事前的規劃與設計啊，有時候會讓人有跟 DevOps 闡述 “先交付價值，尋求回饋持續改善” 的快速循環有所衝突的錯覺。這並非是你要做出二擇一的選擇，而是在持續改善的循環中，有沒有掌握好長期的目標的差別；而 API 的設計往往就是容易被忽略的一環。
因此我多準備了一段: 就是 “架構師在敏捷團隊中該扮演的角色”，這是我在演講當下沒時間聊到的段落，我在文章內也把他補上了! 同樣的內容，除了 DevOpsDays Taipei 2022 Keynote (2022/09/16) 之外，我事後也跟保哥進行了一場同主題的線上直播 (2022/10/07)，相關連結我擺在文章最後面。你可以選擇你想要的方式來了解，不過我個人是最推薦看我部落格文章啦 :D
