PTT推薦

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

看板Soft_Job標題Re: [討論] hard code 速度會快嗎?作者
HZYSoft
(PCMan)
時間推噓25 推:25 噓:0 →:76

※ 引述《talkmyself (休息中)》之銘言:
: 如題 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
: 所以會有技術債問題是腦筋不好造成的 不是趕工造成的
: 我的想法

關鍵其實要看你的專案現在在哪個階段

1. 專案在非常早期:

這時候 hard code 有可能其實是最佳解。
此時需求不太很確定,可能經常修改。你現在看起來有幾段 code 很相似,
可以重構成共用 function,但不幸的是,幾個月後商業需求改變,他們的行為
越差越多,卻因為共用 code 造成難以擴充,改了這個就壞了那個,
明明差很多的邏輯,卻硬要共用,只會拖慢開發

另外是有時候還在探索可行的產品方向,prototyping 結束後決定捨棄,
那你就白費工夫在 refactor 了,這些 code 很快都是要 deprecate 的

在這些情況下,先 hard code 都是相對好的做法,呼應了不要 early optimization

2. 專案在穩定成長期:

這時候會慢慢添加新功能,但不會大幅度的改變,先 hard code 緊急修復,
把損害降到最低,接著註解寫下 TODO,並且留下 bug 連結供日後參考即可。
"農暇"之餘,再慢慢安排時間來 refactor 還債即可。
當然,如果開發時間充裕,那還是好好設計,一次把它做好比較好。

3. 專案不太會改,或在生命週期尾聲:

這時候直接 hard code 常常也是最佳解,花太多成本去 refactor 沒有什麼效益
這些 code 日後也不太會再改了,多只是維護工作,甚至系統隨後就會淘汰。
欠一些技術債沒還也還好,產品結束這些呆帳就打消了 XD

如果有在好好追蹤技術債,定期償還,視情況舉債,有時是一件好事情。
重點 hard code 的當下要留下註解,說明前因後果,並且開 bug 追蹤,
這樣日後不會忘記,要 refactor 也比較好搜尋到這些位置

補充:
註解的使用不是我想回的重點,重點是平衡短期和長期效益
按照當下的狀況,調整開發的步調。
建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup
或是有些緊急的修改有當下的時空背景,怕一忙沒法馬上清
日後有空要 refactor 的時候,回想不起來當時狀況。
註解不是描述 code 做了什麼,而是描述為什麼會有這 hack
至於 code 做了什麼,自然是 code 寫好讀 code 就懂了

--
Sent from PCMan on PCMan's PC

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.249.166.208 (臺灣)
PTT 網址

kurtsgm06/01 18:30倒數第二句真的是重點

kurtsgm06/01 18:30Hardcode又不留註解就是在雷

NDark06/01 18:42反註解派該出來說註解無用論了

k7ji91ab5m06/01 18:44反註解派不會認為hardcode不用註解

k7ji91ab5m06/01 18:45不懂在相輕甚麼

NDark06/01 18:46連縮排用tab還是空白都能相輕了 還有不懂的新警察

testPtt06/01 19:16打開專案心情就很差的感覺 refactor還是越早越好

B098869808806/01 19:16有反註解派哦?那他們怎麼處理需要註解的情境?通靈

B098869808806/01 19:16

ab4daa06/01 19:28果然無限QE怎麼輸

