有個女人在街上賣食物。兩年了。她補貨、付供應商、餵孩子、明天出現。不富有，也不掙扎。在進步
有人告訴她她需要一個正規系統。庫存追蹤。需求預測。忠誠度計劃。她的朋友們在做這些。她在學校學到了這些。嚴肅的企業都這樣做。所以她開始設置。花時間和錢把它弄對。
半年起她仍在街頭。系統安裝在她手機上，一點沒動。設立成本讓她的利潤變得更薄。她本應用忠誠度計劃留住顧客，但那些顧客沒有智能手機.
她並非因為粗心失敗。她為一個尚未存在的商業版本建立了業務，幾乎毀掉了那個正在運作的商業。
沒有人警告你這個陷阱，因為它看起來不像一個陷阱。它看起來像野心。它看起來像把事情做對。
她從未停過來問自己這些是否對她現在有用。標準說嚴肅的企業會這樣做，她的朋友們也在做，她就這樣跟進。這個建議在理論上沒錯。但對她來說，今天，在這個情況下，它是錯的。
她從未問過的問題：
這是為今天存在的商業服務，還是為尚未到來的版本服務？
她的商業有一個版本，其中庫存追蹤完全合理。二十家供應商，三個地點，一個正確的供應鏈。那個版本需要系統。
那個版本還沒有實現。
當前她需要知道今天哪些商品銷售得暢，明天哪些商品需要補貨，這週她賺了多少錢。一個筆記本就能解決這個問題。她不需要一個系統。她只需要活得足夠長，直到需要一個系統為止。
軟體是同樣的問題，只是穿上了不同的外衣。
你得到一個專案、一個截止日期、一個客戶。在你寫下一行字之前，你已經在做出關於架構、標準、專業人士看起來怎樣的決定。大多數這些決定都是自動發生的，基於你被教導的內容和你同儕正在做的事。
DRY。SOLID。全面測試覆蓋。有時候這正是正確的做法。
但有時你只有30天、一位開發者，而客戶需要這個東西90%能從頭到尾正常運作。然後你已經花了五小時在一個抽象概念上，如果有三百萬人使用你的伺服器，這個抽象概念就會很重要。你有三百個使用者。他們中的一半是你自己的團隊.
那五小時並沒有浪費在糟糕的程式碼上。它們花費在一個尚未存在的問題上.
這不是反對標準的論點。
有些標準從一開始就承重。建造任何嚴肅涉及金錢的東西，任何有合規要求的東西，任何一個錯誤號碼就意味著某人的房租無法到賬 — 在這裡，測試、審計、正確的錯誤處理不是可選的。你遵守它們是因為在那個特定系統中失敗的成本，而不是因為教科書上說了什麼。
那就是區別。有些標準是支撐這件事的。其他的則是為了尚未存在的系統版本。
第一種類別無論截止日期如何都不會動。第二種則會被擱置，而你必須對此保持誠實。
供應商的錯誤不是沒有考慮未來。她的錯誤是在當前尚未穩定之前就開始為其建設。
這裡有一個運算順序很重要。
這東西今天能運作嗎？它能賺錢、提供價值、承受它現在所承受的重量嗎？
那之後，它需要什麼才能生存到下一個版本？
絕大多數人會反過來做。他們在第一個真實用戶出現之前，就開始為第三版做架構設計。產品最終會死在所建構的版本和出現的版本之間的縫隙裡.
在我開始任何事之前，有兩個問題.
這個需要今天就能運作嗎？不是為了規模。不是在六個月後。今天，用這些用戶，這個截止日期，這個團隊。
這裡失敗實際上花費了什麼？ 這是一個錯誤的號碼會毀掉某人的財務和信任的系統嗎？還是這個系統中，一個錯誤在下次推送中得到了修復，而沒有人因此失眠？
這些答案告訴我哪些標準是不可協商的，而哪些需要延後。延後，而不是被忽略。被忽略意味著你忘了。延後意味著你做出了有意識的決定，你知道後來會付出什麼代價。
程式碼就是將答案變為現實。
那個女人仍在街上。系統仍在她的手機裡。某處有一個開發者已花了六小時在一個抽象概念上，為一個有三百名用戶的程式碼基礎設施，他們在疑惑為何截止日期感覺不可能。
同樣的問題。錯誤的版本。
我是 Damola，一名後端工程師。在 GitHub 上找到這系列的其餘部分。。請在Dev.to上追蹤我，以獲取下一則資訊。