作者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/m.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