這篇我真的很有感

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

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

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

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

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

趕工出來的成果先另當別論, 但我可以理解沒有完善規劃紀錄歸檔後會有什麼影響..

不過, 也坦白說這方面的努力, 通常都不被視為"工作價值." (包括我現任工作場所)

因為這類的"燒回來後"才會有感覺, 而不是當下就可以體現出重要性, 所以沒被重視~

另外出問題想出方法解決的是英雄，但是在開始時就用巧思避免將問題發生的可能性這種不會被列入功勞。

大家都把預防勝於治療的道理掛在嘴邊，但現實社會是成功預防問題不會得到任何感激

還沒發生的事,杞人憂天 :laugh: :stupefy:

看過某晶片廠的code,這間後來被應呆兒併購,裡面的code亂七八糟,還有一大堆空格,換行,簡直傻眼,這一定是包給印度阿三寫的 :unbelief: :jolin: :think:

好的程式碼是需要定期維護的,這樣之後接手的才好上手易修改,不會花太多時間trace程式碼

code quality 通常跟預算成正相關阿
公司有錢有閒, RD 寫完了慢慢刻 慢慢找人review, 每次進code有CI 幫忙build/做static code-review /跑auto test script算test coverage...daily/weekly 還要有qa 驗build 是不是有regression....要花多少$$ 養多少人力自個算算 ~~
所以老闆有sense, 就有機會排預算人力做這些...

跟預算相關的要看案子，像在下的公司都是跟時間賽跑的....
預算再多也是無解，做出來慢了就直接違約用天數算賠錢XD
還有遇過整組team被抓去客戶那邊做完才回來的，這種
情況能搞出穩定能run的版本已經是英雄了;;;

這就是曲突徙薪跟焦頭爛額的由來啊，大家都只會記得焦頭爛額的功勞。
搞不好現在有些人連曲突徙薪這個成語都不知道呢。

:stupefy: :stupefy: :stupefy: :stupefy: :stupefy:

我只是個碼農... :nonono: