如題 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
所以會有技術債問題是腦筋不好造成的 不是趕工造成的
我的想法

這其實很吃當下情況跟判斷 我自己是能接受hard code來hot fix線上問題 事後在重構的

救火時間有限囉

試想半夜兩點接到電話要緊急維修 你會去想程式架構還是趕快改好起床再調整 我相信大部分的人都會選後者

所以你要討論什麼？純抒發請到FB

自問自答也一篇

本來就是救急用的做法啊 是要討論什麼

還以為是在問程式執行速度，原來是開發時間

如果胡亂模組化不如hardcode

客戶坐在你後面現在究竟就要，慢慢refactor沒關係

重構留給學弟做啊

你有比ai寫的快嗎

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

...

就我狀況 維運別人的都盡量不重構自己的就重構到爆 過度設計也在所不惜

修線上產品問題用的啊 隔天上班有時間再重構

我覺得hard code快一點。需要橫跨的檔案比較少的話可以快一點。解bug我就不知道要說啥了，困難到會有bug的話就別亂寫啊…

一切就是看狀況 像我以前公司很愛在C用function pointer模擬物件導向 結果維護麻煩的要死debug 工具都沒辦法直接用還不如分類簡單的if套娃當然也不是說就不要抽象 但一些簡單的東西就保持簡單白痴都能讀懂的code 就繼續讓白痴也能讀懂

其實就急不急跟好不好修兩個metric衡量一下

推一樓

我收到一個需求是某個按鈕在下個月其中三天要關閉，真的要做api去開關這個按鈕也沒必要

設計到IDE都幫不了那種真的煩，後人根本不知道怎麼追

bug不會因為你抽成一個function就不見hardcode也不會因為抽成function就不是hardcode, 你只是把hardcode寫在一個function裡面罷了

那是因為你已經確定需求了開發階段誰知道AB功能看起來這麼像PM卻跑來說A要加啥米啥米但B不用

你說的對，下班之前解決這個問題隨便你想怎麼 code

つcopilot

你都因為哈扣了還在意哈扣怎寫，有同步給團隊就好*因為速度

客戶站你後面 他非常火(哈扣/重構)

現在流行thread，你可以開一個發這樣的東西

我知道你想講的是workaround 而不是hardcode 對吧C不用function pointer 不要跟我講你會寫C

火燒屁股還在慢慢寫的腦筋才不好吧，等等客戶翻臉案子吹了看你的模組化能不能賺到錢

這種事情的邏輯與整理房間一樣的 做法也與整理防間房間雷同 雖然我也不太會整理房間 但我還算會整理code整都是持續在整理的 到後面變成垃圾堆的時候要整理就累趴 也很難從垃圾堆找出你要的東西 越早整後面就不用怎麼大掃除也就是重構 一開始就整理的成本也非常低 再找個收納盒好的櫃子也就是好的模組化方式就非常好至於樓主說的狀況 那不是隨便用個機制就搞定了嗎

可讀性和架構是給大專案用的，幾百幾千人的專案每個人都不會有 full picture，所以有一個架構師在做決策才重要幾十人的小專案做擴充性什麼的以開發效率來講絕對不高，等需求穩定後再來重構絕對比每天慢慢磨擴充性花的總時間少很多，但是如果你每天都工作早早做完閒閒沒事，做這些就是用目前免費的高時間成本（大量閒閒沒事的時間）做以後的事（原本需求穩定後才要做的重構）與其寫高擴充性的 code，還不如寫方便重構的 code，例如那種可以整段剪下貼上，沒有一堆生命週期、scope 等等考量的 code因為你做再多設想，也不可能知道還沒出現的需求是什麼，你做的擴充性永遠都只是 hit or miss 而且還需要花大量時間成本在設計，但寫容易重構的 code 需要的成本只是隨手留意不要太高耦合、保持自己看得出來段落在哪的 copy-pasteable 的 snippet 而已

跟客戶說明重構的重要性，使其接受

這問題很開放 只能說不同產業別 疊代開發的風氣差很多

不需要擴充性非常強阿 不然整理的意義何在？ 有一定擴充性程式碼又乾淨簡潔很重要 超出擴充性範圍邊寫邊改就好 也不需要多少時間 而不是東西狂堆爆炸了再給其它人處理無腦堆與重構的通常都不會是同一個人

"hard code" 是小問題啊，通常都很容易重構我感覺你想講的應該是應急的 dirty code我是建議真的有需要的話就寫，然後馬上重構

Hardcode本身就是一種workaround

現在都用AI寫code了還在clean code分大小寫才是笑話實際上的hard code看起來就是個笑話,想偷工早點會去睡覺*回去實際重構的作法都是拿自己的時間時程塞進去一併做掉，其一老闆不答應，主管不一定同意，有限度重構讓自己後續方便才是重點

clean code?

看module吧.... 自己的屎自己扛 除非你想寫完離職

不想hardcode所以規劃了一堆modules，做完發現不可行整個架構都必須大改，你前面的modules都變垃圾直接扣腦筋不好的帽子好厲害喔，菜鳥

其實跟經驗有關…，入行發現有寫人做了10年程度一樣有些人寫3-5年就超越了

與其討論怎麼做比較好，不如先想想你寫的code到底有何價值，如果只是可有可無的功能怎麼寫都無所謂

hardcore是個好東西呀，不但可以短時間內把工作完成，而且還可以留下地雷，給你的競爭對手，一舉兩得