想象一下：大約400萬行PHP代碼，由低薪，有時合作不是很順暢的自由職業(yè)者和學(xué)生在8年的時間里編寫。首席執(zhí)行官寫了很大一部分，但他在2004年左右停止了學(xué)習(xí)新技術(shù)。

這就是當一家初創(chuàng)公司不考慮所有這些混亂的捷徑最終都必須清理干凈的情況下運營時，技術(shù)債務(wù)可能會產(chǎn)生的糟糕狀態(tài)。

如果你在一家初創(chuàng)公司擔任技術(shù)角色，你就會知道，避免技術(shù)債務(wù)并不像聽起來那么容易。初創(chuàng)公司通常有很多的開發(fā)里程碑要在很短的時間內(nèi)實現(xiàn)。在人員和預(yù)算有限的情況下，讓一家初創(chuàng)公司獲得 MVP 有時需要走一些捷徑，因為你知道將來必須進行一些重構(gòu)。

但適度很重要。當你承擔技術(shù)債務(wù)時，你正在建造一座山，在你的公司能夠擴大規(guī)模之前，你必須爬上這座山。你現(xiàn)在節(jié)省的所有工程時間都必須償還，通常需要支付利息。許多從事過具有重大技術(shù)債務(wù)項目的開發(fā)人員都有這樣的故事：

我曾在幾個大而雜亂的代碼庫中工作過，在那里我們進行了一次大的重構(gòu)，它花費的時間比預(yù)期的要長，然后在完成之前將資源拉到其他事情上。最終結(jié)果是：一個更大，更混亂，更難理解的代碼庫!

換句話說，當技術(shù)債務(wù)變得太大時，即使你有很多資源來解決這個問題，修復(fù)它也會變得非常棘手。對于初創(chuàng)公司來說，最好的方法是避免承擔任何不必要的技術(shù)債務(wù)，所以讓我們來看看初創(chuàng)公司可以做的六件事，以盡量減少或消除在擴大規(guī)模之前必須償還的技術(shù)債務(wù)。

不要承擔你不需要的債務(wù)

這個建議可能聽起來很合理，但遵循它可能具有挑戰(zhàn)性。你需要什么債務(wù)并不總是很明顯。

建立一家初創(chuàng)公司幾乎總是需要在早期做出一些妥協(xié)，但隨著工具和技術(shù)的變化和發(fā)展，可能很難弄清楚你真正需要做出哪些妥協(xié)。

比如說事務(wù)數(shù)據(jù)庫。就在幾年前，初創(chuàng)公司不得不做出一個艱難的選擇，一個不可避免地涉及妥協(xié)的選擇：你是否會選擇一個能夠快速輕松地擴展的NoSQL數(shù)據(jù)庫，并處理潛在的一致性問題和潛在的更高成本?或者，你是否會選擇像 PostgreSQL 這樣可靠、簡單且免費的數(shù)據(jù)庫，供您的開發(fā)人員使用，但將來可能很難去擴展?

這兩種選擇都不是理想的。NoSQL 方法可能會帶來令人不快的后續(xù)問題，例如臟讀、幻讀、寫入傾斜等。但 Postgres 方法也承擔了一種債務(wù)，因為以后必須手動擴展。正如教育初創(chuàng)公司 Kami 在大流行期間了解到的那樣，擴展 Postgres 可能會很痛苦：

“我們知道在 Postgres中保留和設(shè)置分片會有多復(fù)雜。管理多個數(shù)據(jù)分片會一直拖累我們。我們團隊中沒有人愿意經(jīng)歷那種體力勞動。即使我們設(shè)置了分片，我們也無法將業(yè)務(wù)增長 10 倍。”

在今天，盡管我們可以通過選擇正確的技術(shù)棧去避免承擔大量的技術(shù)債務(wù)。但是什么是“正確的”在很大程度上取決于你正在構(gòu)建的內(nèi)容和你已經(jīng)熟悉的內(nèi)容。在幾乎所有的技術(shù)棧中，不妥協(xié)的選項可以讓初創(chuàng)公司獲得兩全其美的優(yōu)勢。

當然，事務(wù)數(shù)據(jù)庫只是你技術(shù)棧的一部分，現(xiàn)在幾乎每一層都存在類似的解決方案。 例如，你的應(yīng)用程序的業(yè)務(wù)邏輯可以遷移到基于云的無服務(wù)器服務(wù)上面，例如 AWS Lambda、Google Cloud Functions 或 Azure Serverless Functions，從而實現(xiàn)幾乎無限的可擴展性，而無需前期大量的投入時間或金錢。

