史戴拉寫扣

上週 這篇 一同理解了為什麼需要複雜度分析之後，本篇我們將一起透過 LeetCode 題目，逐步分析時間複雜度，看看不同複雜度在演算法實戰中的應用情境。

在學習或撰寫演算法程式時，會遇到一個問題是:「我怎麼知道這段程式碼快不快?」。直覺上的做法，或許就是直接把「程式跑起來，然後計時」，但這個方法其實隱藏了陷阱，因為「秒數」本身並不一定能公平反映程式效率。

你有想過三角形為什麼是「兩邊和大於第三邊」嗎?

還記得 上篇 我們用「用狗狗冒險遊戲🐶」理解類別和物件嗎?

• 類別(Class) = 狗狗角色模板
• 建構子(Constructor) = 狗狗初始能力值
• 物件(Object) = 玩家的狗狗角色

來到進階篇，我們要解鎖 OOP 的四大核心機制: 繼承、封裝、多型、抽象。

還在被物件導向搞得頭昏腦脹嗎？🤯
「什麼是類別？什麼是物件？」

2025年6月16日，Y Combinator CEO Garry Tan 與 Sam Altman 在 AI Startup School 展開一場深度對話，以下是我整理的重點摘要。

用了一陣子的 GitHub Copilot 的「自動產生提交訊息」功能後(大腦外包給AI 😆)，不過有時還是想要手動微調提交訊息，所以想要了解所有的提交類型，以便可以微調提交訊息。

最近在開發 WordPress 外掛時，遇到一個經常重複的流程:

本地開發 → 手動打包 → 上傳到WordPress → 測試 → 修bug → 再打包…

每次修改都要花 3-5 分鐘手動打包、上傳、測試，一天重複 10 次，就是將近 1 小時。不是在寫程式，而只是在搬檔案。這些時間累積起來…是什麼?是再也回不來的青春歲月!(你說這時間拿來盯著bug看體悟無常也不錯)。而這就是為什麼需要 CI/CD，一個持續整合與部署的自動化流程。

身為一個在 AI 浪潮下學習程式設計的開發者，我的 Coding 心態與方法，經歷了一段有趣的進化。從最初對 AI 的驚嘆，到追求產出品質的穩定，最終走向系統化的架構思維。我將這段歷程歸納為三個階段，稱之為「Vibe Coding 進化史」。

這題是 LeetCode 上的 SQL 題目 197. Rising Temperature，任務是:

找出氣溫比「昨天」更高的日期紀錄。