這就是一家初創企業當初為了走捷徑而到最后不得不重新編寫代碼的情況，其面臨的技術債務達到難以承受的程度。
但是，如果你在初創企業擔任技術職務，就會知道避免技術債務并不像聽起來那么容易。
初創企業通常有很多發展里程碑需要在很短的時間內完成。在人員和預算有限的情況下，初創企業為了開發最小可行產品有時需要走捷徑，雖然他們知道將來必須進行一些重構。
但適度實施很重要。當初創企業背負技術債務時，就像爬山一樣，必須先爬過這座山才能繼續前進，初創企業只有先背負一些技術債務然后才能擴大規模。企業現在節省的工程時間都必須得到償還，通常還要償還利息。許多從事過嚴重技術債務項目的開發人員都有這樣的故事：曾在幾個龐大而雜亂的代碼庫中工作過，在那里進行了一次重大重構，花費的時間比預期的要長，然后在完成之前將資源轉移其他項目上。其最終結果是構建了一個更大、更混亂、更難理解的代碼庫!
換句話說，當技術債務變得過重時，即使有很多資源可以解決這個問題，修復它也會變得非常棘手。對于初創企業來說，最好的方法是避免承擔任何不必要的技術債務，所以需要了解一下初創企業可以做的六件事，以盡量減少或消除在擴大之前必須償還的技術債務。
1.不要承擔不需要的債務
這個建議聽起來很簡單，但真正實施可能具有挑戰性。初創企業需要承擔什么債務并不總是很明顯。一家初創企業在早期幾乎總是需要做出一些妥協，但隨著工具和技術的變化和發展，可能很難弄清楚真正需要做出哪些妥協。
例如創建事務數據庫。一家初創企業在幾年前不得不做出一個艱難的決定，而且不可避免地涉及妥協：是否選擇能夠快速輕松地擴展并處理潛在的一致性問題但成本更高的NoSQL數據庫?或者選擇像PostgreSQL這樣可靠、簡單且免費的開發人員現在可以使用的東西，但將來可能難以擴展?
這些都不是理想的選擇，采用NoSQL方法可能會帶來一系列令人不快的后續問題。但采用Postgres方法也承擔了一種技術債務，因為以后必須人工擴展。正如初創教育機構Kami公司在新冠疫情期間所面臨的那樣，擴展Postgres可能會很痛苦。該公司的一位代表表示，“我們知道留在Postgres并設置分片會有多復雜，管理多個數據分片會有一個持續的阻力。我們團隊中沒有人愿意完成這種工具，使我們設置了分片，也無法將業務增長10倍。”
不過，如今只需選擇正確的堆棧，就可以避免承擔大量技術債務——盡管什么構成“正確”在很大程度上取決于企業正在構建的內容以及已經熟悉的內容。然而，在任何一種情況下，初創企業都必須妥協進行選擇。
當然，事務數據庫只是技術堆棧的一部分，但現在幾乎每一層都存在類似的解決方案。例如，應用程序的業務邏輯可以遷移到基于云計算的無服務器服務，例如AWS Lambda、Google Cloud Functions或Azure Serverless Functions，從而實現幾乎無限的可擴展性，而無需在前期投入大量的時間或費用。
因此，對于初創企業來說，了解他們的選擇至關重要。由于有了新工具，像Kami這樣的公司被迫做出的妥協現在可能完全避免。特別是，無服務器產品在整個堆棧中的激增使初創企業有可能擴展規模。這反過來又使他們能夠避免使用難以擴展的技術而承擔的技術債務，只是因為它們是獲得最小可行產品的最便宜和最快的方式。
初創企業團隊現在可以使用無服務器選項進行構建，這些選項既免費又容易獲得最小可行產品，同時還提供云原生自動化規模，以保持成本最小化和應用程序性能一致，無論應用程序是處理360個并發用戶還是36萬個并發用戶。
因此，初創企業在早期階段避免技術債務，有時是一種讓其時刻保持警惕并了解所有選擇的功能。不到一年前，還沒有免費的、無服務器分布式SQL數據庫的選擇，而現在已經有了。了解這些選項可以幫助企業避免承擔技術債務，并避免妥協。
2.盡量減少運維工作
在初創企業發展的早期階段，開發人員身兼多職是很常見的。例如，初創企業的開發人員通常會在運營方面擔負雙重職責，直到公司規模大到能夠雇傭專門的IT運營人員。
但啟動開發時間表往往很短，企業的發展路線圖上有很多功能，而且需要快速周轉。開發人員花在運維工作上的時間其實都是應該花費在構建應用程序上的時間，而且他們構建的時間越少，可能不得不削減一些功能以在最后期限交付。而每一次偷工減料都是一小部分技術債務。
出于這個原因，選擇托管服務有時可能是一種最經濟的選擇，即使這意味著要承擔更高的前期成本。初創企業可能并不愿意通過托管來節省成本，因為必須自己開發，但重要的是要考慮讓開發人員了解和管理運營相關的成本。
這一成本超出了開發人員在開展運維工作時浪費的開發時間。選擇托管服務將運維工作交到第三方專業人士手中，他們通常會提供優先的技術支持以促進集成，這可能意味著更順暢的集成過程、更好的應用程序性能以及在出現運維問題時更快地解決。
3.保持靈活性
當初創企業做出設計選擇或選擇以后難以改變的服務時，可能會在不知情的情況下承擔技術債務。
雖然有很多這樣的例子，但最常見的例子之一是初創企業鎖定在單個云平臺的生態系統中。在一開始這樣做通常有令人信服的理由，因為當將AWS Lambda功能連接到其他AWS云服務(如Aurora、ElastiCache或Redshift)時，可以利用其提供的功能。
但從長遠來看，如果谷歌云平臺或微軟Azure成為更實惠的選擇呢?或者，如果意識到為用戶提供最可靠的服務將需要使用多云怎么辦?突然之間，一筆巨大的技術債務到期，初創企業的團隊將不得不弄清楚如何處理，例如將其僅限AWS云平臺的數據庫遷移到可以支持AWS和谷歌云平臺的數據庫，從而避免引發一系列其他問題。
只要有可能，選擇設計和工具以保持靈活性是值得的。有時這需要權衡利弊，但在其他時候，只需選擇不同的工具即可獲得相同的性能和更高的靈活性。因此，即使選擇的功能仍然在AWS云平臺上構建和部署，擁有一個與云計算無關的數據庫也可以靈活地切換到另一個云平臺或在未來采用多云，而無需更改數據庫。
4.不要解決已經解決的問題
作為工程師，不要嘗試解決別人已經解決的問題。雖然不斷改進的動力是許多技術創新背后的動力，但創業公司要想獲得成功，就必須與實踐相結合。雖然定制解決方案可能是完美的，但也有可用的第三方解決方案，可以在不花費開發人員時間的情況下提供99%的功能。
例如，Starburst公司提供的一個數據分析引擎為客戶的數據提供一個單一并且快速的訪問點。為了確保為客戶提供更好的性能，Starburst公司需要構建一個多區域關系數據庫。該公司當然可以嘗試構建一個定制的解決方案。但正如Starburst公司工程副總裁Ken Pickering所說：“當一個工程團隊已經建立了一個可靠的解決方案時，我為什么要讓工程團隊嘗試解決多區域問題?我們需要對第三方技術解決方案做出明智的選擇。因為我們需要為客戶的數據負責。”
對于大多數初創企業來說也是如此，即使還沒有為客戶要求所困擾，也需要做出明智的選擇來保護其開發人員的時間。
為了快速發展和成長，初創企業需要專注于解決他們的團隊需要解決的核心問題。如果開發人員偏離正軌，轉而構建定制解決方案，那么他們的時間將非常緊迫，以至于他們在開發產品的核心功能時不得不偷工減料。那么這就成為企業最終必須償還的技術債務。
5.盡早建立編碼最佳實踐
雖然人們關注的是使用為技術堆棧選擇的解決方案來避免技術債務的更宏觀的方法，但很多技術都可以追溯到草率編寫代碼，這通常是因為時間匆忙。
如果企業的目標是為避免技術債務，那么重要的是確保從第一天開始就實施并遵循編碼最佳實踐，但這應該包括可重復的、形式化的系統。雖然開發人員都知道這一點，但當初創企業的開發團隊只有幾個人(甚至只有一個人)時，這些都是很難做到的。當交付截止日期快到的時候，很容易決定不需要評測或記錄代碼，但是每次跳過類似的步驟時，都會增加技術債務，而這些技術債務總有一天要償還。
當然，開發人員是否有時間遵循所有這些最佳實踐并不總是掌握在他們手中。在通常情況下，開發時間表是從自上而下傳遞。
6.立足當下，展望未來
避免技術債務的真正關鍵是善于平衡當前的需求和未來的目標。實際上，這樣做具有挑戰性，需要將以上討論過的所有內容結合起來，并將這些知識帶到關于企業目標和時間表的更廣泛的討論中。
例如，如果初創企業的首席執行官設定了開發期限，如果不承擔某種形式的技術債務，就很難達到這一目標，那么技術人員需要能夠確定并傳達這些權衡，以便將其納入預算和規劃中。如果首席執行官希望在本季度發布兩個主要功能，那么很可能只能發布一個功能，因為下個季度將會處理技術債務，可能花費大量時間和精力處理客戶支持問題和重構有缺陷的代碼。
在平衡有限的時間、技能和預算的同時嘗試優化以獲得最佳結果是一項真正的挑戰。但是建立一家初創企業并不容易，也不可能完全避免技術債務，尤其是在創業初期。但是，如果可以在堆棧中做出正確的選擇，并構建良好的內部護欄，以避免走捷徑或解決不需要解決的問題，那么初創企業可以確信自己走上了正確的道路。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號