NIH 症候群不一定是壞事#
「非我所創」症候群（Not-Invented-Here Syndrome，NIH）通常被視為一種反模式——工程師因為驕傲或偏見，拒絕使用外部的程式碼和工具，非要自己重寫一份。這個名詞帶有強烈的貶義。但 Joel 認為，在某些情況下，自己動手寫反而是正確的選擇。
什麼時候該自己寫#
Joel 的核心論點是：如果某個元件是你業務的核心，你需要完全理解和掌控它。
核心業務邏輯#
- 如果某個程式碼是你的產品之所以存在的理由，那麼你最好自己寫並擁有每一行程式碼
- 依賴第三方程式碼來實現核心功能，等於把你的命運交到別人手上
- 當第三方程式碼出了問題，你無法快速修復；當你需要某個特殊功能，你無法輕易新增
對程式碼的深度理解#
- 使用自己寫的程式碼，團隊對每一個細節都瞭若指掌
- 出了問題可以立刻定位和修復
- 需要擴展或修改時，不受第三方 API 設計的限制
Joel 在 Fog Creek 的實踐：他們自己寫了許多在市面上已經有現成解決方案的元件，因為這些元件是產品的核心。理解每一行核心程式碼的能力，讓他們在品質和速度上都有優勢。
依賴第三方程式碼的風險#
使用外部程式碼並非沒有代價：
- 版本相依性：當第三方更新版本時，你的產品可能會出問題
- 功能限制：第三方程式碼的設計可能無法完全滿足你的需求，而你無法修改它
- 除錯困難：當問題出在第三方程式碼中，你往往只能等待對方修復，或者花大量時間閱讀不熟悉的原始碼
- 授權風險：第三方的授權條款可能會改變，影響你的產品
- 生態系統風險：第三方可能停止維護、被收購、或改變方向
什麼時候該用現成的方案
Joel 並不是說所有東西都要自己寫。NIH 的合理適用範圍有明確的邊界：
- 非核心功能：如果某個功能不是你的核心業務，使用成熟的第三方方案通常是明智的。例如：你不需要自己寫資料庫引擎（除非你的業務就是做資料庫）
- 通用基礎設施：作業系統、網路協定、加密函式庫——這些不需要自己寫
- 時間壓力下的權衡：有時候用現成方案快速推出產品，比花幾個月自己寫更重要
判斷標準：這個元件是不是你的競爭優勢所在？如果是，自己寫。如果不是，用現成的。
NIH 症候群之所以有壞名聲，是因為很多人把它用在了錯誤的地方——為了非核心功能重新造輪子。但對於核心業務而言，「自己造輪子」不是驕傲，而是專業判斷。
核心原則#
自己寫 vs. 使用第三方，這個決策應該基於策略考量，而非意識形態：
- 核心競爭力 → 自己寫，完全掌控
- 非核心功能 → 使用成熟的第三方方案
- 判斷依據是商業價值，不是技術驕傲或懶惰