看板 Soft_Job
※ 引述《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.cc), 來自: 111.249.166.208 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1717233115.A.3ED.html
kurtsgm: 倒數第二句真的是重點 06/01 18:30
kurtsgm: Hardcode又不留註解就是在雷 06/01 18:30
NDark: 反註解派該出來說註解無用論了 06/01 18:42
k7ji91ab5m: 反註解派不會認為hardcode不用註解 06/01 18:44
Kroner: 魚油 06/02 00:07
k7ji91ab5m: 不懂在相輕甚麼 06/01 18:45
NDark: 連縮排用tab還是空白都能相輕了 還有不懂的新警察 06/01 18:46
testPtt: 打開專案心情就很差的感覺 refactor還是越早越好 06/01 19:16
Kroner: 益生菌推薦 06/02 00:09
B0988698088: 有反註解派哦?那他們怎麼處理需要註解的情境?通靈 06/01 19:16
B0988698088: 嗎 06/01 19:16
ab4daa: 果然無限QE怎麼輸 06/01 19:28
Kroner: uc2功效 06/02 00:46
abccbaandy: 結論:hard code就對了(? 06/01 19:34
angusyu: 你的結論就是怎樣哈扣都可以,真是可愛 06/01 20:28
za755188: 樓上懷疑PCMan嗎? 06/01 20:40
Chricey: omega 3 06/02 01:00
pyCassandra: 推PCMan 06/01 20:43
wei115: 哈扣真的不是最差的選擇 06/01 20:44
labbat: 反註解派:程式碼即為說明書,程式碼即為文件,不hardcode 06/01 22:30
Chricey: 06/02 01:44
labbat: 寫出來的就是所有人應該看懂的常識 06/01 22:31
CRPKT: 我推薦使用 ad-hoc 這個字取代 hard code 06/01 22:47
peter98: 反註解派說程式碼即為所以不用寫註解的觀點沒有錯,但是 06/01 22:49
Chricey: omega 3 06/02 10:54
peter98: 反註解派的最大的問題是,他們對於自己的code太有自信, 06/01 22:49
peter98: 這是華人教育的傳統問題,華人教育是文章看不懂是讀者的 06/01 22:50
peter98: 問題。 06/01 22:50
Kroner: 透納葉 06/02 11:00
peter98: 反註解派說程式碼即為"說明書"所以不用寫註解的觀點* 06/01 22:51
VL1003: 反註解派的想法沒問題,就跟共產主義也沒問題,但實作就是 06/01 22:54
VL1003: 問題一堆,理念很美好,但現實超難達成。 06/01 22:55
Kroner: 魚油 06/02 17:26
tsaigi: 反註解派反的是那種無用的註解吧 例如這裡呼叫xxx 之類看 06/01 23:06
tsaigi: code比看註解還有用的地方 06/01 23:06
kurtsgm: 不用註解的前提是程式碼的命名、邏輯、流程都能簡單讀懂 06/01 23:16
Chricey: 甘露糖 06/02 17:31
kurtsgm: 但通常會用hard code去解決問題一定有當時的時空背景在 06/01 23:17
t64141: 但實際上常常是:專案早期 hardcode勇敢欠債,成長期沒空 06/01 23:17
t64141: 改,穩定期東西沒壞就不要亂改(或已經改不動了) 06/01 23:17
Kroner: 魚油 06/02 17:35
kurtsgm: 或是用通則無法解決 ... 06/01 23:17
kurtsgm: 這種情況下後面再回頭看code只能靠回憶 幾乎無法單純讀懂 06/01 23:17
t64141: 至於註解不是寫不寫的問題,反而比較像是"如何適當使用註 06/01 23:20
Chricey: UC2推薦 06/02 17:42
t64141: 解" 06/01 23:20
HZYSoft: 註解的使用不是我想回的重點,重點是平衡短期和長期效益 06/02 00:07
HZYSoft: 按照當下的狀況,調整開發的步調。 06/02 00:07
Kroner: 透納葉 06/02 00:07
HZYSoft: 建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup 06/02 00:08
HZYSoft: 或是有些緊急的修改有當下的時空背景,怕一忙沒法馬上清 06/02 00:09
HZYSoft: 日後有空要 refactor 的時候,回想不起來當時狀況。 06/02 00:09
Chricey: gaba 06/02 00:09
HZYSoft: 註解不是描述 code 做了什麼,而是描述為什麼會有這 hack 06/02 00:09
HZYSoft: 至於 code 做了什麼,自然是 code 寫好讀 code 就懂了 06/02 00:10
※ 編輯: HZYSoft (111.249.166.208 臺灣), 06/02/2024 00:11:39
viper9709: 推這篇專業 06/02 00:46
Kroner: UC2 06/02 00:46
henrylin8086: 前期就幹模組化確實滿浪費時間的,不確定性高又有d 06/02 01:00
henrylin8086: emo去喊芭樂拳的需求,直接hardcode省事。我的情境 06/02 01:00
henrylin8086: 是專案中期會整個系統連程式語言都大改,這邊再開 06/02 01:00
Kroner: 苦瓜胜肽功效 06/02 01:00
henrylin8086: 始做模組化都還來得及。 06/02 01:00
mmonkeyboyy: 我是都看專案的arch 兩著會連動 06/02 01:43
mmonkeyboyy: 其實很合文主說的前面快速後面還債 反正有空能還 06/02 01:44
Chricey: 瑪卡功效女性 06/02 01:44
mmonkeyboyy: 寫面太認真 後面要裝忙也很累 06/02 01:44
jack0204: 有的時候要先搶時間弄MVP驗證市場或技術方案 06/02 10:52
jack0204: 會寫得很亂,但要有文件歸納重點方便日後重寫或重構 06/02 10:54
Chricey: 馬卡 06/02 10:54
jack0204: 與其說hardcode不好,不如說很多人技術不熟練只會這樣做 06/02 10:56
jack0204: 順便說臨時修程式大多hardcode是因為你凌晨4點被call 06/02 10:59
jack0204: 大概也沒心弄得很漂亮,只是幾天內要記得重構 06/02 11:00
Kroner: 蔓越莓益生菌推薦dcard 06/02 11:00
za755188: 不夠清楚的需求沒必要過度最佳化 但又有多少需求是清楚 06/02 16:14
za755188: 的呢? 06/02 16:14
superpandal: 不過是不重構的藉口罷了 你不能保證你寫出來的都很清 06/02 17:26
Kroner: 蔓越莓益生菌 06/02 17:26
superpandal: 爽 堆到後面你不考慮共用還債就是推給別人還 這種也 06/02 17:28
superpandal: 是種垃圾行為 當然好的方向想就是不喜歡被鳥盡弓藏 06/02 17:29
superpandal: 不做模組化給後面的人爽而已 是否可以共用那也是看 06/02 17:31
Chricey: UC2推薦 06/02 17:31
superpandal: 個人功力 只要寫的顯式即可 06/02 17:32
superpandal: 未知才會拖慢開發速度 而不是已知 已知只要你對語言 06/02 17:34
superpandal: 不是很不熟或惡搞都能完善到底 06/02 17:35
Kroner: 魚油功效 06/02 17:35
superpandal: 然而這樣搞對你來講也許可以算已知 對接手的人就是未 06/02 17:39
superpandal: 知了 要花成倍心思去解決 當然不寫注解要求就是寫的 06/02 17:40
superpandal: 好 複雜需求簡歸納簡化 達成可以顯式除錯而不用通靈 06/02 17:42
Kroner: GABA 06/02 17:42
superpandal: 然而依照你上面這樣搞對你來講可以算已知 06/02 17:45
superpandal: 至於如何共用的更好講究的是邏輯圓融 天人合一 06/02 17:50
superpandal: 要達到樓主講的流程趨勢 對整潔本來就要有一定要求 06/02 18:00
superpandal: 否則自己寫的都看不懂了 不要說別人 往後才會有下一 06/02 18:01
superpandal: 步 06/02 18:02
superpandal: 講到底最重要的還是整齊 模組化都不用搞到很高大上 06/02 18:05
superpandal: 畢竟搞太多就會隱藏細節 06/02 18:06
andy0055: 推 倒數第二行話… 06/02 21:40
andy0055: 寫了一堆註解,結果關鍵的地雷卻不寫…. 06/02 21:41
gmoz: 註解最大作用就是拿來貼Jira或confluence連結XD 06/03 10:18
Araiman: 有些事要做過大專案 踩過坑流過淚才能體會了 06/03 13:52
Lipraxde: "註解不是描述 code 做了什麼,而是描述為什麼會有這 h 06/03 15:13
Lipraxde: ack"...不只是 hack,平常寫註解本來就該以補充程式碼 06/03 15:13
Lipraxde: 以外的資訊、解釋由來為主,看一堆解釋底下程式碼在做 06/03 15:13
Lipraxde: 什麼操作的註解...當作是在寫教學用的 sample code,看 06/03 15:13
Lipraxde: 著浪費視覺空間 06/03 15:13
TonyQ: //這裡定義了變數 a=1 06/03 15:17
TonyQ: var a=1; //你不寫註解我也知道 06/03 15:17
GDaaaa: 推 06/03 16:29
shooter555: // 註解是用來說這段垃圾code 是上層交代 不要怪我 06/03 23:54
becca945: TODO: someone else do 06/04 00:16
sb8888: 我會留著hardcode的代碼重構 這樣不好嗎 06/04 13:06
sb8888: 直接開個v2 這樣 06/04 13:07
fatb: 根據經驗不會有時間重構 如果能讓你有時間重構 那是PM時間 06/04 17:10
fatb: 壓得不夠緊 所以最好還是一次寫好 06/04 17:11
fatb: 尾聲部份就同意 最好寫得越簡單越笨越好 免得前面的大量測試 06/04 17:12
fatb: 做白工 (雖然一改都還是要重測 但出事就會被放大) 06/04 17:13
eva19452002: 不是說有一派主張不要寫註解,只要var和func名稱取得 06/04 19:30
eva19452002: 好,再加上程式內聚力強,就可以看懂程式在做什麼了 06/04 19:31
brucetu: 看得懂程式在做什麼不一定看得懂為什麼要做這件事啊所以 06/04 19:57
brucetu: 才要註解 06/04 19:57
w0005151: 對code有太多理想的人多半沒做過大專案 06/04 22:41
viper9709: 看得懂程式在做什麼不一定懂為什麼要這樣做+1 06/05 00:37
fatb: 不一定是沒做過大專案 還有一種是主管職願意假日花時間那種 06/05 10:04
wistful96: 推 06/07 11:05