因此，對于初創(chuàng)公司來說，清楚他們的選擇至關(guān)重要。由于有了新工具，像Kami這樣的公司被迫做出的妥協(xié)現(xiàn)在可能完全可以避免。特別是，整個技術(shù)棧中無服務(wù)器產(chǎn)品的激增使得初創(chuàng)公司能夠在必須為規(guī)模付費之前進行規(guī)模擴展。這反過來又使他們能夠避免承擔使用難以擴展的技術(shù)構(gòu)建的技術(shù)債務(wù)，僅僅因為它們是獲得 MVP 的最便宜和最快的方式。

團隊現(xiàn)在可以使用無服務(wù)器選項進行構(gòu)建，這些選項既免費又容易獲得MVP，同時還提供云原生的自動化擴展，以保持成本最小化和應(yīng)用程序性能一致，無論應(yīng)用程序處理的是 360個并發(fā)用戶還是360，000個并發(fā)用戶。

因此，在初創(chuàng)公司的早期階段避免技術(shù)債務(wù)有時是一種讓你時刻保持警惕并了解所有選擇的課題。不到一年前，還沒有免費的、無服務(wù)器分布式 SQL 數(shù)據(jù)庫的選擇。現(xiàn)在有了。了解這些選項可以幫助您避免承擔技術(shù)債務(wù)并不再做出不需要做出的妥協(xié)。

最小化運維工作

在初創(chuàng)公司的早期階段，開發(fā)人員“戴上一堆帽子”是很常見的。例如，初創(chuàng)公司的開發(fā)人員通常會承擔開發(fā)和運維的雙重職責(zé)，直到公司規(guī)模大到能夠負擔得起專門的IT運維或 DevOps人員。

但是初創(chuàng)公司的開發(fā)時間往往很短。產(chǎn)品路線圖上有很多功能。時間很緊需要快速迭代。任何時候，開發(fā)人員花在運維工作上的時間就是他們沒有花在構(gòu)建應(yīng)用程序上的時間，而且他們構(gòu)建程序的時間越少，他們就越需要偷工減料以趕上他們的截至?xí)r間。每一個偷工減料都是一小部分技術(shù)債務(wù)。

出于這個原因，選擇托管服務(wù)有時可能是經(jīng)濟的選擇，即使這意味著承擔更高的前期成本。你可能并不總是通過托管來節(jié)省資金 - 這是你必須為自己做的計算 - 但重要的是要考慮讓開發(fā)人員了解和管理運營相關(guān)的成本。

該成本超出了開發(fā)人員因為做運維工作時錯過的開發(fā)時間。選擇托管服務(wù)將操作權(quán)交到專家手中，他們通常會提供優(yōu)先的技術(shù)支持以促進集成，這可能意味著更順暢的集成過程，更好的應(yīng)用程序性能，并在出現(xiàn)運維問題時更快地解決它們。

保持靈活性

當你做出設(shè)計選擇或選擇以后難以改變的服務(wù)時，可能會在沒有意識到的情況下承擔技術(shù)債務(wù)。

雖然有很多這樣的例子，但最常見的例子之一是將自己鎖定在單個云的生態(tài)系統(tǒng)中。一開始這樣做通常有令人信服的理由，比如當你將AWS Lambda 函數(shù)連接到其他Amazon 的服務(wù)(如 Aurora、ElastiCache 或 Redshift)時，你可以利用這些服務(wù)所提供的效率優(yōu)勢。

但從長遠來看，如果GCP或Azure成為更實惠的選擇呢?或者，如果你意識到向用戶提供更可靠的服務(wù)將需要多云，該怎么辦?突然之間，一筆巨額債務(wù)到期了，你的團隊將不得不弄清楚如何將其僅限Amazon的數(shù)據(jù)庫遷移到可以支持AWS和GCP而不會引起許多其他問題。

這就是為什么只要有可能，讓設(shè)計和工具選擇保持靈活性是值得的。有時，這需要權(quán)衡，但在其他時候，只需選擇不同的工具，就可以獲得相同的性能，并增加靈活性。因此，即使你的功能仍在 AWS 上構(gòu)建和部署，擁有與云無關(guān)的數(shù)據(jù)庫也可讓你靈活地切換到另一個云或?qū)磉w移到多云，而無需更改數(shù)據(jù)庫。

不要解決已經(jīng)解決的問題

作為工程師，我們總是想嘗試重新發(fā)明輪子。不斷改進的動力是許多創(chuàng)新背后的力量，但對于一家初創(chuàng)公司來說，要想成功，就必須與實用性相結(jié)合。雖然定制的解決方案可能是完美的，但通常有一個即插即用的解決方案可以為你提供 99% 的所需功能，而不會花費你任何開發(fā)時間。

