※ 引述《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.org.tw), 來自: 111.249.166.208 (臺灣) ※ 文章網址: https://ptt.org.tw/Soft_Job/M.1717233115.A.3ED

推 kurtsgm: 倒數第二句真的是重點 06/01 18:30

→ kurtsgm: Hardcode又不留註解就是在雷 06/01 18:30

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

推 k7ji91ab5m: 反註解派不會認為hardcode不用註解 06/01 18:44

→ k7ji91ab5m: 不懂在相輕甚麼 06/01 18:45

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

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

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

→ B0988698088: 嗎 06/01 19:16

推 ab4daa: 果然無限QE怎麼輸 06/01 19:28

推 abccbaandy: 結論：hard code就對了(？ 06/01 19:34

→ angusyu: 你的結論就是怎樣哈扣都可以，真是可愛 06/01 20:28

推 za755188: 樓上懷疑PCMan嗎? 06/01 20:40

推 pyCassandra: 推PCMan 06/01 20:43

推 wei115: 哈扣真的不是最差的選擇 06/01 20:44

→ labbat: 反註解派：程式碼即為說明書，程式碼即為文件，不hardcode 06/01 22:30

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

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

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

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

→ peter98: 這是華人教育的傳統問題，華人教育是文章看不懂是讀者的 06/01 22:50

→ peter98: 問題。 06/01 22:50

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

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

→ VL1003: 問題一堆，理念很美好，但現實超難達成。 06/01 22:55

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

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

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

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

推 t64141: 但實際上常常是：專案早期 hardcode勇敢欠債，成長期沒空 06/01 23:17

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

→ kurtsgm: 或是用通則無法解決 ... 06/01 23:17

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

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

→ t64141: 解" 06/01 23:20

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

→ HZYSoft: 按照當下的狀況，調整開發的步調。 06/02 00:07

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

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

→ HZYSoft: 日後有空要 refactor 的時候，回想不起來當時狀況。 06/02 00:09

→ HZYSoft: 註解不是描述 code 做了什麼，而是描述為什麼會有這 hack 06/02 00:09

→ HZYSoft: 至於 code 做了什麼，自然是 code 寫好讀 code 就懂了 06/02 00:10

推 viper9709: 推這篇專業 06/02 00:46

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

→ henrylin8086: emo去喊芭樂拳的需求，直接hardcode省事。我的情境 06/02 01:00

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

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

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

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

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

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

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

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

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

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

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

→ za755188: 的呢? 06/02 16:14

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

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

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

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

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

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

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

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

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

→ superpandal: 好 複雜需求簡歸納簡化 達成可以顯式除錯而不用通靈 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: 根據經驗不會有時間重構 如果能讓你有時間重構 那是ＰＭ時間 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