PTT推薦

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

看板Soft_Job標題[討論] hard code 速度會快嗎?作者
talkmyself
(休息中)
時間推噓21 推:25 噓:4 →:61

如題 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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 203.67.103.85 (臺灣)
PTT 網址

Hnash05/28 17:29這其實很吃當下情況跟判斷 我自己是能接受hard code來hot f

Hnash05/28 17:29ix線上問題 事後在重構的

cutearia05/28 17:31救火時間有限囉

Hnash05/28 17:31試想半夜兩點接到電話要緊急維修 你會去想程式架構還是趕

Hnash05/28 17:31快改好起床再調整 我相信大部分的人都會選後者

B098869808805/28 17:37所以你要討論什麼?純抒發請到FB

tzouandy281805/28 17:41自問自答也一篇

ko27tye05/28 17:45本來就是救急用的做法啊 是要討論什麼

b092007505/28 18:24還以為是在問程式執行速度,原來是開發時間

sos2012205/28 18:36如果胡亂模組化不如hardcode

wulouise05/28 18:41客戶坐在你後面現在究竟就要,慢慢refactor沒關係

MonkeyCL05/28 18:57重構留給學弟做啊

Csongs05/28 19:33你有比ai寫的快嗎

NDark05/28 19:38如果你的產品就是幾個月才動一次 一定大改 那不值得做系統

k7ji91ab5m05/28 20:47...

chuegou05/28 21:01就我狀況 維運別人的都盡量不重構

chuegou05/28 21:01自己的就重構到爆 過度設計也在所不惜

seal011205/28 21:07修線上產品問題用的啊 隔天上班有時間再重構

pot123405/28 21:39我覺得hard code快一點。需要橫跨的檔案比較少的話可以

pot123405/28 21:39快一點。解bug我就不知道要說啥了,困難到會有bug的話就

pot123405/28 21:39別亂寫啊…

BoXeX05/28 23:39一切就是看狀況 像我以前公司很愛在C用function pointer

BoXeX05/28 23:40模擬物件導向 結果維護麻煩的要死

BoXeX05/28 23:40debug 工具都沒辦法直接用

BoXeX05/28 23:41還不如分類簡單的if套娃

BoXeX05/28 23:45當然也不是說就不要抽象 但一些簡單的東西就保持簡單

BoXeX05/28 23:46白痴都能讀懂的code 就繼續讓白痴也能讀懂

NTUTM0405/29 00:12其實就急不急跟好不好修兩個metric衡量一下

viper970905/29 00:13推一樓

hakama9905/29 00:20我收到一個需求是某個按鈕在下個月其中三天要關閉,真的

hakama9905/29 00:20要做api去開關這個按鈕也沒必要

abccbaandy05/29 00:38設計到IDE都幫不了那種真的煩,後人根本不知道怎麼追

DDR67805/29 07:53bug不會因為你抽成一個function就不見

DDR67805/29 07:57hardcode也不會因為抽成function就不是hardcode, 你只是

DDR67805/29 07:57把hardcode寫在一個function裡面罷了

lazarus112105/29 09:04那是因為你已經確定需求了

lazarus112105/29 09:04開發階段誰知道AB功能看起來這麼像

lazarus112105/29 09:04PM卻跑來說A要加啥米啥米但B不用

brucetu05/29 09:08你說的對,下班之前解決這個問題

brucetu05/29 09:08隨便你想怎麼 code

yamagishi05/29 11:00つcopilot

Suleika05/29 12:04你都因為哈扣了還在意哈扣怎寫,有同步給團隊就好

Suleika05/29 12:04*因為速度

dapple05/29 13:10客戶站你後面 他非常火(哈扣/重構)

jyunwei05/29 13:41現在流行thread,你可以開一個發這樣的東西

shooter55505/29 13:52我知道你想講的是workaround 而不是hardcode 對吧

shooter55505/29 13:55C不用function pointer 不要跟我講你會寫C

