數據庫設計不好

Question

我不知道我是否可以在這裏提出這樣的問題，所以我很抱歉。

我使用的系統具有很多依賴性和設計不佳的數據庫。現在我必須做出決定，並希望聽到你們的一些案例。

情況就是這樣：軟件的某些部分在所有使用情況下都沒有考慮過。今天我需要做一些重大的改變，比如在數據庫上創建新的關係，重構所有的類和方法。這就是理論所說的，但實際上這將需要很多天，會延遲版本和整個時間表。我可以選擇保持gambiarra（可行的錯誤代碼），並只做出滿足新需求的小改動。

我知道，每個案件都是不同的，所以我想聽聽你會怎麼做，如果你有過類似的東西。

Answer 1

這是很難提供這麼小細節一些建議，但我認爲你需要讓利益相關者認識到他們所問的是要及時和昂貴。

話雖這麼說，試圖打破這一切工作納入一套實際可行的變化（我知道你已經有一些用戶故事）。逐步遞送並優先考慮它們，以便您的利益相關者儘快獲得價值。

可能運行與他們車間瞭解哪些是對他們最重要的，對其進行權衡的努力和實現的風險是使每個人都在同一頁上的好方法。

祝你好運，聽起來像你會需要它。

Answer 2

這是一個非常普遍的情況。你沒有提供任何具體的細節，所以很難回答以外的其他問題。

完成工作，擔心未來和技術債務之間總是存在權衡。

擔心未來 - 你認爲你需要在未來的版本中的功能 - 是一個阿巴德的想法。 「我現在就把它放進去，然後它會讓下一個版本更容易一些」 - 每一次，「以防萬一」代碼需要愛和關注，而且每一次都不是很完美正確的時候到了。所以，我不建議爲將來的用例建立支持。它減慢了你的速度，你往往會猜測你後來需要什麼。在敏捷中，他們使用YAGNI的首字母縮略詞 - 「你不需要它」。非常明確地回答你的問題 - 我不認爲不支持未來用例的代碼或設計是「不好的」。

但是，你真的應該真的擔心技術債務。你的代碼是否是模塊化的，由體面的測試用例覆蓋，可讀性，不是太複雜？質量的一個方面是「擴展這個有多容易？」。這是一個非常不同的問題 - 難以延伸的代碼是錯誤的代碼。

如果在這種情況下發現自己，你可能希望你的公司介紹的technical debt概念。有時候，承擔技術債務是一個很好的決定 - 而且我從未參與過一個沒有某種程度的項目。但這是一個商業問題，而不是技術問題。這歸結爲「您希望多少錢用於維護或擴展此功能，以換取更快的出門時間？」。如果這是最後一個版本，答案可能是「很多」。如果這是長期發佈計劃中的第一個，那麼答案可能是「不太多」。