眾說紛紜：

靈活性可能導致更多的設計時間和複雜性。這個詞本身看起來不錯，但沒那麼簡單。

我現在正在（艱難地）學習到，隨著複雜性的增加，維持軟體專案中的變化速率變得越來越困難。如果我可以回去一年，我肯定會在設計更多SOLID方面投入更多的前期精力。

我認為靈活性更昂貴。理由：靈活性通常會導致過度抽象，從而過度滲透到測試中。另外，使用者可能會注意到效能降低。我寧願在舊程式碼上使用TDD，並且僅在測試告訴我需要時才引入靈活性。

我記得歷史老師說，在宗教法庭上，可怕的事情是以上帝的名義完成的。我已經看到以OO的名義做的可怕的事情。

我選擇A，但我認為B也取決於開發人員/工程師的技能。

這個問題缺乏背景。也許程式碼很簡單，但是很難更改。然後將其丟棄並使用新功能再次編寫將更便宜。只要具有有意義的測試更改就很便宜。

最好的方法是：“保持程式碼“簡單”到足以輕鬆新增新功能。” 另外：“保持足夠的迴歸測試以無畏地新增新功能。” 簡單性和迴歸測試取代了為未知的未來提供靈活性的需求。

有人說靈活性會導致過度投入和過度抽象，但這將意味著程式碼難以維護。因此，我選擇A，因為靈活的程式碼必須良好且易於維護。

取決於您如何量化技術債務成本

取決於您對“難以改變”的含義以及為何難以改變。

這就像複利-取決於變化率。最初，義大利麵條程式碼的成本較低。隨著時間的流逝，變化的速度增加-作為人類，我們希望在更短的時間內得到更多。這時靈活性變得更便宜，而義大利麵條式程式碼開始削弱企業。