例如，Starburst是一個數(shù)據(jù)分析引擎，為客戶提供了所有數(shù)據(jù)的單一且快速的訪問點。為了確保為客戶提供良好的性能，Starburst 需要一個多區(qū)域關(guān)系數(shù)據(jù)庫。該公司當然可以嘗試構(gòu)建一個定制的解決方案。但正如Starburst工程副總裁Ken Pickering所說：“當有一個工程團隊已經(jīng)建立了一個可靠的解決方案時，我為什么要讓我的工程團隊嘗試解決多區(qū)域問題呢?”

“我們需要做出防御性的、智能的技術(shù)解決方案選擇，”Pickering說，“因為我們要為客戶的數(shù)據(jù)負責(zé)”。對于大多數(shù)初創(chuàng)公司來說也是如此，即使你還沒有為許多客戶所困擾，你需要做出明智的選擇，以保護你的開發(fā)人員的時間。

為了快速成長，初創(chuàng)公司需要專注于解決他們的團隊要解決的核心問題。如果您的開發(fā)人員被轉(zhuǎn)移到為其他人已經(jīng)解決的問題構(gòu)建定制解決方案，那么他們將時間緊迫，以至于他們將不得不偷工減料開發(fā)您產(chǎn)品的核心功能。那是您最終必須償還的技術(shù)債務(wù)。

盡早建立最佳的編碼規(guī)范

雖然我們專注于使用你為你的技術(shù)棧選擇的解決方案來避免技術(shù)債務(wù)，但許多技術(shù)要么源碼回溯困難(通常是因為它編寫時很倉促)，要么技術(shù)文檔混亂(通常也是因為它編寫時很倉促)。

如果您的目標是避免技術(shù)債務(wù)，那么重要的是要確保你從第一天開始實施就遵循編碼最佳規(guī)范或者盡可能接近第一天。我們不會過多地談?wù)撨@些，因為你可能已經(jīng)很清楚它們的重要性，但這應(yīng)該包括可重復(fù)的，格式化的系統(tǒng)，以確保所有代碼都是。

雖然所有開發(fā)人員都知道這一點，但當您的開發(fā)團隊只有幾個人(甚至只是一個人)時，很容易忽略這些最佳規(guī)范。當截止日期即將到來時，你很容易不為你代碼做注釋和編寫文檔，但每次你跳過這樣的事情，你就會承擔一點技術(shù)債務(wù)，公司總有一天會償還這些債務(wù)。

當然，開發(fā)人員是否有時間遵循所有這些最佳規(guī)范并不總是掌握在他們手中。通常，開發(fā)時間表是從上到下傳遞的，因此我們將以最后一條建議結(jié)束，即使是首席執(zhí)行官也需要接受。

想想你的未來，但活在當下

避免技術(shù)債務(wù)的真正關(guān)鍵是善于平衡你現(xiàn)在的需求和未來的目標。實際上，這樣做具有挑戰(zhàn)性，并且需要整合我們在這篇文章中已經(jīng)討論過的所有內(nèi)容，并將這些知識帶入有關(guān)公司目標和時間表的更廣泛討論中。

例如，如果你的CEO設(shè)定的開發(fā)截止日期在不承擔某種形式的技術(shù)債務(wù)的情況下時是很有挑戰(zhàn)性的，那么技術(shù)人員需要能夠識別和溝通這些權(quán)衡策略，以便它們可以被納入預(yù)算和規(guī)劃中。如果替代方案意味著將整個下個季度都花在處理客戶支持難題和匆忙重構(gòu)，有缺陷的代碼上。想要在本季度發(fā)布兩個主要功能的首席執(zhí)行官可能非常愿意接受只發(fā)布一個功能，

在平衡有限的時間、技能和預(yù)算的同時嘗試優(yōu)化以獲得最佳結(jié)果是一項真正的挑戰(zhàn)。 建立一家初創(chuàng)公司很不容易!你不太可能完全避免承擔技術(shù)債務(wù)，尤其是在匆忙的創(chuàng)業(yè)早期。但是，如果你能在你的技術(shù)棧中做出好的選擇，并建立良好的內(nèi)部護欄，以避免編碼偷工減料或解決你不必解決的問題，那么你至少可以確信自己正朝著正確的方向前進。

譯者介紹

范曉波，51CTO社區(qū)編輯，資深網(wǎng)絡(luò)安全工程師。精通SDN、SD-WAN、VPN、NFV等網(wǎng)絡(luò)相關(guān)技術(shù)。精通二三層網(wǎng)絡(luò)轉(zhuǎn)發(fā)。熟悉DPDK、VPP、OVS高性能網(wǎng)絡(luò)開源框架。喜歡打羽毛球、烹飪美食。

原文標題：??6 Things Startups Can Do to Avoid Tech Debt??，作者：Charlie Custer