如题 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
所以会有技术债问题是脑筋不好造成的 不是赶工造成的
我的想法

这其实很吃当下情况跟判断 我自己是能接受hard code来hot fix线上问题 事后在重构的

救火时间有限囉

试想半夜两点接到电话要紧急维修 你会去想程式架构还是赶快改好起床再调整 我相信大部分的人都会选后者

所以你要讨论什么？纯抒发请到FB

自问自答也一篇

本来就是救急用的做法啊 是要讨论什么

还以为是在问程式执行速度，原来是开发时间

如果胡乱模组化不如hardcode

客户坐在你后面现在究竟就要，慢慢refactor没关系

重构留给学弟做啊

你有比ai写的快吗

如果你的产品就是几个月才动一次 一定大改 那不值得做系统

...

就我状况 维运别人的都尽量不重构自己的就重构到爆 过度设计也在所不惜

修线上产品问题用的啊 隔天上班有时间再重构

我觉得hard code快一点。需要横跨的档案比较少的话可以快一点。解bug我就不知道要说啥了，困难到会有bug的话就别乱写啊…

一切就是看状况 像我以前公司很爱在C用function pointer模拟物件导向 结果维护麻烦的要死debug 工具都没办法直接用还不如分类简单的if套娃当然也不是说就不要抽象 但一些简单的东西就保持简单白痴都能读懂的code 就继续让白痴也能读懂

其实就急不急跟好不好修两个metric衡量一下

推一楼

我收到一个需求是某个按钮在下个月其中三天要关闭，真的要做api去开关这个按钮也没必要

设计到IDE都帮不了那种真的烦，后人根本不知道怎么追

bug不会因为你抽成一个function就不见hardcode也不会因为抽成function就不是hardcode, 你只是把hardcode写在一个function里面罢了

那是因为你已经确定需求了开发阶段谁知道AB功能看起来这么像PM却跑来说A要加啥米啥米但B不用

你说的对，下班之前解决这个问题随便你想怎么 code

つcopilot

你都因为哈扣了还在意哈扣怎写，有同步给团队就好*因为速度

客户站你后面 他非常火(哈扣/重构)

现在流行thread，你可以开一个发这样的东西

我知道你想讲的是workaround 而不是hardcode 对吧C不用function pointer 不要跟我讲你会写C

火烧屁股还在慢慢写的脑筋才不好吧，等等客户翻脸案子吹了看你的模组化能不能赚到钱

这种事情的逻辑与整理房间一样的 做法也与整理防间房间雷同 虽然我也不太会整理房间 但我还算会整理code整都是持续在整理的 到后面变成垃圾堆的时候要整理就累趴 也很难从垃圾堆找出你要的东西 越早整后面就不用怎么大扫除也就是重构 一开始就整理的成本也非常低 再找个收纳盒好的柜子也就是好的模组化方式就非常好至于楼主说的状况 那不是随便用个机制就搞定了吗

可读性和架构是给大专案用的，几百几千人的专案每个人都不会有 full picture，所以有一个架构师在做决策才重要几十人的小专案做扩充性什么的以开发效率来讲绝对不高，等需求稳定后再来重构绝对比每天慢慢磨扩充性花的总时间少很多，但是如果你每天都工作早早做完闲闲没事，做这些就是用目前免费的高时间成本（大量闲闲没事的时间）做以后的事（原本需求稳定后才要做的重构）与其写高扩充性的 code，还不如写方便重构的 code，例如那种可以整段剪下贴上，没有一堆生命周期、scope 等等考量的 code因为你做再多设想，也不可能知道还没出现的需求是什么，你做的扩充性永远都只是 hit or miss 而且还需要花大量时间成本在设计，但写容易重构的 code 需要的成本只是随手留意不要太高耦合、保持自己看得出来段落在哪的 copy-pasteable 的 snippet 而已

跟客户说明重构的重要性，使其接受

这问题很开放 只能说不同产业别 叠代开发的风气差很多

不需要扩充性非常强阿 不然整理的意义何在？ 有一定扩充性程式码又干净简洁很重要 超出扩充性范围边写边改就好 也不需要多少时间 而不是东西狂堆爆炸了再给其它人处理无脑堆与重构的通常都不会是同一个人

"hard code" 是小问题啊，通常都很容易重构我感觉你想讲的应该是应急的 dirty code我是建议真的有需要的话就写，然后马上重构

Hardcode本身就是一种workaround

现在都用AI写code了还在clean code分大小写才是笑话实际上的hard code看起来就是个笑话,想偷工早点会去睡觉*回去实际重构的作法都是拿自己的时间时程塞进去一并做掉，其一老板不答应，主管不一定同意，有限度重构让自己后续方便才是重点

clean code?

看module吧.... 自己的屎自己扛 除非你想写完离职

不想hardcode所以规划了一堆modules，做完发现不可行整个架构都必须大改，你前面的modules都变垃圾直接扣脑筋不好的帽子好厉害喔，菜鸟

其实跟经验有关…，入行发现有写人做了10年程度一样有些人写3-5年就超越了

与其讨论怎么做比较好，不如先想想你写的code到底有何价值，如果只是可有可无的功能怎么写都无所谓

hardcore是个好东西呀，不但可以短时间内把工作完成，而且还可以留下地雷，给你的竞争对手，一举两得