雜談

前言 本篇算是整理下目前自己對 API 的理解，算是雜談性質，就記錄一下吧。 什麼是 API (Application Program Interface) ? 從文義解釋開始 從文義解釋來看，API 的基本定義是：軟體之間溝通的介面，允許不同系統有規範地交換資料。API 規範了如何向服務提出請求、需要的資料格式，以及回傳結果的形式。 然而文義解釋總是過於抽象，我們還是舉例來說明會比較清楚。在介紹何謂 API 時，最常聽到，會用餐廳點餐來比喻，我這裡也不免俗地用這個方式來說明。 餐廳的例子 Image Source Credit: Celeste Layne - Medium.com 你是餐廳的顧客，菜單代表「服務可以提供那些資料、功能」。當你向服務生點餐（發送請求），服務生將你的請求帶給廚房（資源所在，也就是後端系統）。廚房根據菜單和你的選擇（麵要加大不要辣）的選擇製作食物（處理請求）。最後，服務生把餐點（回應）端給你。 在這個比喻中，服務生就像 API，客戶端（顧客）不直接與後端（資料、邏輯、資源）打交道，而是透過 API 這個介面來溝通下單和取得結果，省去彼此理解內部細節的麻煩。 但是，工具的目的是為了解決問題，重要的不是工具本身，而是背後要解決的那個問題。因此我們要進一步思考的是，如果沒有 API，會如何？ 軟體之間就必須「直接訪問」彼此的資料或功能，彼此須了解對方的內部細節，如同點菜時顧客沒有按照制式的菜單點餐，廚房根本不知道怎麼出菜，最後本人必須進廚房了解每一道手續，如此一來餐廳根本無法運作。但若真的讓顧客直接進餐廳，如此，就會缺乏安全隔離，外部程式可以隨意取得資料，使系統變得脆弱，就像顧客可能將病原體帶入廚房，污染食材。同時，維護上若有需要調整，將會修改困難，比方說內部實作細節更改，取用者要如何取得資料，必須重新理解取用過程。 舉例來說，如果沒有 API，你開發一個 App，需要取得 google 地圖的資料、處理金流等功能時，你得直接接觸這些系統的底層，理解提供服務者的內部結構才能夠拿到你想要的東西。 訂購人的困境 OK，現在每一家餐廳都有自己的菜單與訂購單，解決了廚房的溝通問題。這解決了單一廚房點餐的問題，基本上只要看得懂上面菜單的文字，就可以知道這張單要出甚麼內容。我們有了 API 了！ 但若場景變成：要對多個餐廳要同時下單，你是訂便當股長，就會遇到要對應不同便當店，要看懂每家的菜單格式，還要想辦法看懂各位同事自由格式的信件內容，也就是你要適應不同格式，結果就是增加了溝通成本。 例如上圖，每間餐廳的菜單風格迥異。 開發人員的困境 回到開發場景。來做個系統吧，資訊人員一定會幫我們解決這個問題，降低便當股長的離職率。但資訊人員遇到了問題，那就是他要去串接的每個店家，他的訂購單格式都不一樣，此時面對了一些抉擇： 鍛鍊資訊人員，所有店家都客製作下去，但這可能會提高資訊人員離職率。 訓練資訊人員的溝通能力，配合專案經理，以及外部合作商，談訂一個共同的規格。 很遺憾的，上面那兩個選項，偉大的老闆選了項目 1，為了不影響其他合作商，所以決定讓自己的工程師處理。 如果每個合作對象（例如不同餐廳）都用自己的格式來傳遞資料，資訊人員（工程師）就必須針對每一種格式，開發不同的「解析」方法。舉例來說： 有的店家用 Word 檔案下訂單，有的用 Excel，有的用 PDF，有的直接寄圖片，有的用網頁表單。工程師就要寫很多不同的程式，來讀取和理解這些不同的檔案格式。 如果店家改變了檔案格式（例如 Word 從 2003 版換成 2007 版），工程師的程式就可能失效，要重新修改。 有的 Excel 檔案可能被植入病毒，還要擔心安全問題。 如果是圖片，還要用影像辨識技術來「看懂」圖片內容，萬一圖片字體換了，辨識又會出錯。 ...

