【CSDN 編者按】在軟件工程里，技術(shù)債往往不是一次“重大失誤”的產(chǎn)物，而是由無數(shù)個“當(dāng)時看起來還不錯”的小決定慢慢堆出來的。本文作者就用了一個極其真實的案例，講清了一個很多團隊都會踩的坑：為了省事、為了快、為了“先跑起來”，不斷模糊邊界、復(fù)用模型，最終讓數(shù)據(jù)結(jié)構(gòu)和業(yè)務(wù)語義一起失控。

原文鏈接：https://superkacper4.github.io/portfolio-2023/blog/technical-debt-everyday

作者 | Kacper Kuczewski 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

六個月前，我們做了一個看起來非常小、也非常“合理”的決定：不新建數(shù)據(jù)庫表。

原因很簡單，系統(tǒng)里的兩個業(yè)務(wù)實體“看起來足夠相似”，于是我們直接把它們?nèi)M了同一張表中——誰也沒想到，就是這個決定，讓我們在短短半年里，造出了比我日常維護的 10 年老系統(tǒng)還要多的技術(shù)債。

接下來，就說說這個坑是怎么一步步挖出來的。

一張表，拖垮整個系統(tǒng)

最初，我們的應(yīng)用邏輯非常簡單：用戶可以對房產(chǎn)添加觀點（Opinion）。當(dāng)時的數(shù)據(jù)模型大概長這樣：

}

你可以看到，這里面已經(jīng)存在一些明顯是“房源”和“觀點”都能共用的字段，比如：buildingId、pricePerSquareMeter、area，一切都還算正常。

“再加一個字段也沒什么吧？”

問題出現(xiàn)在我們準備引入公寓（Apartment）實體的時候。

我們發(fā)現(xiàn)，當(dāng)前的Opinion表缺少一些對“房源”來說非常關(guān)鍵的字段。但由于當(dāng)時評價和公寓信息都支持注冊用戶提交，我們就給表加了用戶關(guān)聯(lián)關(guān)系，功能覆蓋依然完整，一切看起來都還不錯。

于是我們繼續(xù)迭代，很快又發(fā)現(xiàn)缺了房間數(shù)這個基礎(chǔ)字段，那就加一個numberOfRooms；接著又加了floor（樓層）、height（層高）……從技術(shù)角度看，這些字段放在 Opinion表里并不會報錯；但從業(yè)務(wù)角度看——它們對“觀點”毫無意義。

慢慢地，事情開始失控

久而久之，整個表的一半字段都成了可選屬性（?），這種設(shè)計也讓可選屬性遍布了整個應(yīng)用的代碼中。

從數(shù)據(jù)層面看，這張表已經(jīng)亂成一鍋粥，最后我們不得不往表里加一個isApartmentOpinion的標(biāo)識字段，用來區(qū)分這條數(shù)據(jù)到底是公寓信息還是房產(chǎn)評價，想想都覺得無奈。

而從代碼層面來說，問題更嚴重：開發(fā)者根本無法快速判斷一個Opinion對象到底是公寓信息，還是單純的房產(chǎn)評價。

這一操作直接埋下了巨大的技術(shù)債。但最可悲的是，在很長一段時間里，所有人都覺得當(dāng)初“合表”的決定是合理的——直到隨著業(yè)務(wù)迭代，這個決策的弊端才被無限放大，變得無可挽回。

背景補充：一個 6 個月的成熟應(yīng)用

這里提一下我們的應(yīng)用背景，這是一個基于Next.js 開發(fā)的單體應(yīng)用，雖然只有 6 個月的歷史，但已經(jīng)是一個成熟的產(chǎn)品，甚至對接了外部支付系統(tǒng)。

它不算超復(fù)雜的大型應(yīng)用，但絕對也不是小打小鬧的 Demo。

這個產(chǎn)品的初衷，是做一個房產(chǎn)市場的評價和價格交流平臺，幫助用戶做房產(chǎn)決策——你可以把它理解為：“房地產(chǎn)版的 Glassdoor”（職場評價平臺）。

也正因如此，當(dāng)我們后來想在應(yīng)用中加入房產(chǎn)廣告功能時，系統(tǒng)里已經(jīng)有了那張Opinion評價表，這也是當(dāng)初我們選擇“合表”的重要原因。

鮮明對比：10 年老系統(tǒng)的正確操作

最近，我們在維護一個10 年的老系統(tǒng)時，要開發(fā)一個“優(yōu)惠券”新功能，初期也和往常一樣，打算直接在單體應(yīng)用里開發(fā)，把所有相關(guān)數(shù)據(jù)都塞進老系統(tǒng)的數(shù)據(jù)庫。

但很快我們意識到，這個功能遲早要和公司的商城微服務(wù)集群做外部集成。

于是我們停了下來：沒有“先湊合”，也沒有想著“反正能跑”，我們把整套邏輯直接拆出去，做成了一個獨立服務(wù)。

這個做法確實增加了開發(fā)工作量，也導(dǎo)致了功能上線延期，但換來了一個最重要的結(jié)果：優(yōu)惠券業(yè)務(wù)有了唯一的數(shù)據(jù)源，后續(xù)的維護、集成、迭代都有了清晰的邊界，從根本上避免了技術(shù)債的產(chǎn)生。

經(jīng)驗教訓(xùn)：技術(shù)債從不是憑空出現(xiàn)的

這次的經(jīng)歷讓我徹底明白：技術(shù)債從來都不是憑空產(chǎn)生的，而是我們每天在開發(fā)中，一步步親手造出來的。

技術(shù)債的產(chǎn)生，從來不是因為開發(fā)者偷懶、沒時間重構(gòu)，或者選了什么小眾的技術(shù)棧——更多時候，是我們在開發(fā)中做了那些看似合理的小決策，而這些決策在業(yè)務(wù)迭代中不斷發(fā)酵、滾雪球，最終演變成無法收拾的大問題。

比如那句耳熟能詳?shù)摹昂罄m(xù)再重構(gòu)（TODO: Will refactor it later）”，還有 “這兩個實體看起來差不多，不如共用一套邏輯吧”，最后都會讓代碼里充滿各種判斷分支（if），變得臃腫且難以維護。

最后，我想和所有開發(fā)者共勉：請重視技術(shù)債，并且一定要意識到，技術(shù)債就藏在我們每天的每一個開發(fā)決策里。它從來都不是 “前任開發(fā)者留下的爛攤子”，而是我們自己埋的坑，是你，也是我。

終有一天你會發(fā)現(xiàn)，自己對著屏幕抓耳撓腮想要調(diào)試的糟糕代碼，正是當(dāng)初自己寫的。開發(fā)之路多坑，愿我們都能保持清醒，積極面對，少埋坑，多填債。

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯(lián)合主辦「2026 奇點智能技術(shù)大會」將在上海隆重召開，大會聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術(shù)大會上海站，我們不見不散！