※ 引述《Lordaeron (Terry)》之銘言：
: ※ 引述《HZYSoft (PCMan)》之銘言：
: : 如果有在好好追蹤技術債，定期償還，視情況舉債，有時是一件好事情。
: : 重點 hard code 的當下要留下註解，說明前因後果，並且開 bug 追蹤，
: : 這樣日後不會忘記，要 refactor 也比較好搜尋到這些位置
: : 補充:
: : 註解的使用不是我想回的重點，重點是平衡短期和長期效益
: : 按照當下的狀況，調整開發的步調。
: : 建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup
: : 或是有些緊急的修改有當下的時空背景，怕一忙沒法馬上清
: : 日後有空要 refactor 的時候，回想不起來當時狀況。
: : 註解不是描述 code 做了什麼，而是描述為什麼會有這 hack
: : 至於 code 做了什麼，自然是 code 寫好讀 code 就懂了
: 都說是做專案了，又不是做產品。
: 做專案當然是做完收錢，Meet Dealine，所以重點是，
: 照案主的需求，改成他要的，照資安需求，修掉有問題的地方。好好上線。
: 一案結束，就下一案來了，你還有空refactor? 誰billing你？
: 我是真的不明白ptt 上一堆天天refactor 掛嘴邊的。
: 用數字說話吧，台灣是出了幾個產品？ 幾個open source project ?
: 大家不就接案或做公司內部PROJECT。
: 你一個人爽refactor 讓其他人陪你一起更版，就真的是一個老闆的現象囉。
再吐一下天天refactor 的，在台灣你可以看到一堆公司，都有自己的產品，
就是接案子後，用原案的CODE重包出來的：產品。
然後，根本賣不動，這樣要你老闆BILLING你的閒著沒事做去re-fat-tor?
號稱精進系統，使系統更好what?
這下問題大了，何謂"更好"？如何衡量？
跑更快？算更準？資源吃更少？更容易讀？
如果哪一項是為了讓產品更有市場競爭力的也就算了，
公司還可能BILLING你去 fat 一下。然後再BILLING 大伙又重測一次。
最後，注解不寫一下這段CODE 的作用，只寫為什麼這樣HACK，就去將哪個人
鞭十下。
誰管你說的好讀、不好讀，你是讀得懂李白還是杜老爺，誰第一誰第二是不是？
又不是在寫詩詞歌賦。