※ 引述《talkmyself (休息中)》之銘言：
: 如題 hard code的速度會比較快嗎?
: 根據我經驗 hard code可以在極短時間內處理一些專案上的問題
: 但是專案上有高度相似的東西 藉由hard code去寫並不會比較快
: 反倒是多花一點時間重構 重構完畢之後 再來只要套function 修改參數
: 這速度會比hard code快很多
: hard code完畢有十個地方要改 才發現改9個地方 發現bug 又要花時間處理
: 反倒是重構後的code 就算10個地方要改 可以縮減到5個地方
: 然後藉由5個地方又在同一隻function 帶入參數之後 會比較快
: 然而bug也不容易產生
: 因為hard code去處理 只是極短時間內比較快寫完的錯覺
: 後續要加一兩個功能就會越來越慢 除非是極迷你的專案
: 就算是小專案 hard code也不會比較快
: 至於會留下大量技術債的問題 不是為了趕時間而hard code
: 而是因為腦筋不好而hard code
: 因為腦筋不好 所以很多可以模組化的東西都hard code去解決
: 發現到越改越複雜 到最後連自己都無法維運
: 腦筋不好的緣故 改一個bug會產生3個bug
: 所以會有技術債問題是腦筋不好造成的 不是趕工造成的
: 我的想法
關鍵其實要看你的專案現在在哪個階段
1. 專案在非常早期:
這時候 hard code 有可能其實是最佳解。
此時需求不太很確定，可能經常修改。你現在看起來有幾段 code 很相似，
可以重構成共用 function，但不幸的是，幾個月後商業需求改變，他們的行為
越差越多，卻因為共用 code 造成難以擴充，改了這個就壞了那個，
明明差很多的邏輯，卻硬要共用，只會拖慢開發
另外是有時候還在探索可行的產品方向，prototyping 結束後決定捨棄，
那你就白費工夫在 refactor 了，這些 code 很快都是要 deprecate 的
在這些情況下，先 hard code 都是相對好的做法，呼應了不要 early optimization
2. 專案在穩定成長期:
這時候會慢慢添加新功能，但不會大幅度的改變，先 hard code 緊急修復，
把損害降到最低，接著註解寫下 TODO，並且留下 bug 連結供日後參考即可。
"農暇"之餘，再慢慢安排時間來 refactor 還債即可。
當然，如果開發時間充裕，那還是好好設計，一次把它做好比較好。
3. 專案不太會改，或在生命週期尾聲:
這時候直接 hard code 常常也是最佳解，花太多成本去 refactor 沒有什麼效益
這些 code 日後也不太會再改了，多只是維護工作，甚至系統隨後就會淘汰。
欠一些技術債沒還也還好，產品結束這些呆帳就打消了 XD
如果有在好好追蹤技術債，定期償還，視情況舉債，有時是一件好事情。
重點 hard code 的當下要留下註解，說明前因後果，並且開 bug 追蹤，
這樣日後不會忘記，要 refactor 也比較好搜尋到這些位置
補充:
註解的使用不是我想回的重點，重點是平衡短期和長期效益
按照當下的狀況，調整開發的步調。
建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup
或是有些緊急的修改有當下的時空背景，怕一忙沒法馬上清
日後有空要 refactor 的時候，回想不起來當時狀況。
註解不是描述 code 做了什麼，而是描述為什麼會有這 hack
至於 code 做了什麼，自然是 code 寫好讀 code 就懂了