我最近開通了我的 GitHub 帳號，並篩選了私有倉庫。我實際統計了一下：總共有 27 個在過去三年建立但已被廢棄的業餘專案。
我開發過一個基於機器學習的習慣追蹤器，一個狗狗版的 Twitter，還有一個複雜的 SaaS 樣板專案，我花了四個星期配置，最後還是徹底放棄了。有些專案我甚至花了幾個星期，其中一個我還專門買了網域。
數百小時白白浪費。為什麼他們都還沒見到天日就死了？不是因為時間不夠，也不是因為缺乏動力。
以下是可能引發爭議的真相：
大多數開發者失敗並非因為缺乏技能，而是因為他們內心深處更享受啟動新專案時帶來的多巴胺快感，而不是完成專案時的艱辛付出。
以下是導致我 27 個專案失敗的確切模式，以及最終幫助我打破這個循環的規則。
1. 「完美堆疊」陷阱
身為開發者，我們都喜歡嶄新的工具。啟動一個專案時，我們首先想到的就是嘗試推特上大家都在熱議的新資料庫，或是框架的最新測試版。
我曾經花了一個週末的時間配置一個基於 Next.js 的應用，包括 tRPC、Prisma 和一個自訂的 Tailwind 設計系統。到了周日晚上，我的基礎架構已經完美無缺。但我一個業務邏輯都沒寫。第二天，我就徹底失去了興趣。
如果你想真正完成一個專案，就必須使用那些看似枯燥的技術。選擇你最熟悉的技術棧，即使它感覺有些過時。
2. 針對虛擬用戶進行最佳化
為了搭建這個狗狗版的推特，我花了三天時間搭建了一個複雜的Redis快取層。我當時非常擔心，如果第一天就有100萬隻狗註冊，伺服器會不會崩潰。
我們喜歡過度設計。我們擔心資料庫如何應對海量流量，所以設計了複雜的微服務。但殘酷的現實是：
你最大的威脅不是伺服器崩潰，而是沒人會造訪你的網站。
不要為尚未出現的問題開發功能。一個簡單的資料庫查詢就足夠了。等應用程式真正獲得用戶後，你再進行最佳化也不遲。
3. 功能蔓延是一種疾病
一切都始於一個看似無害的想法。你正在建立一個簡單的待辦事項清單，然後突然想到：「如果用戶可以上傳自訂頭像就好了。」結果，你花了五個小時閱讀 AWS S3 文件，而不是完成核心任務邏輯。
設想各種功能固然令人興奮，但實現起來卻十分繁瑣。每增加一個按鈕，就會拖延產品發布。完成專案的最佳方法是毫不留情地精簡功能，直到最終得到絕對最小可行產品（MVP）。如果某個功能無法解決核心問題，那就必須刪除。
4. 對運輸的恐懼
編寫程式碼是安全的。你的 VS Code 編輯器不會評判你。但發布專案意味著真人可能會看到它，發現 bug，或者更糟——完全忽略它。
很多業餘專案在完成度達到90%時就被放棄了，因為開發者內心深處害怕按下部署按鈕。我們總是用「還需要再完善一下」來搪塞。
一個存在漏洞、介面醜陋但已上線執行的應用程式，其價值遠高於一個完美但僅存在於本地主機上的應用程式。
48小時法則
為了打破這個魔咒，我為自己定了一條嚴格的新規矩：我必須在 48 小時內推出一個功能齊全但外形醜陋的原型。
如果核心功能上線需要超過一個週末的時間，那就表示專案規模太大了。這種簡單的思維轉變是我最終開始發布真正有價值的應用，而不是開發一堆毫無用處的應用程式的主要原因之一。
接下來該你了
我知道我不是唯一一個在 GitHub 上存放著大量已失效創意的人。
說實話：你曾經啟動過的最奇怪的、最終被放棄的副業專案是什麼？你停止開發的真正原因是什麼？
請在留言區告訴我，你的墓園裡都埋什麼？
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
