PTT職涯區 / Soft_Job (軟體人)

[討論] hard code 速度會快嗎?

看板Soft_Job (軟體人)作者 (休息中)時間6月前 (2024/05/28 17:13), 編輯推噓23(27推 4噓 70→)
留言101則, 41人參與, 5月前最新討論串1/7 (看更多)
如題 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.html
推
05/28 17:29, 6月前 , 1F
這其實很吃當下情況跟判斷 我自己是能接受hard code來hot f
05/28 17:29, 1F
→
05/28 17:29, 6月前 , 2F
ix線上問題 事後在重構的
05/28 17:29, 2F
推
05/28 17:31, 6月前 , 3F
救火時間有限囉
05/28 17:31, 3F
推
05/28 17:31, 6月前 , 4F
試想半夜兩點接到電話要緊急維修 你會去想程式架構還是趕
05/28 17:31, 4F
→
05/28 17:31, 6月前 , 5F
快改好起床再調整 我相信大部分的人都會選後者
05/28 17:31, 5F
噓
05/28 17:37, 6月前 , 6F
所以你要討論什麼？純抒發請到FB
05/28 17:37, 6F
噓
05/28 17:41, 6月前 , 7F
自問自答也一篇
05/28 17:41, 7F
推
05/28 17:45, 6月前 , 8F
本來就是救急用的做法啊 是要討論什麼
05/28 17:45, 8F
推
05/28 18:24, 6月前 , 9F
還以為是在問程式執行速度，原來是開發時間
05/28 18:24, 9F
→
05/28 18:36, 6月前 , 10F
如果胡亂模組化不如hardcode
05/28 18:36, 10F
推
05/28 18:41, 6月前 , 11F
客戶坐在你後面現在究竟就要，慢慢refactor沒關係
05/28 18:41, 11F
推
05/28 18:57, 6月前 , 12F
重構留給學弟做啊
05/28 18:57, 12F
噓
05/28 19:33, 6月前 , 13F
你有比ai寫的快嗎
05/28 19:33, 13F
推
05/28 19:38, 6月前 , 14F
如果你的產品就是幾個月才動一次 一定大改 那不值得做系統
05/28 19:38, 14F
→
05/28 20:47, 6月前 , 15F
...
05/28 20:47, 15F
推
05/28 21:01, 6月前 , 16F
就我狀況 維運別人的都盡量不重構
05/28 21:01, 16F
→
05/28 21:01, 6月前 , 17F
自己的就重構到爆 過度設計也在所不惜
05/28 21:01, 17F
推
05/28 21:07, 6月前 , 18F
修線上產品問題用的啊 隔天上班有時間再重構
05/28 21:07, 18F
→
05/28 21:39, 6月前 , 19F
我覺得hard code快一點。需要橫跨的檔案比較少的話可以
05/28 21:39, 19F
→
05/28 21:39, 6月前 , 20F
快一點。解bug我就不知道要說啥了，困難到會有bug的話就
05/28 21:39, 20F
→
05/28 21:39, 6月前 , 21F
別亂寫啊…
05/28 21:39, 21F
→
05/28 23:39, 6月前 , 22F
一切就是看狀況 像我以前公司很愛在C用function pointer
05/28 23:39, 22F
→
05/28 23:40, 6月前 , 23F
模擬物件導向 結果維護麻煩的要死
05/28 23:40, 23F
→
05/28 23:40, 6月前 , 24F
debug 工具都沒辦法直接用
05/28 23:40, 24F
→
05/28 23:41, 6月前 , 25F
還不如分類簡單的if套娃
05/28 23:41, 25F
→
05/28 23:45, 6月前 , 26F
當然也不是說就不要抽象 但一些簡單的東西就保持簡單
05/28 23:45, 26F
→
05/28 23:46, 6月前 , 27F
白痴都能讀懂的code 就繼續讓白痴也能讀懂
05/28 23:46, 27F
→
05/29 00:12, 6月前 , 28F
其實就急不急跟好不好修兩個metric衡量一下
05/29 00:12, 28F
推
05/29 00:13, 6月前 , 29F
推一樓
05/29 00:13, 29F
推
05/29 00:20, 6月前 , 30F
我收到一個需求是某個按鈕在下個月其中三天要關閉，真的
05/29 00:20, 30F
→
05/29 00:20, 6月前 , 31F
要做api去開關這個按鈕也沒必要
05/29 00:20, 31F
推
05/29 00:38, 6月前 , 32F
設計到IDE都幫不了那種真的煩，後人根本不知道怎麼追
05/29 00:38, 32F
推
05/29 07:53, 5月前 , 33F
bug不會因為你抽成一個function就不見
05/29 07:53, 33F
推
05/29 07:57, 5月前 , 34F
hardcode也不會因為抽成function就不是hardcode, 你只是
05/29 07:57, 34F
→
05/29 07:57, 5月前 , 35F
把hardcode寫在一個function裡面罷了
05/29 07:57, 35F
→
05/29 09:04, 5月前 , 36F
那是因為你已經確定需求了
05/29 09:04, 36F
→
05/29 09:04, 5月前 , 37F
開發階段誰知道AB功能看起來這麼像
05/29 09:04, 37F
→
05/29 09:04, 5月前 , 38F
PM卻跑來說A要加啥米啥米但B不用
05/29 09:04, 38F
噓
05/29 09:08, 5月前 , 39F
你說的對，下班之前解決這個問題
05/29 09:08, 39F
還有 22 則推文
→
05/29 19:55, 5月前 , 62F
等需求穩定後再來重構絕對比每天慢慢磨擴充性花的總時間
05/29 19:55, 62F
→
05/29 19:55, 5月前 , 63F
少很多，但是如果你每天都工作早早做完閒閒沒事，做這些
05/29 19:55, 63F
→
05/29 19:55, 5月前 , 64F
就是用目前免費的高時間成本（大量閒閒沒事的時間）做以
05/29 19:55, 64F
→
05/29 19:55, 5月前 , 65F
後的事（原本需求穩定後才要做的重構）
05/29 19:55, 65F
推
05/29 20:04, 5月前 , 66F
與其寫高擴充性的 code，還不如寫方便重構的 code，例如
05/29 20:04, 66F
→
05/29 20:04, 5月前 , 67F
那種可以整段剪下貼上，沒有一堆生命週期、scope 等等考
05/29 20:04, 67F
→
05/29 20:04, 5月前 , 68F
量的 code
05/29 20:04, 68F
→
05/29 20:04, 5月前 , 69F
因為你做再多設想，也不可能知道還沒出現的需求是什麼，
05/29 20:04, 69F
→
05/29 20:04, 5月前 , 70F
你做的擴充性永遠都只是 hit or miss 而且還需要花大量
05/29 20:04, 70F
→
05/29 20:04, 5月前 , 71F
時間成本在設計，但寫容易重構的 code 需要的成本只是隨
05/29 20:04, 71F
→
05/29 20:04, 5月前 , 72F
手留意不要太高耦合、保持自己看得出來段落在哪的 copy-p
05/29 20:04, 72F
→
05/29 20:04, 5月前 , 73F
asteable 的 snippet 而已
05/29 20:04, 73F
推
05/29 20:07, 5月前 , 74F
跟客戶說明重構的重要性，使其接受
05/29 20:07, 74F
推
05/29 23:22, 5月前 , 75F
這問題很開放 只能說不同產業別 疊代開發的風氣差很多
05/29 23:22, 75F
→
05/30 01:20, 5月前 , 76F
不需要擴充性非常強阿 不然整理的意義何在？ 有一定
05/30 01:20, 76F
→
05/30 01:23, 5月前 , 77F
擴充性程式碼又乾淨簡潔很重要 超出擴充性範圍邊寫邊
05/30 01:23, 77F
→
05/30 01:24, 5月前 , 78F
改就好 也不需要多少時間 而不是東西狂堆爆炸了再給
05/30 01:24, 78F
→
05/30 01:25, 5月前 , 79F
其它人處理
05/30 01:25, 79F
→
05/30 01:28, 5月前 , 80F
無腦堆與重構的通常都不會是同一個人
05/30 01:28, 80F
→
05/30 05:05, 5月前 , 81F
"hard code" 是小問題啊，通常都很容易重構
05/30 05:05, 81F
→
05/30 05:05, 5月前 , 82F
我感覺你想講的應該是應急的 dirty code
05/30 05:05, 82F
→
05/30 05:06, 5月前 , 83F
我是建議真的有需要的話就寫，然後馬上重構
05/30 05:06, 83F
推
05/31 14:08, 5月前 , 84F
Hardcode本身就是一種workaround
05/31 14:08, 84F
推
05/31 17:58, 5月前 , 85F
現在都用AI寫code了還在clean code分大小寫才是笑話
05/31 17:58, 85F
推
05/31 18:01, 5月前 , 86F
實際上的hard code看起來就是個笑話,想偷工早點會去睡覺
05/31 18:01, 86F
→
05/31 18:01, 5月前 , 87F
*回去
05/31 18:01, 87F
推
05/31 18:13, 5月前 , 88F
實際重構的作法都是拿自己的時間時程塞進去一併做掉，其
05/31 18:13, 88F
→
05/31 18:13, 5月前 , 89F
一老闆不答應，主管不一定同意，有限度重構讓自己後續方
05/31 18:13, 89F
→
05/31 18:13, 5月前 , 90F
便才是重點
05/31 18:13, 90F
→
06/01 13:15, 5月前 , 91F
clean code?
06/01 13:15, 91F
→
06/02 01:42, 5月前 , 92F
看module吧.... 自己的屎自己扛 除非你想寫完離職
06/02 01:42, 92F
推
06/07 19:00, 5月前 , 93F
不想hardcode所以規劃了一堆modules，做完發現不可行
06/07 19:00, 93F
→
06/07 19:01, 5月前 , 94F
整個架構都必須大改，你前面的modules都變垃圾
06/07 19:01, 94F
→
06/07 19:02, 5月前 , 95F
直接扣腦筋不好的帽子好厲害喔，菜鳥
06/07 19:02, 95F
→
06/09 02:25, 5月前 , 96F
其實跟經驗有關…，入行發現有寫人做了10年程度一樣
06/09 02:25, 96F
→
06/09 02:25, 5月前 , 97F
有些人寫3-5年就超越了
06/09 02:25, 97F
→
06/09 20:21, 5月前 , 98F
與其討論怎麼做比較好，不如先想想你寫的code到底有何價
06/09 20:21, 98F
→
06/09 20:21, 5月前 , 99F
值，如果只是可有可無的功能怎麼寫都無所謂
06/09 20:21, 99F
推
06/09 22:06, 5月前 , 100F
hardcore是個好東西呀，不但可以短時間內把工作完成，而且
06/09 22:06, 100F
→
06/09 22:06, 5月前 , 101F
還可以留下地雷，給你的競爭對手，一舉兩得
06/09 22:06, 101F
‣ 更多 talkmyself 的文章
文章代碼(AID): #1cLQ1Bul (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 talkmyself 的文章
文章代碼(AID): #1cLQ1Bul (Soft_Job)