作者HZYSoft (PCMan)
看板Soft_Job
标题Re: [讨论] hard code 速度会快吗?
时间Sat Jun 1 17:11:48 2024
※ 引述《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 就懂了
--
Sent from PCMan on PCMan's PC
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.249.166.208 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1717233115.A.3ED.html
1F：推 kurtsgm: 倒数第二句真的是重点 06/01 18:30
2F：→ kurtsgm: Hardcode又不留注解就是在雷 06/01 18:30
3F：→ NDark: 反注解派该出来说注解无用论了 06/01 18:42
4F：推 k7ji91ab5m: 反注解派不会认为hardcode不用注解 06/01 18:44
5F：→ k7ji91ab5m: 不懂在相轻甚麽 06/01 18:45
6F：推 NDark: 连缩排用tab还是空白都能相轻了 还有不懂的新警察 06/01 18:46
7F：→ testPtt: 打开专案心情就很差的感觉 refactor还是越早越好 06/01 19:16
8F：推 B0988698088: 有反注解派哦？那他们怎麽处理需要注解的情境？通灵 06/01 19:16
9F：→ B0988698088: 吗 06/01 19:16
10F：推 ab4daa: 果然无限QE怎麽输 06/01 19:28
11F：推 abccbaandy: 结论：hard code就对了(？ 06/01 19:34
12F：→ angusyu: 你的结论就是怎样哈扣都可以，真是可爱 06/01 20:28
13F：推 za755188: 楼上怀疑PCMan吗? 06/01 20:40
14F：推 pyCassandra: 推PCMan 06/01 20:43
15F：推 wei115: 哈扣真的不是最差的选择 06/01 20:44
16F：→ labbat: 反注解派：程式码即为说明书，程式码即为文件，不hardcode 06/01 22:30
17F：→ labbat: 写出来的就是所有人应该看懂的常识 06/01 22:31
18F：推 CRPKT: 我推荐使用 ad-hoc 这个字取代 hard code 06/01 22:47
19F：→ peter98: 反注解派说程式码即为所以不用写注解的观点没有错，但是 06/01 22:49
20F：→ peter98: 反注解派的最大的问题是，他们对於自己的code太有自信， 06/01 22:49
21F：→ peter98: 这是华人教育的传统问题，华人教育是文章看不懂是读者的 06/01 22:50
22F：→ peter98: 问题。 06/01 22:50
23F：→ peter98: 反注解派说程式码即为"说明书"所以不用写注解的观点* 06/01 22:51
24F：→ VL1003: 反注解派的想法没问题，就跟共产主义也没问题，但实作就是 06/01 22:54
25F：→ VL1003: 问题一堆，理念很美好，但现实超难达成。 06/01 22:55
26F：推 tsaigi: 反注解派反的是那种无用的注解吧 例如这里呼叫xxx 之类看 06/01 23:06
27F：→ tsaigi: code比看注解还有用的地方 06/01 23:06
28F：推 kurtsgm: 不用注解的前提是程式码的命名、逻辑、流程都能简单读懂 06/01 23:16
29F：→ kurtsgm: 但通常会用hard code去解决问题一定有当时的时空背景在 06/01 23:17
30F：推 t64141: 但实际上常常是：专案早期 hardcode勇敢欠债，成长期没空 06/01 23:17
31F：→ t64141: 改，稳定期东西没坏就不要乱改(或已经改不动了) 06/01 23:17
32F：→ kurtsgm: 或是用通则无法解决 ... 06/01 23:17
33F：→ kurtsgm: 这种情况下後面再回头看code只能靠回忆 几乎无法单纯读懂 06/01 23:17
34F：推 t64141: 至於注解不是写不写的问题，反而比较像是"如何适当使用注 06/01 23:20
35F：→ t64141: 解" 06/01 23:20
36F：→ HZYSoft: 注解的使用不是我想回的重点，重点是平衡短期和长期效益 06/02 00:07
37F：→ HZYSoft: 按照当下的状况，调整开发的步调。 06/02 00:07
38F：→ HZYSoft: 建议注解单纯是加个 TODO: 的注记日後才不会忘了 cleanup 06/02 00:08
39F：→ HZYSoft: 或是有些紧急的修改有当下的时空背景，怕一忙没法马上清 06/02 00:09
40F：→ HZYSoft: 日後有空要 refactor 的时候，回想不起来当时状况。 06/02 00:09
41F：→ HZYSoft: 注解不是描述 code 做了什麽，而是描述为什麽会有这 hack 06/02 00:09
42F：→ HZYSoft: 至於 code 做了什麽，自然是 code 写好读 code 就懂了 06/02 00:10
※ 编辑: HZYSoft (111.249.166.208 台湾), 06/02/2024 00:11:39
43F：推 viper9709: 推这篇专业 06/02 00:46
44F：→ henrylin8086: 前期就干模组化确实满浪费时间的，不确定性高又有d 06/02 01:00
45F：→ henrylin8086: emo去喊芭乐拳的需求，直接hardcode省事。我的情境 06/02 01:00
46F：→ henrylin8086: 是专案中期会整个系统连程式语言都大改，这边再开 06/02 01:00
47F：→ henrylin8086: 始做模组化都还来得及。 06/02 01:00
48F：→ mmonkeyboyy: 我是都看专案的arch 两着会连动 06/02 01:43
49F：→ mmonkeyboyy: 其实很合文主说的前面快速後面还债 反正有空能还 06/02 01:44
50F：→ mmonkeyboyy: 写面太认真 後面要装忙也很累 06/02 01:44
51F：推 jack0204: 有的时候要先抢时间弄MVP验证市场或技术方案 06/02 10:52
52F：→ jack0204: 会写得很乱，但要有文件归纳重点方便日後重写或重构 06/02 10:54
53F：→ jack0204: 与其说hardcode不好，不如说很多人技术不熟练只会这样做 06/02 10:56
54F：推 jack0204: 顺便说临时修程式大多hardcode是因为你凌晨4点被call 06/02 10:59
55F：→ jack0204: 大概也没心弄得很漂亮，只是几天内要记得重构 06/02 11:00
56F：推 za755188: 不够清楚的需求没必要过度最佳化 但又有多少需求是清楚 06/02 16:14
57F：→ za755188: 的呢? 06/02 16:14
58F：→ superpandal: 不过是不重构的藉口罢了 你不能保证你写出来的都很清 06/02 17:26
59F：→ superpandal: 爽 堆到後面你不考虑共用还债就是推给别人还 这种也 06/02 17:28
60F：→ superpandal: 是种垃圾行为 当然好的方向想就是不喜欢被鸟尽弓藏 06/02 17:29
61F：→ superpandal: 不做模组化给後面的人爽而已 是否可以共用那也是看 06/02 17:31
62F：→ superpandal: 个人功力 只要写的显式即可 06/02 17:32
63F：→ superpandal: 未知才会拖慢开发速度 而不是已知 已知只要你对语言 06/02 17:34
64F：→ superpandal: 不是很不熟或恶搞都能完善到底 06/02 17:35
65F：→ superpandal: 然而这样搞对你来讲也许可以算已知 对接手的人就是未 06/02 17:39
66F：→ superpandal: 知了 要花成倍心思去解决 当然不写注解要求就是写的 06/02 17:40
67F：→ superpandal: 好 复杂需求简归纳简化 达成可以显式除错而不用通灵 06/02 17:42
68F：→ superpandal: 然而依照你上面这样搞对你来讲可以算已知 06/02 17:45
69F：→ superpandal: 至於如何共用的更好讲究的是逻辑圆融 天人合一 06/02 17:50
70F：→ superpandal: 要达到楼主讲的流程趋势 对整洁本来就要有一定要求 06/02 18:00
71F：→ superpandal: 否则自己写的都看不懂了 不要说别人 往後才会有下一 06/02 18:01
72F：→ superpandal: 步 06/02 18:02
73F：→ superpandal: 讲到底最重要的还是整齐 模组化都不用搞到很高大上 06/02 18:05
74F：→ superpandal: 毕竟搞太多就会隐藏细节 06/02 18:06
75F：推 andy0055: 推 倒数第二行话… 06/02 21:40
76F：→ andy0055: 写了一堆注解，结果关键的地雷却不写…. 06/02 21:41
77F：→ gmoz: 注解最大作用就是拿来贴Jira或confluence连结XD 06/03 10:18
78F：→ Araiman: 有些事要做过大专案 踩过坑流过泪才能体会了 06/03 13:52
79F：推 Lipraxde: "注解不是描述 code 做了什麽，而是描述为什麽会有这 h 06/03 15:13
80F：→ Lipraxde: ack"...不只是 hack，平常写注解本来就该以补充程式码 06/03 15:13
81F：→ Lipraxde: 以外的资讯、解释由来为主，看一堆解释底下程式码在做 06/03 15:13
82F：→ Lipraxde: 什麽操作的注解...当作是在写教学用的 sample code，看 06/03 15:13
83F：→ Lipraxde: 着浪费视觉空间 06/03 15:13
84F：→ TonyQ: //这里定义了变数 a=1 06/03 15:17
85F：→ TonyQ: var a=1; //你不写注解我也知道 06/03 15:17
86F：推 GDaaaa: 推 06/03 16:29
87F：→ shooter555: // 注解是用来说这段垃圾code 是上层交代 不要怪我 06/03 23:54
88F：→ becca945: TODO: someone else do 06/04 00:16
89F：推 sb8888: 我会留着hardcode的代码重构 这样不好吗 06/04 13:06
90F：→ sb8888: 直接开个v2 这样 06/04 13:07
91F：推 fatb: 根据经验不会有时间重构 如果能让你有时间重构 那是ＰＭ时间 06/04 17:10
92F：→ fatb: 压得不够紧 所以最好还是一次写好 06/04 17:11
93F：→ fatb: 尾声部份就同意 最好写得越简单越笨越好 免得前面的大量测试 06/04 17:12
94F：→ fatb: 做白工 （虽然一改都还是要重测 但出事就会被放大) 06/04 17:13
95F：→ eva19452002: 不是说有一派主张不要写注解，只要var和func名称取得 06/04 19:30
96F：→ eva19452002: 好，再加上程式内聚力强，就可以看懂程式在做什麽了 06/04 19:31
97F：→ brucetu: 看得懂程式在做什麽不一定看得懂为什麽要做这件事啊所以 06/04 19:57
98F：→ brucetu: 才要注解 06/04 19:57
99F：推 w0005151: 对code有太多理想的人多半没做过大专案 06/04 22:41
100F：推 viper9709: 看得懂程式在做什麽不一定懂为什麽要这样做+1 06/05 00:37
101F：→ fatb: 不一定是没做过大专案 还有一种是主管职愿意假日花时间那种 06/05 10:04
102F：推 wistful96: 推 06/07 11:05