🔧 阿川の電商水電行
我曾經多年追逐最新潮的東西。到了2026年，我卻押注於最具爭議性的建築風格：簡約。
我以前是一名以簡歷為導向的開發人員。
你肯定見過這種專案。如果一個專案不涉及 Kubernetes、三個不同的雲端服務供應商、訊息佇列，以及上週二才發布的框架，我就沒興趣。
我不是在開發軟體；我是在為自己虛榮心建造一座紀念碑。
結果呢？我的雲端服務帳單比我的食品雜貨帳單還高，而且我甚至需要一張地圖才能找到我的用戶密碼儲存在哪裡。
現在已經是2026年了。炒作週期令人疲憊不堪。
人工智慧工具產生程式碼的速度比我們除錯的速度還快。複雜性正在淹沒我們。
所以，今年我要做一個徹底的改變。我押寶在「枯燥堆疊」上。
這就是我摒棄複雜性的原因，也是你可能也應該這樣做的原因。
你不是谷歌（我也不是）。
我們被謊言蒙蔽了。我們看著 Netflix 和 Uber，心想：“他們用微服務，所以我的待辦事項應用程式也應該用微服務。”
但我們忘了他們有2000名工程師。而我只有我自己、一個咖啡杯和一個截止日期。
當你把應用程式拆分成 10 個小型服務時，你並沒有降低複雜性，只是把複雜性從程式碼轉移到了網路層面。凌晨兩點除錯網路錯誤可不是我理想中的消遣。
今年，我將回歸宏偉的單體架構。一個程式碼庫，一次部署，一個資料庫。如果我想查找 bug，我不需要分散式追蹤——我只需要 Ctrl+F。
我實際使用的技術棧
當其他人都在爭論最新的元框架時，我卻在用這個框架發佈生產程式碼：
運算資源：一台獨立的VPS伺服器。無需冷啟動。沒有隱藏費用。就是一台永不停歇的Linux伺服器。
資料庫:
SQLite 或 Postgres。不需要那些花俏的 NoSQL 文件存儲，也不需要我在應用層進行資料連接。關係型資料就很好。讓 SQL 來完成這些工作。
後端：
標準的 REST API。 GraphQL 很棒，但請求特定欄位並不是我的瓶頸，瓶頸在於複雜性。
前端：
使用 React（因為我熟悉它），無需 50 個額外的庫。
它是否具有可擴展性？
Stack Overflow 和 Shopify 都採用單體架構。除非你打算明天就讓整個巴西的人口都加入進來，否則一個普通的單體架構就足夠了。
枯燥的軟體也能賺錢
身為資深工程師，我最大的感悟是：使用者並不在乎你的技術棧。
他們不在乎你用的是 Rust 還是 Python。他們不在乎你的架構是不是「事件驅動的」。他們只在乎按鈕點擊後是否有效。
選擇枯燥的技術，就能減少配置 Webpack 的時間，把更多精力放在開發功能上。功能帶來客戶，客戶付費。
「完成」的喜悅
使用比團隊裡的實習生年紀還大的工具，會給人特別安心的感覺。
當我使用 SQLite 時，我知道它可靠。它已經在數十億台設備上測試過。它不會因為 npm 更新而崩潰。它就那樣穩定地待在那裡，可靠地保存我的資料，不求任何回報。
所以，到了 2026 年，請繼續使用您的 Kubernetes 叢集和邊緣運算無伺服器函數。
我這邊就用我的單一伺服器和 SQLite 檔案出貨，而你們還在設定 YAML 檔案呢。
你最不想放棄的「枯燥」工具是什麼？請在評論區告訴我。
原文出處：https://dev.to/the_nortern_dev/my-2026-tech-stack-is-boring-as-hell-and-that-is-the-point-20c1
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
