Spirit
55 位追蹤者
Spirit
55 位追蹤者
在業界打滾多年，本來想開發遊戲，想想還是打遊戲比開發遊戲輕鬆，曾想當敏捷傳教士，但後來發現，好的產品品質跟健全心態的團隊比用什麼流派重要，所以，這幾年比較隨心所欲，但不隨波逐流，仍想做出值得驕傲的好產品。
這是從 Medium 開始的一個專題，主要是想用輕鬆閒談的方式，分享這幾年軟體開發的心得，原本比較侷限於軟體架構，但這幾年的文章不僅限於架構，也聊不少流程相關的心得，所以趁換平台，順勢換成閒談軟體設計。
全部內容
由新到舊
分享瞭如何在新系統中應用樂觀鎖，透過 version 欄位簡化併發控制，同時保持高吞吐量。文章也觸及了樂觀鎖的進階應用及注意事項，並總結了兩種鎖機制的適用場景，為開發者提供實用的選擇指南。
現今的系統不論是 B to B、B to C 或是 B to B to C，通知都是不可少，不管是簡訊發送 OTP，還是發送臨時密碼的 email，或各式各樣的 push 通知，通知已不可少的環節，這也是為什麼在一開始系統架構設計時，早早把 ncc 規劃成一個獨立模組 (子系統)。
本文深入探討了 UUID 的演進，介紹了 UUID v6 和 v7 相較於舊版本在時間排序上的顯著提升，以及 ULID 作為另一種優化 ID 設計的替代方案。技術是不斷進化的，定期檢視是必要的。
分享自身團隊在 Cloudflare 當機時，如何透過事先規劃的備援機制，在極短時間內將服務切換至 GCP Cloud DNS 並恢復正常運作的經驗。文章深入探討備援設計的複雜性，涵蓋成本、同步、複雜度及演練等面向，並總結事後檢討，強調建置外部監控系統和自動化 SSL 憑證更新的重要性。
本文探討後端 API 安全驗證機制，說明如何基於請求憑證進行身家調查，確保只有授權使用者才能存取資源。文中詳細闡述了資料採信原則、角色來源、組織層級的設計考量，並介紹簡單的實作範例，以確保系統安全。
本文探討如何使用函數式風格聲明 Javalin API endpoint 的安全性需求，並透過組合函數，例如 any 和 all，以及自定義函數，例如 anyManager 和 anyOwner，來簡化複雜的權限檢查。此方法避免了使用註解的繁瑣，並提高了程式碼的可讀性和可維護性。
從Spring Boot轉換到Javalin的過程與考量，以及如何保持核心業務邏輯與Web框架的距離以提升專案彈性。文中比較了Micronaut, Helidon和Javalin三個輕量級框架，並說明選擇Javalin的原因及優缺點。
日誌設計包含幾個重要考量因素，包括關聯式查詢、雲端生態支援、情境豐富性、結構化日誌以及與商業邏輯核心保持距離。利用 correlation ID、ThreadLocal 以及自定義抽象物件，實現了這些需求，並簡潔地說明在不同任務發動情況下 (API請求、定時執行、事件驅動) 的使用
本書大多數的內容都以 OO 的概念出發，詳列了許多設計的臭味道，也有大量的例子。個人雖然不會這樣寫程式，但仍是覺得受益良多，至少在 code review 時能更清楚知道該怎麼描述問題。不過，即便不是用 OO 的概念，有些章節還是可以帶來一些想法，用 OO 概念寫程式的人更不該錯過這本好書。
5/5設計重構
實際就業後，會發現收集與分析需求，通常都不是工程師在做，會有另一群人，以非工程的角度收集及分析需求，然後在開發過程中蹦出不同的火花，於是很好奇另一群人的想法是什麼？我不敢說這本書能完全代表另一群人的想法，但確實能夠得到很多有用的思維。推薦給所有的軟體工程師。
4/5從需求到設計
