本文探討「第一性原理思考」與「站在巨人肩膀上」兩種思維模式在程式開發中的應用與平衡。作者分析這兩種看似對立的方法如何互補：一種鼓勵從基本原理重新構建解決方案，另一種則倡導善用既有工具。文章以 Web 開發實例說明，優秀程式設計師應靈活運用兩種思維，依據不同情境動態切換，在創新與效率間取得平衡。
前陣子在聽 Podcast「請聽，哈佛管理學」中的"S2#24-3 行銷大撒幣，轉單卻卡關？掌握「存量」與「增量」雙增長的品牌策略，讓顧客主動幫你「一傳千里」！Ft. 汪志謙｜哈佛人物面對面"，其中提到了「第一性原理思考」這個概念，讓我產生了興趣。
Google 了幾篇文章了解後，突然意識到：「第一性原理思考」似乎與我們在學習過程中常聽到的「站在巨人的肩膀上」、「不要重複發明輪子」這些建議形成某種對比，甚至可能有些矛盾。一個鼓勵我們回歸基本重新思考，另一個則勸我們善用前人智慧。
作為一個程式設計師，這引發了我對這兩種思維方式的好奇：它們到底有什麼不同？哪種更適合軟體開發？是否可能融合使用？
第一性原理（First Principles）源自物理學，指的是那些不能再被簡化的基本前提或假設。採用第一性原理思考，就是將問題拆解到最基本的元素，然後從這些元素重新構建解決方案，而非依賴現有的模式或類比。
作為程式設計師，第一性原理思考表現為：
老實說，在講求快速迭代的開發環境中，這種追根究底的思考模式看起來簡直是天方夜譚。「專案下週就要上線了，你還想研究底層原理？」——我彷彿已經聽到 PM 的咆哮聲。
但有趣的是，「重新發明輪子」這件事在實際開發中其實時常發生。多少次我在面對特定需求時，先是去搜尋現有套件，結果發現它們為了滿足各種使用場景而變得異常複雜，不僅效能堪憂，連理解文檔都要花上半天。這時，從需求的本質出發，寫一個小巧精準的解決方案反而更高效。
這讓我想起大學時期的計算機概論課，老師要求我們自己寫一個簡易的程式編譯器作為期末專案。當時我想：「這不是已經有現成的編譯器了嗎？為什麼要重複發明輪子？」現在看來，那正是一次很好的第一性原理思考訓練。只有真正理解了編譯原理，才能在需要時靈活運用或改進它。
「站在巨人的肩膀上」這一概念源自牛頓爵士的謙遜之言：「如果說我看得比別人更遠，那是因為我站在巨人的肩膀上。」它強調了知識的累積性和繼承性。
這種思維方式在開發中體現為：
想象一下，如果每次開發網站都要從設計 HTTP 協議和 TCP/IP 開始，那現代 Web 世界恐怕還停留在九十年代。正是因為我們可以站在各種前後端框架、容器技術的肩膀上，才能以驚人的速度構建複雜的應用。
表面上看，這兩種思維方式確實存在張力：一個鼓勵從零思考，一個建議善用現成工具。但仔細想想，它們真的不能共存嗎？
真正的創新智慧往往來自於這兩種思維的動態平衡：
以我最近的一個項目為例，我們需要開發一個數據可視化儀表板：
結果証明，這種混合方法不僅節省了開發時間，還讓成品在功能上擁有了獨特性。
我認為，優秀的程式設計師不應該將第一性原理思考和站在巨人肩膀上視為非此即彼的選擇，而是應該靈活運用這兩種思維工具：
在現實的軟體開發中，我逐漸學會了這種平衡之道：對於基礎架構和通用功能，我毫不猶豫地利用成熟框架；而對於核心業務邏輯和關鍵性能瓶頸，我願意花時間回歸問題本質，重新思考最優解法。
或許，軟體工程的真正藝術不在於選擇哪種思維模式，而在於知道何時切換，以及如何將它們融為一體。
後記：寫完這篇文章後，我忍不住想：程式就是生活模式的寫照，那在生活中，有哪些情況也是如此?也許下次有機會再寫，是乖寶寶該睡覺的時間了