通往地獄的道路充滿了良好的願望。希望您可以從我們的錯誤中學習並發現為什麼在開始下一個專案時應該考慮極簡主義。

在Spaceship，Voyager應用程式後端的第一個迭代很大程度上依賴於Kafka。我們的意圖是崇高的：建立一個應用程式，隨著我們的客戶群的增長，該應用程式將具有可稽核性，穩定性和長期負擔。

最終採取Kafka是一個相當簡單的過程，但最終複雜化。Voyager的真正內心在於投資體系，其中大多數與成員之間沒有直接互動。只需註冊Voyager，就不必為極重的負載建立系統。團隊很小，時間表很雄心勃勃，而且第一次釋出產品時就不需要額外的開銷。在大多數情況下，當您需要處理大量請求時，無論如何您已經重寫了事情。有一個好問題；這意味著您正在成功。

當時可能沒有考慮的其他問題是基礎架構的成本，更重要的是維護和支援的成本。

花時間掌握新技術

每種技術都有自己的處理方式。有一種“正確”的方法。如果您的團隊中沒有已經擁有新技術經驗的成員，那麼，您遲早會夢想著正確重寫它。

即使您確實有團隊成員花費大量時間來使用這項技術，也可能需要一些時間才能使其他成員開始使用。有時必須進行切換，但要讓整個團隊團結起來，討論您為什麼要切換，並確保出於所有正確的原因進行切換。另外，請確保您不想太快地新增太多新技術。

聘請新工程師時，簡單的應用程式變得更快，更容易。

使用簡單易用的技術棧，該技術棧在行業中很普遍，這意味著您可以讓新的團隊成員加入團隊，並且比複雜的設定要快得多。通常，學習公司的業務領域需要花費足夠長的時間。通過技術堆疊增加額外的複雜性意味著團隊的整體產出減少的時間將超過必要的時間。在一家初創公司中，如果營業額很高，而您正試圖快速成長，那真的可以加起來。

易於支援

在支援生產應用程式時，除錯問題在最佳情況下通常很困難。當應用程式很複雜時，這可能會導致支援問題增加。

一個常見的問題是團隊中只有一個人知道應用程式的工作方式並最終一直支援該應用程式。如果工程師休假，生病或離開公司，而其他人都不知道該怎麼辦，那麼這種知識孤島最終可能會傷害到團隊。對於支援該應用程式的人員來說，這也可能很無聊，導致企業失去一支優秀的團隊成員，因為他們希望從事新工作。

另一個問題是，除錯問題可能需要更長的時間，這可能會使不滿意的客戶受益。尤其是當您是新手時，您需要做的最後一件事就是讓客戶感到沮喪，留下不好的評論或對他們的朋友說壞話。

易於新增和修改

與最初的開發一樣，一個更簡單的應用程式可以更快地新增修復，更新和新功能。有時，過於複雜的舊版應用程式會將所有更新放入“太難”的籃子中。

我們如何解決

快速的答案是我們轉向使用帶有protobuf模式的gPRC微服務。卡夫卡被完全被砍掉。解釋我們如何做到這一點又是另一回事，但它花了很多時間進行規劃，並且花了三到四個星期的時間。幸運的是，我們有時間來照顧我們所謂的大量技術債務。

好處是可觀的。上崗時間減少了，人們可以快速啟動並執行該技術，並且可以通過與支援工程師一起進行工作的前一兩個星期進行標記，從而學習業務領域。可以在整個團隊中輪流提供支援，因為任何人只要對編碼有一點了解，並且能夠搜尋日誌至少可以跟蹤問題的根源。支援SLA的時間已大大減少，並且支援的輪換限制了知識孤島和無聊，因為您知道您會花時間回到有趣的東西上。哦，我是否提到我們將伺服器數量減少了約50％？

每個公司都有自己要解決的問題，有時需要複雜的技術。只要確保技術能夠解決問題而不是解決問題即可。更少的程式碼，更少的錯誤。