※ 引述《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，就去将哪个人
鞭十下。
谁管你说的好读、不好读，你是读得懂李白还是杜老爷，谁第一谁第二是不是？
又不是在写诗词歌赋。