推 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: 根據經驗不會有時間重構 如果能讓你有時間重構 那是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