-
微服務架構 - 從狀態圖來驅動 API 的設計
這次我直接破題了。我想寫一篇從 State Machine 的分析為主軸，來驅動整個服務的 API 設計的文章。
圖片來源: https://www.giga.de/artikel/was-ist-eine-api-schnell-erklaert/
“我們服務的 API 設計很糟糕，怎樣才能設計出好的 API? 有沒有一些 SOP 或是準則可以給我參考?”
其實這個問題我已經被問到爛了，答案當然是 “沒有” 啊 XDDD, 如果有的話，這個問題根本就不會是個難題，也不會有這 FAQ 了。首先，API 的好壞，”設計” 占了九成以上啊! 設計問題是沒有正確答案的，既然是設計，就是帶有個人風格的，你會發現有些大師的設計就是既精準又靈活，看的到背後的巧思，每個環節都搭配的恰到好處，找不出一絲多餘的設計。指南 (Guideline) 通常是告訴你該做什麼，不該做什麼。它可以讓你設計出及格的 API，但是沒辦法讓你設計出理想的 API。要達到這個境界 (我也還不夠格) 需要依靠的是對 domain 更精準的掌握…。
先定義一下，何謂 “好” 的 API? 我很看重 API 設計上的一致性。API 必須顧及很多層面，例如你要端出那些功能? 這些功能是否都用一樣的視角來設計? (主詞會不會一直變動?) 背後處理的邏輯是否一致? (某個 API 不准你取得的資訊，另一個 API 卻又可以?) 你能否在呼叫前就很明確的知道能不能這樣用? (還是任何大小事都要查文件才能搞懂?)
其實這些細節都很煩人啊! 這些都是很多不同面向的考量，我們在實作時同個面向的問題往往都能很一致的處理，不同面向的一致性往往就因為背後的實作階段不同，就很容易被忽略。因此我蠻重視在設計階段就先想辦法對齊這些不同面向的問題。我的作法是，通通都在狀態圖上面把這些 API 設計的要素標示出來，在同一張圖上面思考，就很容易在設計階段解決一致性問題。
-
[架構師的修練] #2, SLO - 如何確保服務水準?
繼上一篇文章: 刻意練習 - 打好基礎 講完整個我對技術人員職涯要持續成長，就必須要刻意的持續練習看法後，這篇我就來舉實際的案例吧。這篇案例是示範，當你學習了技術與管理的知識之後，如何融會貫通，運用在解決問題上的案例。你累積的經驗或是能力，若無法轉換為價值，那是沒有用的。技術人能展現的價值，就是解決問題。怎樣才能讓一個問題拿到你面前你都能迎刃而解? 最有用的就是連結你累積的各種能力。連結越強，織起來的知識網就越強韌，你看問題就會越到位。
這篇我就拿我在去年 91APP TechDay 以及 .NET Conf 2020 分享的主題: 維持非同步系統的 SLO 來當例子吧。這是近年來我擔任架構師，端出來的幾個 solution 之中，對於 “連結” 這件事最有代表性的案例了。這是個包含開發技術，架構設計，服務水準與流程管理等等層面的綜合需求。要解決這問題，你不但要有很札實的技術及實作能力、也要有很到位的 cloud infrastructure 掌控能力，同時還要具備管理知識，缺一不可，才有可能把這件事情解的漂亮。表面上看來，訂定服務水準要達成的目標 (SLO, Service Level Objective) 並落實，是個很純粹的技術題目啊，但是真正做過的人就知道，光是開規格就不知道該怎麼開了，團隊做出來你也很難驗證 (直到上線後碰到流量撐不住之後… )。
-
[架構師的修練] #1, 刻意練習 - 打好基礎
我在下半年的幾場公開演講，開始做了一點不同的嘗試。除了技術或是架構知識之外，我開始會強調為什麼會這樣思考的過程，也開始會帶到該怎麼培養這樣的經驗與能力的想法。在 2020 下半年，有幾場演講都往這個方向調整了。2020 下半年是個爆忙的半年，到現在終於有點力氣把這些內容整理一下了，於是就開了這系列文章 - 刻意練習。這篇是第一篇，主要就是對應到 2020/08 我在 Study4.Dev 八月份活動上分享的主題 - 後端工程師的修練之路。
-
[架構師觀點] 資安沒有捷徑，請從根本做起!
最近一連串資安事件，加上這兩天看到圈子內很熱門的討論串 (大意: 服務開發商，到底該不該儲存能還原的使用者密碼)，於是就想來寫點短篇一點的，說明一下我對軟體開發相關資安 issue 的看法。
那個討論串，我就不提供連結了。我的目的不是要把那位仁兄抓出來鞭，我只是要來聊聊這事件背後的看法而已。如果有人在底下留言附上 link, 我看到會刪掉的，先在此告知
其實我要談的，不是密碼該怎麼加密儲存 (encrypt)，或是只儲存加鹽後的雜湊 (salt + hash) 這些技術問題，我想探討的是技術決策或架構設計者的原則跟態度問題。在軟體開發團隊內 (尤其是技術決策者)，應該都要有正確的認知，不只是密碼儲存，而是泛指所有資安相關議題。如果你只把資安問題當作一種 “需求規格” 來看待，而非品質要求或是法規要求的話，一旦出事時真的會讓公司陷入困境的。
-
架構面試題 #4 - 抽象化設計；折扣規則的設計機制 (06/25 補完)
最近看到好幾篇有內容的討論串，都提到 “抽象化思考” 是個很關鍵的能力。我就在想 “什麼才是正確的抽象化思考” 案例? 看了很多講理論的文章，也看了很多定義, 我相信很多人還是一樣有看沒有懂，或是你真的理解抽象化的概念了，但是真正應用在工作上，你也不一定用的到位啊! 於是就有了寫這篇文章的念頭。我一樣不喜歡只講 “理論”，理論說的容易，要落實才是最難的那一步，因此我決定拿個實際上工作相關的案例來說明 “抽象化” 概念。
我就拿我在 面試架構師常問的問題 之一: “折扣機制的設計方式” 當作這篇文章的主題吧! 只要做過銷售網站，或是相關的系統，我相信一定都被這個主題弄得牙癢癢的，你想的再週全，你的客戶就是有辦法想出你意料不到的折扣規則來折磨你…。不過，這是個很好的例子啊，正好拿來驗證你的抽象化思考夠不夠到位。該說是職業病嗎? 從開始學寫 code 後，我就習慣在日常生活中，碰到大小事情，我都會在腦袋裡想一下 “這東西我該怎麼寫 code 來處理?” …，就是這個折扣計算的問題，每次我在收銀機等結帳時就在想:
這個第二件六折的折扣我該怎麼去計算?
這個第二件加一元我該怎麼設定才合理?
這個即期品半價優惠的機制我該怎麼設計，POS 機才能搞的定?
這麼多種折扣混在一起，結帳時怎麼用一致的規則來處理才不會算錯?
這些問題我就這樣，在我腦袋裡面轉過好幾次了 XDD (所以一時之間想不出來的朋友們不用難過)。我就用這篇文章的篇幅來說明一下該如何將這問題抽象化，然後一步一步解決現在跟未來的問題。
