如題 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://www.ptt.cc/bbs/Soft_Job/M.1716887627.A.E2F.htmlHnash1樓這其實很吃當下情況跟判斷 我自己是能接受hard code來hot f 05/28 17:29
→ Hnash2樓ix線上問題 事後在重構的 05/28 17:29
cutearia3樓救火時間有限囉 05/28 17:31
Hnash4樓試想半夜兩點接到電話要緊急維修 你會去想程式架構還是趕 05/28 17:31
→ Hnash5樓快改好起床再調整 我相信大部分的人都會選後者 05/28 17:31
B09886980886樓所以你要討論什麼？純抒發請到FB 05/28 17:37
tzouandy28187樓自問自答也一篇 05/28 17:41
ko27tye8樓本來就是救急用的做法啊 是要討論什麼 05/28 17:45
b09200759樓還以為是在問程式執行速度，原來是開發時間 05/28 18:24
→ sos2012210樓如果胡亂模組化不如hardcode 05/28 18:36
wulouise11樓客戶坐在你後面現在究竟就要，慢慢refactor沒關係 05/28 18:41
MonkeyCL12樓重構留給學弟做啊 05/28 18:57
Csongs13樓你有比ai寫的快嗎 05/28 19:33
NDark14樓如果你的產品就是幾個月才動一次 一定大改 那不值得做系統 05/28 19:38
→ k7ji91ab5m15樓... 05/28 20:47
chuegou16樓就我狀況 維運別人的都盡量不重構 05/28 21:01
→ chuegou17樓自己的就重構到爆 過度設計也在所不惜 05/28 21:01
seal011218樓修線上產品問題用的啊 隔天上班有時間再重構 05/28 21:07
→ pot123419樓我覺得hard code快一點。需要橫跨的檔案比較少的話可以 05/28 21:39
→ pot123420樓快一點。解bug我就不知道要說啥了，困難到會有bug的話就 05/28 21:39
→ pot123421樓別亂寫啊… 05/28 21:39
→ BoXeX22樓一切就是看狀況 像我以前公司很愛在C用function pointer 05/28 23:39
→ BoXeX23樓模擬物件導向 結果維護麻煩的要死 05/28 23:40
→ BoXeX24樓debug 工具都沒辦法直接用 05/28 23:40
→ BoXeX25樓還不如分類簡單的if套娃 05/28 23:41
→ BoXeX26樓當然也不是說就不要抽象 但一些簡單的東西就保持簡單 05/28 23:45
→ BoXeX27樓白痴都能讀懂的code 就繼續讓白痴也能讀懂 05/28 23:46
→ NTUTM0428樓其實就急不急跟好不好修兩個metric衡量一下 05/29 00:12
viper970929樓推一樓 05/29 00:13
hakama9930樓我收到一個需求是某個按鈕在下個月其中三天要關閉，真的 05/29 00:20