[討論] hard code 速度會快嗎?
如題 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 f
ix線上問題 事後在重構的
救火時間有限囉
試想半夜兩點接到電話要緊急維修 你會去想程式架構還是趕
快改好起床再調整 我相信大部分的人都會選後者
所以你要討論什麼?純抒發請到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-p
asteable 的 snippet 而已
跟客戶說明重構的重要性,使其接受
這問題很開放 只能說不同產業別 疊代開發的風氣差很多
不需要擴充性非常強阿 不然整理的意義何在? 有一定
擴充性程式碼又乾淨簡潔很重要 超出擴充性範圍邊寫邊
改就好 也不需要多少時間 而不是東西狂堆爆炸了再給
其它人處理
無腦堆與重構的通常都不會是同一個人
"hard code" 是小問題啊,通常都很容易重構
我感覺你想講的應該是應急的 dirty code
我是建議真的有需要的話就寫,然後馬上重構
Hardcode本身就是一種workaround
現在都用AI寫code了還在clean code分大小寫才是笑話
實際上的hard code看起來就是個笑話,想偷工早點會去睡覺
*回去
實際重構的作法都是拿自己的時間時程塞進去一併做掉,其
一老闆不答應,主管不一定同意,有限度重構讓自己後續方
便才是重點
25
關鍵其實要看你的專案現在在哪個階段 1. 專案在非常早期: 這時候 hard code 有可能其實是最佳解。 此時需求不太很確定,可能經常修改。你現在看起來有幾段 code 很相似, 可以重構成共用 function,但不幸的是,幾個月後商業需求改變,他們的行為7
都說是做專案了,又不是做產品。 做專案當然是做完收錢,Meet Dealine,所以重點是, 照案主的需求,改成他要的,照資安需求,修掉有問題的地方。好好上線。 一案結束,就下一案來了,你還有空refactor? 誰billing你? 我是真的不明白ptt 上一堆天天refactor 掛嘴邊的。2
你講這個就代表你們公司(或工作室?)甚至於你個人 完全沒有經營codebase的習慣 我敢這樣說有幾個簡單的推論: 1. 如果你們是接案公司,接的案子種類應該不會南轅北轍 2. 如果你們是接案公司真的一天到晚在接五花八門domain的專案,那代表你們的競爭15
再吐一下天天refactor 的,在台灣你可以看到一堆公司,都有自己的產品, 就是接案子後,用原案的CODE重包出來的:產品。 然後,根本賣不動,這樣要你老闆BILLING你的閒著沒事做去re-fat-tor? 號稱精進系統,使系統更好what? 這下問題大了,何謂"更好"?如何衡量?1
re code 就是一個個人意願的問題,跟 code 是誰的財產無關,你雇用一個 coder 就等 於授權他來改你的 code,跟你請一個清潔人員來家裡打掃,跟你的房子是不是他的財產 無關。 還有人回說要經過股東同意才能歐push code咧,看到真是讓人噴飯,是多麼迷你的公司 會有股東跑來管這個?
38
Re: [討論] 工作時一天coding的時間我覺得you對programming(台灣title比較浮誇 RD)有些misunderstand 實際上真正需要brain storming的時間 可說是少之又少 真的要BS也輪不到你這種菜鳥來BS BS出來最後也是滿口BS 程式開發是不斷iteration 確實是會有構想階段沒錯(看高度 程度越低就越不需要動腦)35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來27
Re: 不想唸碩士了,想去刷題個人覺得刷題跟工作有個不同的點 工作常遇到的一個問題是"如何維護大型專案" 不同類型的工作,專案規模多少有差 純軟來講,很容易遇到破百個檔案的大型專案 規格說改就改,大部分時候是努力讓一堆髒code拼在一起後還能運作....20
Re: [討論] 所謂的開發強者是怎麼樣子的?^^^^^^^^^^^^^^^^^^^^^^ : 管理 1000+ servers、每年幫公司節省一百萬美金(?) machine cost : 1. 硬實力上 : 他很擅長在不同專案、codebases 中穿梭,幾天就能看穿並理解背後的邏輯和設計脈絡 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^21
Re: [討論] 系統越開發越多,負責的東西越來越多(恕刪) : 問題是身為資深成員的你,可否提出數據說明工程宅們整天在吵的code quality到底跟業 : 務的關係在哪 : 是不是做同樣規模的feature要花的時間越來越多 : 是不是release後常常出問題要修17
Re: [代發] 無背景自學想求職[有作品(更新中)]閒聊一下,如果你是公司的用人主管,會給他offer嗎? 從完整的履歷上來看可以得到幾個資訊 1. 非本科系 2. 高職畢業 3. 有自學能力17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳16
[請益] 如何有效益的維護data loader如題 目前做的project架構長這樣 Loader1 Loader2 Loader3 ........... Loader30 Area 1 Area 21
[閒聊] Linux pine64 phoneHum 超級 hard code 手機真的可以用了 而且還可以打指令集 手機 coding 的日子不遠了(逃2
Re: [心情] 工作的內容被放大檢視我怎麼覺得是在找麻煩, 不管是老鳥,還是主管,我就不相信有人可以 速度十分快又完全沒有任何bug,程式精簡到沒任何一絲一毫多餘的斷行 tab或空白或多 餘效率不好的code,或程式中有重覆使用的code(沒精簡包在fuction中) 沒任何bug代表寫完要不斷測試所有各種可能的case,這