什麼是技術債務，你能避免嗎？

如果您從事軟件開發，您將不得不在某個時候處理技術債務。 所以要回答標題中的問題......不，你無法避免它。 但是，您可以採取一些措施來最大程度地減少其影響並確保它不會失控。 至少太糟糕了。

什麼是技術債？

有時被稱為技術債務，本質上是隨著時間的推移，由於代碼不完善而產生的成本。 對源代碼的更改和更新是有成本的，向開發團隊添加新成員、添加新功能或修復錯誤和修補漏洞也是如此。

隨著您的項目變得更大，代碼庫也在擴展，並且有更多的人在處理該代碼，他們的聲音和風格會在這里和那裡發生衝突。 也許你有一個截止日期，一個不太理想的解決方案被修補到源代碼中以按時完成。 也許您添加了一個您不完全理解的開源組件來處理功能而不是自己編碼。 或者你可以在版本之間切換庫（例如從 Backbone 到 React），但仍然需要支持人們在他們的項目中使用遺留代碼庫。

絕對沒有這些事情是壞的。 不是靠自己。 也許根本不是。 但是當加在一起時，它們產生的技術債務將不得不在未來的某個時候償還。

在某些時候，可能需要替換（或分叉）該開源組件。 這將花費時間和金錢。 在遙遠的將來，您將需要從項目中刪除所有 Backbone 代碼並停止支持舊用戶。 再次，時間和金錢。 你為滿足最後期限而做的那個補丁？ 好吧，它最終會被撤銷，需要更永久的修復。 時間和金錢。 並且您的團隊中會有新成員通過舊代碼來完成所有這些工作，需要了解以前開發人員的代碼和邏輯。 時間。 錢。

你懂了。

雖然技術債務是一個抽象術語，通常是比喻性的，但技術債務的成本是非常真實的。 償還它具有貨幣價值，您可以在工作時間和工資單中跟踪您支付的利息。 您可以在所有軟件開發的底線中看到它。

你能避免技術債務嗎？

就像我之前說的……不是真的，不是。 如果您在代碼發布後返回到代碼，您將在您編寫的每個項目中累積技術債務。 但是，如果您分解技術債務的類型，您可以在項目中最小化甚至考慮它。 如果您事先考慮債務，這與獲得汽車貸款或抵押貸款沒有什麼不同。 您查看成本、利息和收益，然後決定是否可以/想要支付。

讓我們來看看我們上面討論的一些例子，看看是否有辦法避免、最小化或吸收成本。

考慮有目的的技術債務

當我們說有目的的技術債務時，我們的意思是您的團隊做出的決定不屬於您所從事的語言或項目類型的所謂最佳實踐。 我們之前提到過，您可能有一個截止日期。 也許這個截止日期是艱難而快速的。 也許它被更改或轉移的可能性為 0%。

這是您需要考慮貸款並承擔技術債務的時候。

你在這裡真的有三個選擇：

• 推出未完成且有缺陷的軟件，但您不會為代碼的清晰度和邏輯做出讓步
• 拉取您無法完善的功能，但盡可能發布您擁有的編寫好的功能
• 制定開發決策，發布“足夠好”的代碼以使一切正常運行，但可能需要稍後再次解決

這裡的第三個選項通常是人們選擇的一個。 這將陷入技術債務。 這沒有任何問題。 因為你決定這樣做。

償還有目的的債務貸款

確保在代碼中記錄選擇走這條路線背後的決定。 記錄您所做的與理想的解決方案。 並確保您在源代碼中至少包含某種評論，以表明此債務解決方案的實施位置（如果您知道，還包括項目其他領域的受影響系統）。 如果您不採取這一步，那麼添加到項目中（即使是在錯誤修復和補丁中，更不用說新功能或擴展的代碼庫）可能會因為在您期望一個完整的解決方案時找到一個拼湊的解決方案而被嚴重延遲。

同樣，拼湊的解決方案可能非常好，永遠不會給您帶來任何真正的問題。 但是技術債務仍然存在，需要加以考慮。

考慮遺留代碼技術債務

