作者talkmyself (休息中)
看板Soft_Job
标题[讨论] hard code 速度会快吗?
时间Tue May 28 17:13:44 2024
如题 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
所以会有技术债问题是脑筋不好造成的 不是赶工造成的
我的想法
--
没有酱汁的料理没有试吃的必要
就如同
没有配音员的角色就只是个软体
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 203.67.103.85 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1716887627.A.E2F.html
1F：推 Hnash: 这其实很吃当下情况跟判断 我自己是能接受hard code来hot f 05/28 17:29
2F：→ Hnash: ix线上问题 事後在重构的 05/28 17:29
3F：推 cutearia: 救火时间有限罗 05/28 17:31
4F：推 Hnash: 试想半夜两点接到电话要紧急维修 你会去想程式架构还是赶 05/28 17:31
5F：→ Hnash: 快改好起床再调整 我相信大部分的人都会选後者 05/28 17:31
6F：嘘 B0988698088: 所以你要讨论什麽？纯抒发请到FB 05/28 17:37
7F：嘘 tzouandy2818: 自问自答也一篇 05/28 17:41
8F：推 ko27tye: 本来就是救急用的做法啊 是要讨论什麽 05/28 17:45
9F：推 b0920075: 还以为是在问程式执行速度，原来是开发时间 05/28 18:24
10F：→ sos20122: 如果胡乱模组化不如hardcode 05/28 18:36
11F：推 wulouise: 客户坐在你後面现在究竟就要，慢慢refactor没关系 05/28 18:41
12F：推 MonkeyCL: 重构留给学弟做啊 05/28 18:57
13F：嘘 Csongs: 你有比ai写的快吗 05/28 19:33
14F：推 NDark: 如果你的产品就是几个月才动一次 一定大改 那不值得做系统 05/28 19:38
15F：→ k7ji91ab5m: ... 05/28 20:47
16F：推 chuegou: 就我状况 维运别人的都尽量不重构 05/28 21:01
17F：→ chuegou: 自己的就重构到爆 过度设计也在所不惜 05/28 21:01
18F：推 seal0112: 修线上产品问题用的啊 隔天上班有时间再重构 05/28 21:07
19F：→ pot1234: 我觉得hard code快一点。需要横跨的档案比较少的话可以 05/28 21:39
20F：→ pot1234: 快一点。解bug我就不知道要说啥了，困难到会有bug的话就 05/28 21:39
21F：→ pot1234: 别乱写啊… 05/28 21:39
22F：→ BoXeX: 一切就是看状况 像我以前公司很爱在C用function pointer 05/28 23:39
23F：→ BoXeX: 模拟物件导向 结果维护麻烦的要死 05/28 23:40
24F：→ BoXeX: debug 工具都没办法直接用 05/28 23:40
25F：→ BoXeX: 还不如分类简单的if套娃 05/28 23:41
26F：→ BoXeX: 当然也不是说就不要抽象 但一些简单的东西就保持简单 05/28 23:45
27F：→ BoXeX: 白痴都能读懂的code 就继续让白痴也能读懂 05/28 23:46
28F：→ NTUTM04: 其实就急不急跟好不好修两个metric衡量一下 05/29 00:12
29F：推 viper9709: 推一楼 05/29 00:13
30F：推 hakama99: 我收到一个需求是某个按钮在下个月其中三天要关闭，真的 05/29 00:20
31F：→ hakama99: 要做api去开关这个按钮也没必要 05/29 00:20
32F：推 abccbaandy: 设计到IDE都帮不了那种真的烦，後人根本不知道怎麽追 05/29 00:38
33F：推 DDR678: bug不会因为你抽成一个function就不见 05/29 07:53
34F：推 DDR678: hardcode也不会因为抽成function就不是hardcode, 你只是 05/29 07:57
35F：→ DDR678: 把hardcode写在一个function里面罢了 05/29 07:57
36F：→ lazarus1121: 那是因为你已经确定需求了 05/29 09:04
37F：→ lazarus1121: 开发阶段谁知道AB功能看起来这麽像 05/29 09:04
38F：→ lazarus1121: PM却跑来说A要加啥米啥米但B不用 05/29 09:04
39F：嘘 brucetu: 你说的对，下班之前解决这个问题 05/29 09:08
40F：→ brucetu: 随便你想怎麽 code 05/29 09:08
41F：→ yamagishi: つcopilot 05/29 11:00
42F：→ Suleika: 你都因为哈扣了还在意哈扣怎写，有同步给团队就好 05/29 12:04
43F：→ Suleika: *因为速度 05/29 12:04
44F：→ dapple: 客户站你後面 他非常火(哈扣/重构) 05/29 13:10
45F：推 jyunwei: 现在流行thread，你可以开一个发这样的东西 05/29 13:41
46F：→ shooter555: 我知道你想讲的是workaround 而不是hardcode 对吧 05/29 13:52
47F：→ shooter555: C不用function pointer 不要跟我讲你会写C 05/29 13:55
48F：推 wade2432: 火烧屁股还在慢慢写的脑筋才不好吧，等等客户翻脸案子 05/29 16:48
49F：→ wade2432: 吹了看你的模组化能不能赚到钱 05/29 16:48
50F：→ superpandal: 这种事情的逻辑与整理房间一样的 做法也与整理防间 05/29 18:10
51F：→ superpandal: 房间 05/29 18:10
52F：→ superpandal: 雷同 虽然我也不太会整理房间 但我还算会整理code 05/29 18:12
53F：→ superpandal: 整都是持续在整理的 到後面变成垃圾堆的时候要整理就 05/29 18:13
54F：→ superpandal: 累趴 也很难从垃圾堆找出你要的东西 越早整後面就不 05/29 18:15
55F：→ superpandal: 用怎麽大扫除也就是重构 一开始就整理的成本也非常 05/29 18:16
56F：→ superpandal: 低 再找个收纳盒好的柜子也就是好的模组化方式就非常 05/29 18:18
57F：→ superpandal: 好 05/29 18:20
58F：→ superpandal: 至於楼主说的状况 那不是随便用个机制就搞定了吗 05/29 18:24
59F：推 CoNsTaR: 可读性和架构是给大专案用的，几百几千人的专案每个人都 05/29 19:55
60F：→ CoNsTaR: 不会有 full picture，所以有一个架构师在做决策才重要 05/29 19:55
61F：→ CoNsTaR: 几十人的小专案做扩充性什麽的以开发效率来讲绝对不高， 05/29 19:55
62F：→ CoNsTaR: 等需求稳定後再来重构绝对比每天慢慢磨扩充性花的总时间 05/29 19:55
63F：→ CoNsTaR: 少很多，但是如果你每天都工作早早做完闲闲没事，做这些 05/29 19:55
64F：→ CoNsTaR: 就是用目前免费的高时间成本（大量闲闲没事的时间）做以 05/29 19:55
65F：→ CoNsTaR: 後的事（原本需求稳定後才要做的重构） 05/29 19:55
66F：推 CoNsTaR: 与其写高扩充性的 code，还不如写方便重构的 code，例如 05/29 20:04
67F：→ CoNsTaR: 那种可以整段剪下贴上，没有一堆生命周期、scope 等等考 05/29 20:04
68F：→ CoNsTaR: 量的 code 05/29 20:04
69F：→ CoNsTaR: 因为你做再多设想，也不可能知道还没出现的需求是什麽， 05/29 20:04
70F：→ CoNsTaR: 你做的扩充性永远都只是 hit or miss 而且还需要花大量 05/29 20:04
71F：→ CoNsTaR: 时间成本在设计，但写容易重构的 code 需要的成本只是随 05/29 20:04
72F：→ CoNsTaR: 手留意不要太高耦合、保持自己看得出来段落在哪的 copy-p 05/29 20:04
73F：→ CoNsTaR: asteable 的 snippet 而已 05/29 20:04
74F：推 new122851: 跟客户说明重构的重要性，使其接受 05/29 20:07
75F：推 jhjhs33504: 这问题很开放 只能说不同产业别 叠代开发的风气差很多 05/29 23:22
76F：→ superpandal: 不需要扩充性非常强阿 不然整理的意义何在？ 有一定 05/30 01:20
77F：→ superpandal: 扩充性程式码又乾净简洁很重要 超出扩充性范围边写边 05/30 01:23
78F：→ superpandal: 改就好 也不需要多少时间 而不是东西狂堆爆炸了再给 05/30 01:24
79F：→ superpandal: 其它人处理 05/30 01:25
80F：→ superpandal: 无脑堆与重构的通常都不会是同一个人 05/30 01:28
81F：→ RumiManiac: "hard code" 是小问题啊，通常都很容易重构 05/30 05:05
82F：→ RumiManiac: 我感觉你想讲的应该是应急的 dirty code 05/30 05:05
83F：→ RumiManiac: 我是建议真的有需要的话就写，然後马上重构 05/30 05:06
84F：推 wang19980531: Hardcode本身就是一种workaround 05/31 14:08
85F：推 prag222: 现在都用AI写code了还在clean code分大小写才是笑话 05/31 17:58
86F：推 prag222: 实际上的hard code看起来就是个笑话,想偷工早点会去睡觉 05/31 18:01
87F：→ prag222: *回去 05/31 18:01
88F：推 prag222: 实际重构的作法都是拿自己的时间时程塞进去一并做掉，其 05/31 18:13
89F：→ prag222: 一老板不答应，主管不一定同意，有限度重构让自己後续方 05/31 18:13
90F：→ prag222: 便才是重点 05/31 18:13
91F：→ superpandal: clean code? 06/01 13:15
92F：→ mmonkeyboyy: 看module吧.... 自己的屎自己扛 除非你想写完离职 06/02 01:42
93F：推 luke72: 不想hardcode所以规划了一堆modules，做完发现不可行 06/07 19:00
94F：→ luke72: 整个架构都必须大改，你前面的modules都变垃圾 06/07 19:01
95F：→ luke72: 直接扣脑筋不好的帽子好厉害喔，菜鸟 06/07 19:02
96F：→ layer0930: 其实跟经验有关…，入行发现有写人做了10年程度一样 06/09 02:25
97F：→ layer0930: 有些人写3-5年就超越了 06/09 02:25
98F：→ luluking: 与其讨论怎麽做比较好，不如先想想你写的code到底有何价 06/09 20:21
99F：→ luluking: 值，如果只是可有可无的功能怎麽写都无所谓 06/09 20:21
100F：推 tvbic: hardcore是个好东西呀，不但可以短时间内把工作完成，而且 06/09 22:06
101F：→ tvbic: 还可以留下地雷，给你的竞争对手，一举两得 06/09 22:06