這篇我真的很有感

抄捷徑的技術債，遲早要還的https://www.ithome.com.tw/node/71807

相信很多程式設計者都有類似的經驗，當我們在做軟體設計、或者是實際撰寫程式碼時，因為一些理由，我們沒有做出能得到最佳品質的設計、或是寫下有著最佳品質的程式碼。例如，當專案的時程過於緊迫，而在期限內完成工作又是十分重要時，我們就有可能放棄較為彈性、較具可擴充性的架構設計，或是寫出具有壞味道（bad smell）的程式碼。

受限於時程，對設計或程式碼當下的取捨，可能會在日後持續的付出代價。每當你遭遇到現有架構無法因應之際，就必須為當初在架構設計的彈性或擴充性上，所做的犧牲付出代價；每當程式中的壞味道持續影響程式碼的品質時，也必須為當初在程式碼品質上的犧牲付出代價。有些人會用「快，但是髒（quick and dirty）」來描述這種作法。

在1992年的時候，Ward Cunningham首先提出了一個名為「技術債（Technical Debt）」的隱喻（metaphor）來描述以上這種許多人都有的共通類似經驗。這是一個十分有趣的比喻方式。
----------------------------------------------------------

之前主管為了應付其它單位的要求
快速的產生了一些程式...
後續維護真的難到靠北
花超多人力成本