另一種常見的技術債務是 WordPress 目前正在積累的技術債務。 WordPress 可以在 PHP 5.x 上運行。 然而，最新的更新會告訴用戶它必須至少是 PHP 5.6。 到 2019 年底，WP Core 將需要 PHP 7.x。 但是，通過將需求推高，必須更新許多舊代碼。 因為在插件、主題和 Core 本身中仍然有 PHP 5.x 代碼。

更不用說新的塊編輯器了。 它是用 JavaScript 編寫的。 反應，具體。 這與 PHP 無關。 事實上，WordPress 核心的大部分內容都被一點一點地重寫為 JavaScript。 但所有這些 JS 也必須讚美並與 PHP 相處。 採用新技術很棒，需要採用新的版本控制要求。 但這樣做時，您正在為因該軟件存在一段時間而產生的不可避免的技術債務支付利息。

償還遺留代碼的債務

這有點困難，因為沒有很好的方法來做到這一點。 您可以選擇核選項並在新的語言/框架/版本中從頭開始完全重寫（看看我們在 Divi 2 和 Divi 3.0 之間做了什麼，從 Backbone.js 到 React）。 然而，這仍然不能完全解決債務問題，因為仍然有人在使用舊庫。 在某些時候，您將不得不放棄對遺留代碼庫的支持。 這有點像償還貸款。 直到你不得不拿出下一個。

如果這不是一個選項（或對您來說是最好的主意），您可以確保您不依賴於特定於語言或版本的功能。 前端開發人員必須一直處理這個問題，因為有些瀏覽器支持全新功能很快，而其他瀏覽器（Microsoft Edge/IE，咳咳）可能永遠不會採用它。 您可以通過堅持基礎知識來為您的項目提供未來證明，這反過來會使升級或重構時需要解決的更改數量少於其他情況。

隨著時間的推移考慮多個開發人員

這是一種技術債務，隨著時間的推移，大型團隊往往比小型開發團隊更糟糕。 儘管即使是小孩子也需要擔心。 你看，每個軟件工程師寫代碼的方式都不一樣。 很少有兩個開發人員使用完全相同的代碼解決相同的問題。 它們可能執行相同的功能，最終結果可能相同，但是代碼將以作者的聲音編寫（就像您可以在這里分辨誰寫了帖子，例如，Jason、Nathan、Donjete 和我都有不同的風格）。 代碼也不例外。

記住這一點，邏輯有時也會有不同的聲音。 一個開發人員的想法非常清楚，另一個開發人員會查看並且不知道為什麼代碼會這樣做。 當原始作者不再可用時，這個問題就變得真正有問題了。 由此產生的技術債務可能是災難性的。 但是有辦法處理它。

償還舊開發人員的技術債務

最簡單的方法是僱傭最好的開發人員，永遠不要讓他們離開你的公司。 曾經。

由於這種情況不會在 100% 左右發生，因此償還這筆債務可能比您想像的要容易一些。 首先，確保你訓練你的開發團隊來評論他們的代碼。 並且要好好評論。 每當他們做出一個甚至可能被其他人遠程認為模棱兩可的決定時，讓他們記下他們為什麼這樣做以及該功能是如何工作的。

此外，請確保您團隊中的每個開發人員都遵守風格指南或一套標準。 WordPress 核心有一套編碼標準，可以將插件、主題和核心貢獻保持內聯，以便以後來的任何人都不會遇到問題。 Airbnb 有一份 React 風格指南，已被採納為全行業的非官方標準。 即使是內部風格指南和標準也可以防止你的開發人員自己走得太遠，因為除非它們符合要求，否則不會合併這些類型的提交。

包起來

技術債務是一個非常現實的問題。 如果您知道如何管理它，它也是一個非常真實的資源。 通過決定何時承擔技術債務以及如何償還債務，您的開發可以比其他方式更快、更順利。 在那些不可避免地要承擔這種負擔的時候，我們希望我們已經為您提供了一些策略的想法，您可以實施這些想法，以減少其影響力。

您如何處理項目和開發團隊中的技術債務？

文章特色圖片由 Andrey Suslov/shutterstock.com 提供