abccbaandy06/01 19:34結論:hard code就對了(?

angusyu06/01 20:28你的結論就是怎樣哈扣都可以,真是可愛

za75518806/01 20:40樓上懷疑PCMan嗎?

pyCassandra06/01 20:43推PCMan

wei11506/01 20:44哈扣真的不是最差的選擇

labbat06/01 22:30反註解派:程式碼即為說明書,程式碼即為文件,不hardcode

labbat06/01 22:31寫出來的就是所有人應該看懂的常識

CRPKT06/01 22:47我推薦使用 ad-hoc 這個字取代 hard code

peter9806/01 22:49反註解派說程式碼即為所以不用寫註解的觀點沒有錯,但是

peter9806/01 22:49反註解派的最大的問題是,他們對於自己的code太有自信,

peter9806/01 22:50這是華人教育的傳統問題,華人教育是文章看不懂是讀者的

peter9806/01 22:50問題。

peter9806/01 22:51反註解派說程式碼即為"說明書"所以不用寫註解的觀點*

VL100306/01 22:54反註解派的想法沒問題,就跟共產主義也沒問題,但實作就是

VL100306/01 22:55問題一堆,理念很美好,但現實超難達成。

tsaigi06/01 23:06反註解派反的是那種無用的註解吧 例如這裡呼叫xxx 之類看

tsaigi06/01 23:06code比看註解還有用的地方

kurtsgm06/01 23:16不用註解的前提是程式碼的命名、邏輯、流程都能簡單讀懂

kurtsgm06/01 23:17但通常會用hard code去解決問題一定有當時的時空背景在

t6414106/01 23:17但實際上常常是:專案早期 hardcode勇敢欠債,成長期沒空

t6414106/01 23:17改,穩定期東西沒壞就不要亂改(或已經改不動了)

kurtsgm06/01 23:17或是用通則無法解決 ...

kurtsgm06/01 23:17這種情況下後面再回頭看code只能靠回憶 幾乎無法單純讀懂

t6414106/01 23:20至於註解不是寫不寫的問題,反而比較像是"如何適當使用註

t6414106/01 23:20解"

HZYSoft06/02 00:07註解的使用不是我想回的重點,重點是平衡短期和長期效益

HZYSoft06/02 00:07按照當下的狀況,調整開發的步調。

HZYSoft06/02 00:08建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup

HZYSoft06/02 00:09或是有些緊急的修改有當下的時空背景,怕一忙沒法馬上清

HZYSoft06/02 00:09日後有空要 refactor 的時候,回想不起來當時狀況。

HZYSoft06/02 00:09註解不是描述 code 做了什麼,而是描述為什麼會有這 hack

HZYSoft06/02 00:10至於 code 做了什麼,自然是 code 寫好讀 code 就懂了

※ 編輯: HZYSoft (111.249.166.208 臺灣), 06/02/2024 00:11:39

viper970906/02 00:46推這篇專業

henrylin808606/02 01:00前期就幹模組化確實滿浪費時間的,不確定性高又有d

henrylin808606/02 01:00emo去喊芭樂拳的需求,直接hardcode省事。我的情境

henrylin808606/02 01:00是專案中期會整個系統連程式語言都大改,這邊再開

henrylin808606/02 01:00始做模組化都還來得及。

mmonkeyboyy06/02 01:43我是都看專案的arch 兩著會連動

mmonkeyboyy06/02 01:44其實很合文主說的前面快速後面還債 反正有空能還

mmonkeyboyy06/02 01:44寫面太認真 後面要裝忙也很累

jack020406/02 10:52有的時候要先搶時間弄MVP驗證市場或技術方案

jack020406/02 10:54會寫得很亂,但要有文件歸納重點方便日後重寫或重構

jack020406/02 10:56與其說hardcode不好,不如說很多人技術不熟練只會這樣做

jack020406/02 10:59順便說臨時修程式大多hardcode是因為你凌晨4點被call

jack020406/02 11:00大概也沒心弄得很漂亮,只是幾天內要記得重構

za75518806/02 16:14不夠清楚的需求沒必要過度最佳化 但又有多少需求是清楚

za75518806/02 16:14的呢?

superpandal06/02 17:26不過是不重構的藉口罷了 你不能保證你寫出來的都很清

superpandal06/02 17:28爽 堆到後面你不考慮共用還債就是推給別人還 這種也

superpandal06/02 17:29是種垃圾行為 當然好的方向想就是不喜歡被鳥盡弓藏

superpandal06/02 17:31不做模組化給後面的人爽而已 是否可以共用那也是看

superpandal06/02 17:32個人功力 只要寫的顯式即可

superpandal06/02 17:34未知才會拖慢開發速度 而不是已知 已知只要你對語言

superpandal06/02 17:35不是很不熟或惡搞都能完善到底

superpandal06/02 17:39然而這樣搞對你來講也許可以算已知 對接手的人就是未

superpandal06/02 17:40知了 要花成倍心思去解決 當然不寫注解要求就是寫的

superpandal06/02 17:42好 複雜需求簡歸納簡化 達成可以顯式除錯而不用通靈

superpandal06/02 17:45然而依照你上面這樣搞對你來講可以算已知

superpandal06/02 17:50至於如何共用的更好講究的是邏輯圓融 天人合一

superpandal06/02 18:00要達到樓主講的流程趨勢 對整潔本來就要有一定要求

superpandal06/02 18:01否則自己寫的都看不懂了 不要說別人 往後才會有下一

superpandal06/02 18:02

superpandal06/02 18:05講到底最重要的還是整齊 模組化都不用搞到很高大上

superpandal06/02 18:06畢竟搞太多就會隱藏細節

andy005506/02 21:40推 倒數第二行話…

andy005506/02 21:41寫了一堆註解,結果關鍵的地雷卻不寫….

gmoz06/03 10:18註解最大作用就是拿來貼Jira或confluence連結XD

Araiman06/03 13:52有些事要做過大專案 踩過坑流過淚才能體會了

Lipraxde06/03 15:13"註解不是描述 code 做了什麼,而是描述為什麼會有這 h

Lipraxde06/03 15:13ack"...不只是 hack,平常寫註解本來就該以補充程式碼

Lipraxde06/03 15:13以外的資訊、解釋由來為主,看一堆解釋底下程式碼在做

Lipraxde06/03 15:13什麼操作的註解...當作是在寫教學用的 sample code,看

Lipraxde06/03 15:13著浪費視覺空間

TonyQ06/03 15:17//這裡定義了變數 a=1

TonyQ06/03 15:17 var a=1; //你不寫註解我也知道

GDaaaa06/03 16:29

shooter55506/03 23:54// 註解是用來說這段垃圾code 是上層交代 不要怪我

becca94506/04 00:16TODO: someone else do

sb888806/04 13:06我會留著hardcode的代碼重構 這樣不好嗎

sb888806/04 13:07直接開個v2 這樣

fatb06/04 17:10根據經驗不會有時間重構 如果能讓你有時間重構 那是PM時間

fatb06/04 17:11壓得不夠緊 所以最好還是一次寫好

fatb06/04 17:12尾聲部份就同意 最好寫得越簡單越笨越好 免得前面的大量測試

fatb06/04 17:13做白工 (雖然一改都還是要重測 但出事就會被放大)

eva1945200206/04 19:30不是說有一派主張不要寫註解,只要var和func名稱取得

eva1945200206/04 19:31好,再加上程式內聚力強,就可以看懂程式在做什麼了

brucetu06/04 19:57看得懂程式在做什麼不一定看得懂為什麼要做這件事啊所以

brucetu06/04 19:57才要註解

w000515106/04 22:41對code有太多理想的人多半沒做過大專案

viper970906/05 00:37看得懂程式在做什麼不一定懂為什麼要這樣做+1

fatb06/05 10:04不一定是沒做過大專案 還有一種是主管職願意假日花時間那種