※ 引述《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 就懂了