作者 HZYSoft (PCMan)標題 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 (臺灣)
※ 作者: HZYSoft 2024-06-01 17:11:48
※ 文章代碼(AID): #1cMkNRFj (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1717233115.A.3ED.html
※ 同主題文章:
Re: [討論] hard code 速度會快嗎?
06-01 17:11 HZYSoft
推 kurtsgm: 倒數第二句真的是重點
Hardcode又不留註解就是在雷1F 06/01 18:30
→ NDark: 反註解派該出來說註解無用論了3F 06/01 18:42
推 k7ji91ab5m: 反註解派不會認為hardcode不用註解
不懂在相輕甚麼4F 06/01 18:44
推 NDark: 連縮排用tab還是空白都能相輕了 還有不懂的新警察6F 06/01 18:46
→ testPtt: 打開專案心情就很差的感覺 refactor還是越早越好7F 06/01 19:16
推 ab4daa: 果然無限QE怎麼輸10F 06/01 19:28
→ angusyu: 你的結論就是怎樣哈扣都可以，真是可愛12F 06/01 20:28
推 wei115: 哈扣真的不是最差的選擇15F 06/01 20:44
→ labbat: 反註解派：程式碼即為說明書，程式碼即為文件，不hardcode寫出來的就是所有人應該看懂的常識16F 06/01 22:30
推 CRPKT: 我推薦使用 ad-hoc 這個字取代 hard code18F 06/01 22:47
→ peter98: 反註解派說程式碼即為所以不用寫註解的觀點沒有錯，但是反註解派的最大的問題是，他們對於自己的code太有自信，這是華人教育的傳統問題，華人教育是文章看不懂是讀者的問題。
反註解派說程式碼即為"說明書"所以不用寫註解的觀點*19F 06/01 22:49
→ VL1003: 反註解派的想法沒問題，就跟共產主義也沒問題，但實作就是問題一堆，理念很美好，但現實超難達成。24F 06/01 22:54
推 tsaigi: 反註解派反的是那種無用的註解吧 例如這裡呼叫xxx 之類看code比看註解還有用的地方26F 06/01 23:06
推 kurtsgm: 不用註解的前提是程式碼的命名、邏輯、流程都能簡單讀懂但通常會用hard code去解決問題一定有當時的時空背景在28F 06/01 23:16
推 t64141: 但實際上常常是：專案早期 hardcode勇敢欠債，成長期沒空改，穩定期東西沒壞就不要亂改(或已經改不動了)30F 06/01 23:17
→ kurtsgm: 或是用通則無法解決 ...
這種情況下後面再回頭看code只能靠回憶 幾乎無法單純讀懂32F 06/01 23:17
推 t64141: 至於註解不是寫不寫的問題，反而比較像是"如何適當使用註解"34F 06/01 23:20
→ HZYSoft: 註解的使用不是我想回的重點，重點是平衡短期和長期效益按照當下的狀況，調整開發的步調。
建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup或是有些緊急的修改有當下的時空背景，怕一忙沒法馬上清日後有空要 refactor 的時候，回想不起來當時狀況。
註解不是描述 code 做了什麼，而是描述為什麼會有這 hack至於 code 做了什麼，自然是 code 寫好讀 code 就懂了36F 06/02 00:07
※ 編輯: HZYSoft (111.249.166.208 臺灣), 06/02/2024 00:11:39
→ henrylin8086: 前期就幹模組化確實滿浪費時間的，不確定性高又有demo去喊芭樂拳的需求，直接hardcode省事。我的情境是專案中期會整個系統連程式語言都大改，這邊再開始做模組化都還來得及。44F 06/02 01:00
→ mmonkeyboyy: 我是都看專案的arch 兩著會連動
其實很合文主說的前面快速後面還債 反正有空能還
寫面太認真 後面要裝忙也很累48F 06/02 01:43
推 jack0204: 有的時候要先搶時間弄MVP驗證市場或技術方案
會寫得很亂，但要有文件歸納重點方便日後重寫或重構
與其說hardcode不好，不如說很多人技術不熟練只會這樣做順便說臨時修程式大多hardcode是因為你凌晨4點被call
大概也沒心弄得很漂亮，只是幾天內要記得重構51F 06/02 10:52
--