前言 今天重新打開 Algomonster 時，點開了之前沒特別注意的 Getting Started 章節。其中一句話讓我停下來反覆思考： At AlgoMonster, we love systems. We are big believers in systems over goals. – 在 AlgoMonster，我們熱愛系統。我們堅信系統比目標更重要。 這句話讓我產生好奇：「系統比目標更重要（systems over goals.）」這是什麼意思？點進連結後，發現是漫畫家 Scott Adams 的部落格文章1，內容來自他的一本書《How to Fail at Almost Everything and Still Win Big》2。這裡整理出我讀完後的理解與想法。 目標（Goals） Scott Adams 指出，目標是「限制性的 (limiting)」。如果你只專注於一個特定的目標，雖然達成它的機率可能比沒有目標時高，但你可能會「錯過可能遠比你的目標更好的機會」 (miss out on opportunities that might have been far better than your goal)」。 舉例來說， 減重多少公斤：這類目標很常見，但實際上很難持之以恆（我自己也經歷過）。 每週去健身房三到四次：這也是一個目標，對於不喜歡運動的人來說可能感覺像懲罰，導致最終因為感到痛苦而放棄。 系統 (Systems) 而 Scott Adams 認為，「系統」旨在將你從低勝算的情況轉移到高勝算的情況 (move you from a game with low odds to a game with better odds)。 透過系統，你不太可能因為過於專注於一個機會而錯過另一個 (less likely to miss one opportunity because you were too focused on another)，並且總是在掃描任何機會 (always scanning for any opportunity)。 ...

前言 曾經在各大平台（如 Medium、Vocus、Substack 等）嘗試發表文章，但最後還是覺得將內容放在自己的 GitHub Pages 最合適。平時的知識整理會以 Obsidian 為主，想公開分享的內容則會發布在這裡。既然這是第一篇文章，就以我的轉職簡短心得作為開場，希望對有類似想法的朋友有所幫助。 如標題所述，我的本科專業是法律，並在取得法學碩士及律師執照後做了幾年訴訟律師，每天的生活就是： 與當事人開會 研究法律問題 寫訴狀 到法院開庭 以上四點無限迴圈。 對，我忘了說一點：「法院等開庭」。 這件事情有什麼特別的？嗯，任何事情都有可能 delay，法院開庭當然也不例外，有時候比較誇張會等 30 分鐘到 1 小時都有可能。 我喜歡律師工作。我喜歡分析案情，研究法律問題，找出可以用的法律見解並應用在案件上。但律師工作性質以及我個人特質的雙重影響下，讓我不僅是在精神上或物理上，很難將工作與生活分開~時間久了身體也漸漸開始出狀況，所以我一直有在思考我有沒有更多其他可能。 在一段職涯空檔中，我慢慢回想自己的過去。 我從小學一年級就開始接觸電腦，直到現在我都是光華商場的常客，朋友、家人之間負責修電腦的工具人XD 吸收法律知識和科技知識，對我來說都很有成就感。不同的是，前者多半是出於專業需求，而後者則多了一份純粹的興奮與熱情。 會發現這點，是因為我在律師工作時，深刻體會到這行業極度依賴紙本作業。但我習慣把資料電子化，所以會把所有文書掃描成電子卷宗，這樣查找資料既方便又快速，開庭時翻資料也不會輸人。 後來我開始思考，能不能再進一步改善這件事。當時就想過，或許可以開發一個系統，讓員工能用來管理案件，客戶也能登入查詢自己案件的進度。只是那時還沒開始學寫程式，這個想法就暫時擱在心裡。 身邊不少朋友都是軟體工程師，而我本來就對電腦、程式這類東西很有興趣，長期下來也算耳濡目染。離開事務所後有了比較多自己的時間，就買了 Python 的書和線上課程，開始認真學習。學著學著發現，其實程式和法律有不少相似之處，所以上手還算順利，越學也越有興趣，還能用程式幫朋友、家人解決一些問題。 在實作過程中我發現，比起一直看課程，動手做的學習效率和成就感都更高。於是我開始開發前面提到的那個事務所系統。這段開發經歷，讓我更確定自己真的熱愛寫程式，覺得這就是我想做的事。 後來進入找工作階段，很幸運錄取了 AppWorks School 的 iOS Training Program，結業後也順利進入媒合的公司工作。 坦白說，現在回頭看，轉職這個決定確實有點任性和衝動，畢竟算是完全打掉重練。不過既然已經踏上這條路，未來會在這裡持續更新技術文章，有機會也會聊聊法律相關的話題XD