Re: [討論] hard code 速度會快嗎?
※ 引述《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
--
倒數第二句真的是重點
Hardcode又不留註解就是在雷
反註解派該出來說註解無用論了
反註解派不會認為hardcode不用註解
不懂在相輕甚麼
連縮排用tab還是空白都能相輕了 還有不懂的新警察
打開專案心情就很差的感覺 refactor還是越早越好
有反註解派哦？那他們怎麼處理需要註解的情境？通靈
嗎
果然無限QE怎麼輸
結論：hard code就對了(？
你的結論就是怎樣哈扣都可以，真是可愛
樓上懷疑PCMan嗎?
推PCMan
哈扣真的不是最差的選擇
反註解派：程式碼即為說明書，程式碼即為文件，不hardcode
寫出來的就是所有人應該看懂的常識
我推薦使用 ad-hoc 這個字取代 hard code
反註解派說程式碼即為所以不用寫註解的觀點沒有錯，但是
反註解派的最大的問題是，他們對於自己的code太有自信，
這是華人教育的傳統問題，華人教育是文章看不懂是讀者的
問題。
反註解派說程式碼即為"說明書"所以不用寫註解的觀點*
反註解派的想法沒問題，就跟共產主義也沒問題，但實作就是
問題一堆，理念很美好，但現實超難達成。
反註解派反的是那種無用的註解吧 例如這裡呼叫xxx 之類看
code比看註解還有用的地方
不用註解的前提是程式碼的命名、邏輯、流程都能簡單讀懂
但通常會用hard code去解決問題一定有當時的時空背景在
但實際上常常是：專案早期 hardcode勇敢欠債，成長期沒空
改，穩定期東西沒壞就不要亂改(或已經改不動了)
或是用通則無法解決 ...
這種情況下後面再回頭看code只能靠回憶 幾乎無法單純讀懂
至於註解不是寫不寫的問題，反而比較像是"如何適當使用註
解"
註解的使用不是我想回的重點，重點是平衡短期和長期效益
按照當下的狀況，調整開發的步調。
建議註解單純是加個 TODO: 的註記日後才不會忘了 cleanup
或是有些緊急的修改有當下的時空背景，怕一忙沒法馬上清
日後有空要 refactor 的時候，回想不起來當時狀況。
註解不是描述 code 做了什麼，而是描述為什麼會有這 hack
至於 code 做了什麼，自然是 code 寫好讀 code 就懂了
推這篇專業
前期就幹模組化確實滿浪費時間的，不確定性高又有d
emo去喊芭樂拳的需求，直接hardcode省事。我的情境
是專案中期會整個系統連程式語言都大改，這邊再開
始做模組化都還來得及。
我是都看專案的arch 兩著會連動
其實很合文主說的前面快速後面還債 反正有空能還
寫面太認真 後面要裝忙也很累
有的時候要先搶時間弄MVP驗證市場或技術方案
會寫得很亂，但要有文件歸納重點方便日後重寫或重構
與其說hardcode不好，不如說很多人技術不熟練只會這樣做
順便說臨時修程式大多hardcode是因為你凌晨4點被call
大概也沒心弄得很漂亮，只是幾天內要記得重構
不夠清楚的需求沒必要過度最佳化 但又有多少需求是清楚
的呢?
不過是不重構的藉口罷了 你不能保證你寫出來的都很清
爽 堆到後面你不考慮共用還債就是推給別人還 這種也
是種垃圾行為 當然好的方向想就是不喜歡被鳥盡弓藏
不做模組化給後面的人爽而已 是否可以共用那也是看
個人功力 只要寫的顯式即可
未知才會拖慢開發速度 而不是已知 已知只要你對語言
不是很不熟或惡搞都能完善到底
然而這樣搞對你來講也許可以算已知 對接手的人就是未
知了 要花成倍心思去解決 當然不寫注解要求就是寫的
好 複雜需求簡歸納簡化 達成可以顯式除錯而不用通靈
然而依照你上面這樣搞對你來講可以算已知
至於如何共用的更好講究的是邏輯圓融 天人合一
要達到樓主講的流程趨勢 對整潔本來就要有一定要求
否則自己寫的都看不懂了 不要說別人 往後才會有下一
步
講到底最重要的還是整齊 模組化都不用搞到很高大上
畢竟搞太多就會隱藏細節
推 倒數第二行話…
寫了一堆註解，結果關鍵的地雷卻不寫….
註解最大作用就是拿來貼Jira或confluence連結XD
有些事要做過大專案 踩過坑流過淚才能體會了
"註解不是描述 code 做了什麼，而是描述為什麼會有這 h
ack"...不只是 hack，平常寫註解本來就該以補充程式碼
以外的資訊、解釋由來為主，看一堆解釋底下程式碼在做
什麼操作的註解...當作是在寫教學用的 sample code，看
著浪費視覺空間
//這裡定義了變數 a=1
var a=1; //你不寫註解我也知道
推
// 註解是用來說這段垃圾code 是上層交代 不要怪我
TODO: someone else do
我會留著hardcode的代碼重構 這樣不好嗎
直接開個v2 這樣
根據經驗不會有時間重構 如果能讓你有時間重構 那是ＰＭ時間
壓得不夠緊 所以最好還是一次寫好
尾聲部份就同意 最好寫得越簡單越笨越好 免得前面的大量測試
做白工 （雖然一改都還是要重測 但出事就會被放大)
不是說有一派主張不要寫註解，只要var和func名稱取得
好，再加上程式內聚力強，就可以看懂程式在做什麼了
看得懂程式在做什麼不一定看得懂為什麼要做這件事啊所以
才要註解
對code有太多理想的人多半沒做過大專案
看得懂程式在做什麼不一定懂為什麼要這樣做+1
不一定是沒做過大專案 還有一種是主管職願意假日花時間那種
21
首Po如題 hard code的速度會比較快嗎? 根據我經驗 hard code可以在極短時間內處理一些專案上的問題 但是專案上有高度相似的東西 藉由hard code去寫並不會比較快 反倒是多花一點時間重構 重構完畢之後 再來只要套function 修改參數 這速度會比hard code快很多7
都說是做專案了，又不是做產品。 做專案當然是做完收錢，Meet Dealine，所以重點是， 照案主的需求，改成他要的，照資安需求，修掉有問題的地方。好好上線。 一案結束，就下一案來了，你還有空refactor? 誰billing你？ 我是真的不明白ptt 上一堆天天refactor 掛嘴邊的。2
你講這個就代表你們公司(或工作室?)甚至於你個人 完全沒有經營codebase的習慣 我敢這樣說有幾個簡單的推論: 1. 如果你們是接案公司，接的案子種類應該不會南轅北轍 2. 如果你們是接案公司真的一天到晚在接五花八門domain的專案，那代表你們的競爭![Re: [討論] hard code 速度會快嗎?](https://i.imgur.com/tr55WF9b.png "Re: [討論] hard code 速度會快嗎?")
15
再吐一下天天refactor 的，在台灣你可以看到一堆公司，都有自己的產品， 就是接案子後，用原案的CODE重包出來的：產品。 然後，根本賣不動，這樣要你老闆BILLING你的閒著沒事做去re-fat-tor? 號稱精進系統，使系統更好what? 這下問題大了，何謂"更好"？如何衡量？1
re code 就是一個個人意願的問題，跟 code 是誰的財產無關，你雇用一個 coder 就等 於授權他來改你的 code，跟你請一個清潔人員來家裡打掃，跟你的房子是不是他的財產 無關。 還有人回說要經過股東同意才能歐push code咧，看到真是讓人噴飯，是多麼迷你的公司 會有股東跑來管這個？![Re: [討論] hard code 速度會快嗎?](https://i.imgur.com/iwoZNLCb.jpeg "Re: [討論] hard code 速度會快嗎?")
前面很多人說得很好了，只做點補充 如果你是新手，前面說的那些絕大部份都跟你沒有關係， 因為你不具備相應的必要能力。 某些 case hard code 好， 但是你可能沒有辦法正確判斷倒底是不是那些 case，![Re: [討論] hard code 速度會快嗎?](https://cdn.sstatic.net/Sites/softwareengineering/Img/apple-touch-icon@2.png?v=1ef7363febba "Re: [討論] hard code 速度會快嗎?")
38
Re: [討論] 工作時一天coding的時間我覺得you對programming(台灣title比較浮誇 RD)有些misunderstand 實際上真正需要brain storming的時間 可說是少之又少 真的要BS也輪不到你這種菜鳥來BS BS出來最後也是滿口BS 程式開發是不斷iteration 確實是會有構想階段沒錯(看高度 程度越低就越不需要動腦)31
Re: [討論] 系統越開發越多，負責的東西越來越多合理啊，進來這麼久了 對於程式碼和領域的掌握度，一定比幾年前的自己好上許多吧 一樣的工作量以前要做兩個禮拜，現在可能三天就做完了 當然要能做更多的事情 不然公司為什麼要給你更多薪水?27
Re: 不想唸碩士了，想去刷題個人覺得刷題跟工作有個不同的點 工作常遇到的一個問題是"如何維護大型專案" 不同類型的工作,專案規模多少有差 純軟來講,很容易遇到破百個檔案的大型專案 規格說改就改,大部分時候是努力讓一堆髒code拼在一起後還能運作....27
Re: [討論] 怎麼跟自以為是的同事相處提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言： : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司，我進去前已就有一個前端工程師，他從0建構了整個產品A 代表他能力不算差24
Re: [討論] 怎麼克制不想教白目同事的衝動原PO還好 只要壓制住教他的衝動就好 有沒有遇過同事一開始很熱情的請教你一些基本到不行的問題 (ex static 是什麼 什麼時候用 泛型怎樣怎樣的 還說他很想進步,只是沒時間(讓人白眼的藉口16
[請益] 如何有效益的維護data loader如題 目前做的project架構長這樣 Loader1 Loader2 Loader3 ........... Loader30 Area 1 Area 2![[請益] 如何有效益的維護data loader](https://i.imgur.com/k9yyOpUb.jpg?fb "[請益] 如何有效益的維護data loader")
7
Re: [討論]有可能不學coding就可以取得前後端工作?先不用談那些面試會遇到的問題，因為基本上目前的LLM能夠作到的能力是boosting 跟teaching而boosting的基礎使用者要會寫code，而teaching的的結果是使用者會 寫code 不可能無中生有，因為這違反了目前LLM的基本邏輯：文字接龍。所謂的文字接龍 ，前半段提示詞的好壞，決定後半段生成內容的品質，當用戶連怎麼正確描述自己7
Re: [請益] 該辭職嗎？到哪都會遇到垃圾系統 還沒聽過哪家公司沒有垃圾code, legacy code, 歷史包袱的... 如果你的主要考量是這個系統太爛不想改他 那我會建議不要離職. 因為不管你走到哪,都會遇到一樣的問題