PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (PCMan)時間5月前 (2024/06/01 17:11), 5月前編輯推噓26(26推 0噓 76→)
留言102則, 37人參與, 5月前最新討論串2/7 (看更多)
※ 引述《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
推
06/01 18:30, 5月前 , 1F
倒數第二句真的是重點
06/01 18:30, 1F
→
06/01 18:30, 5月前 , 2F
Hardcode又不留註解就是在雷
06/01 18:30, 2F
→
06/01 18:42, 5月前 , 3F
反註解派該出來說註解無用論了
06/01 18:42, 3F
推
06/01 18:44, 5月前 , 4F
反註解派不會認為hardcode不用註解
06/01 18:44, 4F
→
06/01 18:45, 5月前 , 5F
不懂在相輕甚麼
06/01 18:45, 5F
推
06/01 18:46, 5月前 , 6F
連縮排用tab還是空白都能相輕了 還有不懂的新警察
06/01 18:46, 6F
→
06/01 19:16, 5月前 , 7F
打開專案心情就很差的感覺 refactor還是越早越好
06/01 19:16, 7F
推
06/01 19:16, 5月前 , 8F
有反註解派哦？那他們怎麼處理需要註解的情境？通靈
06/01 19:16, 8F
→
06/01 19:16, 5月前 , 9F
嗎
06/01 19:16, 9F
推
06/01 19:28, 5月前 , 10F
果然無限QE怎麼輸
06/01 19:28, 10F
推
06/01 19:34, 5月前 , 11F
結論：hard code就對了(？
06/01 19:34, 11F
→
06/01 20:28, 5月前 , 12F
你的結論就是怎樣哈扣都可以，真是可愛
06/01 20:28, 12F
推
06/01 20:40, 5月前 , 13F
樓上懷疑PCMan嗎?
06/01 20:40, 13F
推
06/01 20:43, 5月前 , 14F
推PCMan
06/01 20:43, 14F
推
06/01 20:44, 5月前 , 15F
哈扣真的不是最差的選擇
06/01 20:44, 15F
→
06/01 22:30, 5月前 , 16F
反註解派：程式碼即為說明書，程式碼即為文件，不hardcode
06/01 22:30, 16F
→
06/01 22:31, 5月前 , 17F
寫出來的就是所有人應該看懂的常識
06/01 22:31, 17F
推
06/01 22:47, 5月前 , 18F
我推薦使用 ad-hoc 這個字取代 hard code
06/01 22:47, 18F
→
06/01 22:49, 5月前 , 19F
反註解派說程式碼即為所以不用寫註解的觀點沒有錯，但是
06/01 22:49, 19F
→
06/01 22:49, 5月前 , 20F
反註解派的最大的問題是，他們對於自己的code太有自信，
06/01 22:49, 20F
→
06/01 22:50, 5月前 , 21F
這是華人教育的傳統問題，華人教育是文章看不懂是讀者的
06/01 22:50, 21F
→
06/01 22:50, 5月前 , 22F
問題。
06/01 22:50, 22F
→
06/01 22:51, 5月前 , 23F
反註解派說程式碼即為"說明書"所以不用寫註解的觀點*
06/01 22:51, 23F
→
06/01 22:54, 5月前 , 24F
反註解派的想法沒問題，就跟共產主義也沒問題，但實作就是
06/01 22:54, 24F
→
06/01 22:55, 5月前 , 25F
問題一堆，理念很美好，但現實超難達成。
06/01 22:55, 25F
推
06/01 23:06, 5月前 , 26F
反註解派反的是那種無用的註解吧 例如這裡呼叫xxx 之類看
06/01 23:06, 26F
→
06/01 23:06, 5月前 , 27F
code比看註解還有用的地方
06/01 23:06, 27F
推
06/01 23:16, 5月前 , 28F
不用註解的前提是程式碼的命名、邏輯、流程都能簡單讀懂
06/01 23:16, 28F
→
06/01 23:17, 5月前 , 29F
但通常會用hard code去解決問題一定有當時的時空背景在
06/01 23:17, 29F
推
06/01 23:17, 5月前 , 30F
但實際上常常是：專案早期 hardcode勇敢欠債，成長期沒空
06/01 23:17, 30F
→
06/01 23:17, 5月前 , 31F
改，穩定期東西沒壞就不要亂改(或已經改不動了)
06/01 23:17, 31F
→
06/01 23:17, 5月前 , 32F
或是用通則無法解決 ...
06/01 23:17, 32F
→
06/01 23:17, 5月前 , 33F
這種情況下後面再回頭看code只能靠回憶 幾乎無法單純讀懂
06/01 23:17, 33F
推
06/01 23:20, 5月前 , 34F
至於註解不是寫不寫的問題，反而比較像是"如何適當使用註
06/01 23:20, 34F
→
06/01 23:20, 5月前 , 35F
解"
06/01 23:20, 35F
→
06/02 00:07, 5月前 , 36F
註解的使用不是我想回的重點，重點是平衡短期和長期效益
06/02 00:07, 36F
→
06/02 00:07, 5月前 , 37F
按照當下的狀況，調整開發的步調。
06/02 00:07, 37F
→
06/02 00:08, 5月前 , 38F
建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup
06/02 00:08, 38F
→
06/02 00:09, 5月前 , 39F
或是有些緊急的修改有當下的時空背景，怕一忙沒法馬上清
06/02 00:09, 39F
還有 23 則推文
還有 1 段內文
→
06/02 17:34, 5月前 , 63F
未知才會拖慢開發速度 而不是已知 已知只要你對語言
06/02 17:34, 63F
→
06/02 17:35, 5月前 , 64F
不是很不熟或惡搞都能完善到底
06/02 17:35, 64F
→
06/02 17:39, 5月前 , 65F
然而這樣搞對你來講也許可以算已知 對接手的人就是未
06/02 17:39, 65F
→
06/02 17:40, 5月前 , 66F
知了 要花成倍心思去解決 當然不寫注解要求就是寫的
06/02 17:40, 66F
→
06/02 17:42, 5月前 , 67F
好 複雜需求簡歸納簡化 達成可以顯式除錯而不用通靈
06/02 17:42, 67F
→
06/02 17:45, 5月前 , 68F
然而依照你上面這樣搞對你來講可以算已知
06/02 17:45, 68F
→
06/02 17:50, 5月前 , 69F
至於如何共用的更好講究的是邏輯圓融 天人合一
06/02 17:50, 69F
→
06/02 18:00, 5月前 , 70F
要達到樓主講的流程趨勢 對整潔本來就要有一定要求
06/02 18:00, 70F
→
06/02 18:01, 5月前 , 71F
否則自己寫的都看不懂了 不要說別人 往後才會有下一
06/02 18:01, 71F
→
06/02 18:02, 5月前 , 72F
步
06/02 18:02, 72F
→
06/02 18:05, 5月前 , 73F
講到底最重要的還是整齊 模組化都不用搞到很高大上
06/02 18:05, 73F
→
06/02 18:06, 5月前 , 74F
畢竟搞太多就會隱藏細節
06/02 18:06, 74F
推
06/02 21:40, 5月前 , 75F
推 倒數第二行話…
06/02 21:40, 75F
→
06/02 21:41, 5月前 , 76F
寫了一堆註解，結果關鍵的地雷卻不寫….
06/02 21:41, 76F
→
06/03 10:18, 5月前 , 77F
註解最大作用就是拿來貼Jira或confluence連結XD
06/03 10:18, 77F
→
06/03 13:52, 5月前 , 78F
有些事要做過大專案 踩過坑流過淚才能體會了
06/03 13:52, 78F
推
06/03 15:13, 5月前 , 79F
"註解不是描述 code 做了什麼，而是描述為什麼會有這 h
06/03 15:13, 79F
→
06/03 15:13, 5月前 , 80F
ack"...不只是 hack，平常寫註解本來就該以補充程式碼
06/03 15:13, 80F
→
06/03 15:13, 5月前 , 81F
以外的資訊、解釋由來為主，看一堆解釋底下程式碼在做
06/03 15:13, 81F
→
06/03 15:13, 5月前 , 82F
什麼操作的註解...當作是在寫教學用的 sample code，看
06/03 15:13, 82F
→
06/03 15:13, 5月前 , 83F
著浪費視覺空間
06/03 15:13, 83F
→
06/03 15:17, 5月前 , 84F
//這裡定義了變數 a=1
06/03 15:17, 84F
→
06/03 15:17, 5月前 , 85F
var a=1; //你不寫註解我也知道
06/03 15:17, 85F
推
06/03 16:29, 5月前 , 86F
推
06/03 16:29, 86F
→
06/03 23:54, 5月前 , 87F
// 註解是用來說這段垃圾code 是上層交代 不要怪我
06/03 23:54, 87F
→
06/04 00:16, 5月前 , 88F
TODO: someone else do
06/04 00:16, 88F
推
06/04 13:06, 5月前 , 89F
我會留著hardcode的代碼重構 這樣不好嗎
06/04 13:06, 89F
→
06/04 13:07, 5月前 , 90F
直接開個v2 這樣
06/04 13:07, 90F
推
06/04 17:10, 5月前 , 91F
根據經驗不會有時間重構 如果能讓你有時間重構 那是ＰＭ時間
06/04 17:10, 91F
→
06/04 17:11, 5月前 , 92F
壓得不夠緊 所以最好還是一次寫好
06/04 17:11, 92F
→
06/04 17:12, 5月前 , 93F
尾聲部份就同意 最好寫得越簡單越笨越好 免得前面的大量測試
06/04 17:12, 93F
→
06/04 17:13, 5月前 , 94F
做白工 （雖然一改都還是要重測 但出事就會被放大)
06/04 17:13, 94F
→
06/04 19:30, 5月前 , 95F
不是說有一派主張不要寫註解，只要var和func名稱取得
06/04 19:30, 95F
→
06/04 19:31, 5月前 , 96F
好，再加上程式內聚力強，就可以看懂程式在做什麼了
06/04 19:31, 96F
→
06/04 19:57, 5月前 , 97F
看得懂程式在做什麼不一定看得懂為什麼要做這件事啊所以
06/04 19:57, 97F
→
06/04 19:57, 5月前 , 98F
才要註解
06/04 19:57, 98F
推
06/04 22:41, 5月前 , 99F
對code有太多理想的人多半沒做過大專案
06/04 22:41, 99F
推
06/05 00:37, 5月前 , 100F
看得懂程式在做什麼不一定懂為什麼要這樣做+1
06/05 00:37, 100F
→
06/05 10:04, 5月前 , 101F
不一定是沒做過大專案 還有一種是主管職願意假日花時間那種
06/05 10:04, 101F
推
06/07 11:05, 5月前 , 102F
推
06/07 11:05, 102F
‣ 更多 HZYSoft 的文章
文章代碼(AID): #1cMkNRFj (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 2 之 7 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共7篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 HZYSoft 的文章
文章代碼(AID): #1cMkNRFj (Soft_Job)