wade243205/29 16:48火燒屁股還在慢慢寫的腦筋才不好吧,等等客戶翻臉案子

wade243205/29 16:48吹了看你的模組化能不能賺到錢

superpandal05/29 18:10這種事情的邏輯與整理房間一樣的 做法也與整理防間

superpandal05/29 18:10房間

superpandal05/29 18:12雷同 雖然我也不太會整理房間 但我還算會整理code

superpandal05/29 18:13整都是持續在整理的 到後面變成垃圾堆的時候要整理就

superpandal05/29 18:15累趴 也很難從垃圾堆找出你要的東西 越早整後面就不

superpandal05/29 18:16用怎麼大掃除也就是重構 一開始就整理的成本也非常

superpandal05/29 18:18低 再找個收納盒好的櫃子也就是好的模組化方式就非常

superpandal05/29 18:20

superpandal05/29 18:24至於樓主說的狀況 那不是隨便用個機制就搞定了嗎

CoNsTaR05/29 19:55可讀性和架構是給大專案用的,幾百幾千人的專案每個人都

CoNsTaR05/29 19:55不會有 full picture,所以有一個架構師在做決策才重要

CoNsTaR05/29 19:55幾十人的小專案做擴充性什麼的以開發效率來講絕對不高,

CoNsTaR05/29 19:55等需求穩定後再來重構絕對比每天慢慢磨擴充性花的總時間

CoNsTaR05/29 19:55少很多,但是如果你每天都工作早早做完閒閒沒事,做這些

CoNsTaR05/29 19:55就是用目前免費的高時間成本(大量閒閒沒事的時間)做以

CoNsTaR05/29 19:55後的事(原本需求穩定後才要做的重構)

CoNsTaR05/29 20:04與其寫高擴充性的 code,還不如寫方便重構的 code,例如

CoNsTaR05/29 20:04那種可以整段剪下貼上,沒有一堆生命週期、scope 等等考

CoNsTaR05/29 20:04量的 code

CoNsTaR05/29 20:04因為你做再多設想,也不可能知道還沒出現的需求是什麼,

CoNsTaR05/29 20:04你做的擴充性永遠都只是 hit or miss 而且還需要花大量

CoNsTaR05/29 20:04時間成本在設計,但寫容易重構的 code 需要的成本只是隨

CoNsTaR05/29 20:04手留意不要太高耦合、保持自己看得出來段落在哪的 copy-p

CoNsTaR05/29 20:04asteable 的 snippet 而已

new12285105/29 20:07跟客戶說明重構的重要性,使其接受

jhjhs3350405/29 23:22這問題很開放 只能說不同產業別 疊代開發的風氣差很多

superpandal05/30 01:20不需要擴充性非常強阿 不然整理的意義何在? 有一定

superpandal05/30 01:23擴充性程式碼又乾淨簡潔很重要 超出擴充性範圍邊寫邊

superpandal05/30 01:24改就好 也不需要多少時間 而不是東西狂堆爆炸了再給

superpandal05/30 01:25其它人處理

superpandal05/30 01:28無腦堆與重構的通常都不會是同一個人

RumiManiac05/30 05:05"hard code" 是小問題啊,通常都很容易重構

RumiManiac05/30 05:05我感覺你想講的應該是應急的 dirty code

RumiManiac05/30 05:06我是建議真的有需要的話就寫,然後馬上重構

wang1998053105/31 14:08Hardcode本身就是一種workaround

prag22205/31 17:58現在都用AI寫code了還在clean code分大小寫才是笑話

prag22205/31 18:01實際上的hard code看起來就是個笑話,想偷工早點會去睡覺

prag22205/31 18:01*回去

prag22205/31 18:13實際重構的作法都是拿自己的時間時程塞進去一併做掉,其

prag22205/31 18:13一老闆不答應,主管不一定同意,有限度重構讓自己後續方

prag22205/31 18:13便才是重點