System Design, Actually
Understanding the essence of System Design, and how you could learn it systematically.
Introduction
在經歷過 2023 ~ 2024 的 Tech Layoff，現今軟體就業市場的 要求變的十分的高。
而 System Design Interview (系統設計面試)，由於他能涵蓋的深度與廣度十分充足，也逐漸成為公認能鑑定 senior engineer 的標準。
在此篇文章，筆者會試著探討對於現今 Jr/New Grad 「System Design 學習障礙」 的觀察，網路上的學習資源有哪些優劣。
最後，提出一個幾個筆者認為能讓學習 system design 事半功倍的 mindset，並希望最終能說服你 System Design 就等同 Problem Solving，和 之所以 System Design 會難，是因為多數人都沒把 Problem Solving 學好。
System Design Interview Propaganda
作為 Jr, New Grad, or 想增進架構能力的人，初次會接觸的教材諸如：
但當讀者試著參考、依賴以上的素材去學時，多少會發現一些怪味道 (待會會提到)
我們採用 System Design Interview: A Step-By-Step Guide 的幾個敘述，來試著傳達問題在哪：
相對於上列的套路。筆者認為以下的哲學，才是實務和學習時，看待系統設計比較實際的方式：
遠離 Grand Design (一眼定奪、天才且直覺產生的架構設計)，偏好 逐步發展解法
偏好從 功能性需求 (functional requirement) 作為設計的開頭，再逐漸納入 非功能性需求 (non-functional requirement) 和 Constraints (系統的 tradeoff, 取捨)
非功能性需求 (non-functional requirement) 的實現，必須要能基於 Telemetry 和 Profiling (效能量測) 的事實，並且 深刻理解 Infrastructure 背後的實作。
Interview-Style System Design, 會帶來什麼問題？
❌ 選擇追求 Grand Design
如果在系統設計實務、學習時，實作者只專注在 快速、立即的提出 HLD，而非逐步的發展解法。
這會導致實作者最終的設計提案，及學習的過程，都產生 「去脈絡化」 的成果。而這會導致：
對學習者，Grand Design 的思維陷阱，會讓人傾向去背答案/不求甚解，並且學到與實務 problem solving 相反的推導過程。
而對於架構師而言，追求一個 One-off, Clever 的 Grand Design，恰好踩中了 Who Needs an Architect? 這篇文中所描述的 anti-pattern：Architectus Reloadus
Architectus Reloadus
這樣的架構師，傾向在初期規劃就提出一個完備、複雜、又聰明的系統設計。
此舉會導致其他專案成員難以參透和證偽諸多的初期決策。最終使整個系統更難在未來有效的融入新的功能/非功能性考量。
❌ 忽略功能性需求 (functional requirement)
在 System Design Interview: A Step-By-Step Guide 的宣揚中，營造了一個幻想：
認為軟體行業內的 Staff/Architect Software Engineer，全都是腦中只關注 Hard Skills, Non-functional Requirement 一群人。
但今天在任何型態的軟體公司中，去與團隊內的 Staff/Architect 訪談。筆者會發現，Staff/Architect 的實際模樣，和上述的幻想是完全相悖的。
每個能被 promote 到 Staff/Architect 的工程師，在商業策略、宏觀的產品理解、使用情境上，全都比一般的工程師有過之而無不及。
Why is Functional Requirement Important?
在任何的軟體公司的開發上，產品都是從 MVP (最小可行產品)，逐步的發展到一個成熟的盈利功能。這也與架構的演進相互應。
並且一個軟體產品在本質上能帶來使用者價值與獲利，功能性需求是佔了絕大多數的貢獻。
在任何的產品開發路徑上，架構很大程度都是從 功能性需求 的 「分析」、「開發」、「驗證」、「擴充」 來實現的。
因此，在任何場景的系統、架構設計中，從滿足功能性需求的路徑，去逐步納入效能、穩定性上的考量。才能確保架構師們不 over-design，也設計得精準。
❌ 忽略 Profiling 與 Benchmarking
諸如 QPS/Bandwidth 的非功能性需求，在實務上都不是能夠輕易的去做出 dare assumption 的。
多數時候，都得從使用者情境、Telemetry (系統遙測) 得到的效能觀察、作出假設與實驗，才能知道架構的預期與解法該往怎麼方向發展。
而這才是實務上分析與理解 non-functional requirement 的標準解決流程。
結語：如何克服 「System Design 學習障礙」
在此文中，描述了網路上的 System Design 學習資源，以及常見的 認知誤區 會如何讓 System Design 的學習事倍功半。
而克服 System Design 這門知識混亂的學問，筆者認為可以從兩個方向進行主題式的學習。
Software Architecture
軟體設計/架構這們學問，本質上探討的問題就是 「從一群需求中，如何能發展出一個模型來陳述要實現的功能」，掌握他能讓軟體工程師對功能性需求的實現有更全盤性的理解。
以下的幾個主題，及 Architecture, Actually 有提供數個學習方向：
Domain Driven Design
OOAD (Object-Oriented Analysis and Design)
Clean Architecture
讀者的練習目標該放在 能做出精準、系統性的做出 Feature Modeling，並能高效的草稿出滿足所有功能性需求的 design MVP。
System Programming
幾乎所有的 非功能性需求 (non-functional requirement)，在電腦科學的 Distributed Systems、Parallel Computing、Operating System 都有所琢磨。
因此，針對效能、穩定性、一致性等問題的解法，學習者可以將眼光放在熟讀以上的經典電腦科學知識。
並以此延伸，透過自己實作經典的系統元件 (如 Redis, Load Balance, BTree)，來熟知元件真正的效能瓶頸，解法和如何量測。(RCS.103 就是希望能編排出能滿足以上能力的練習)
Last updated
