推 O187: 我也曾寫c#的lamda被人嗆 這只有你會寫 沒人這樣寫04/03 11:42
推 O187: 也有開發一半的程式一離職被程度不佳的整個重寫 後來他作不04/03 11:44
→ O187: 出來也跑了04/03 11:44
推 ILoveAMD: lamda等語法糖 很大的原因是原始設計偏向囉嗦 才改成04/03 11:46
→ ILoveAMD: 這種奇妙的簡寫04/03 11:47
推 stepnight: 曾經寫個功能易於擴展，不用動舊Code04/03 12:48
→ stepnight: 只要新增，在介面都寫完整註解 04/03 12:48
→ stepnight: 離職後聽前同事說有個新人一來就說要重構 04/03 12:48
→ stepnight: 整天說：這怎麼這樣寫、那怎麼這樣寫04/03 12:48
→ stepnight: 後來過一陣子問前同事是重構成怎樣了04/03 12:48
→ stepnight: ：他後來發現好像也只能這樣寫了 04/03 12:48
推 wulouise: 我寫過c#到現在還是不懂linq04/03 14:01
推 springfeel: 通常半調子的新人就是會有一堆美好想像 估計自己寫的04/03 14:50
→ springfeel: code後人來看也是嫌的像一坨屎04/03 14:50
推 NDark: 其實不用後人 每個人半年後都抱怨半年前自己在寫甚麼04/03 19:17
→ NDark: 但都沒想到 自己正在寫的 半年之後的自己也會抱怨04/03 19:17
→ NDark: 其實只有(商業)邏輯的"參數"才是黃金 程式碼都能花錢造04/03 19:18
→ NDark: 實作過程的所累積的經驗在人身上 這樣的人才重要04/03 19:19
推 hobnob: 真的很多工程師不是自閉就是自傲欸04/03 20:23
→ superpandal: 不然呢 重構本身就是要先幫助自己 雖然我通常是不重04/03 22:39
→ superpandal: 構那個 因為應該是沒收益04/03 22:40
→ superpandal: 效能情況我沒見過屎山效能好的 我自己從頭開始整的 04/03 22:42
→ superpandal: 效能倒是很不錯04/03 22:43
推 VScode: 超級討厭過度設計的 搞到不知道在寫三小 我寧願看義大利04/03 22:43
→ VScode: 麵糞扣 也不想看一堆封裝繼承oop04/03 22:43
→ superpandal: 我也討厭過度封裝 我一直視為前人的陰謀 但基本架構04/03 22:51
→ superpandal: 還是要有的 否則全義大利麵也是很痛苦04/03 22:51
→ superpandal: 全義大利麵只有給其它不相干的人最適合 可以搞生成co04/03 22:53
→ superpandal: de 04/03 22:53
→ superpandal: 自己內部看的與給別人的是不一樣的 模版有無限可能 04/03 22:57
→ superpandal: 現在前端也差不多這樣 compile再compile04/03 22:58
→ stepnight: 全義大利麵code就是給免洗員工最佳架構04/03 23:08
→ stepnight: 反正誰來都可以繼續維護 04/03 23:08
→ superpandal: 商業邏輯參數也都不是黃金 多半只是公司專用的產物04/03 23:09
→ superpandal: 都免洗了還想維護義大利麵code 稍微施加需求壓力就爆04/03 23:11
→ superpandal: 了的東西 當然是能省心就省心04/03 23:11
→ superpandal: 有經驗應該知道省心才是第一要務 其它根本不值得care04/03 23:22
→ superpandal: 當然有些人會想別人不省心我不就省心了嗎04/03 23:35
推 jlhc: 全義大利麵真心不行... 要修改都牽一髮動全身..04/04 00:14
→ viper9709: 推新寫的用新方式,舊的有異動的部分再去調+104/04 01:07
推 prag222: 之前我手上重構也是排自己的工時進去,就整理一下包成物件04/04 04:56
→ prag222: 不然每次呼叫都一堆重複程式碼跟麻煩的細節設定04/04 04:56
→ prag222: 有的功能你用早期web程式一行一行跑script lang會搞死人04/04 04:58
推 pot1234: 效能變差我就覺得不算成功的refactor了。前人寫那麼差的 04/04 08:10
→ pot1234: 話怎麼可能refactor到效能變差
因為重構的人只是看不慣以前的寫法，能力卻不夠，新的寫法反而差，例如前人寫for/fo
reach看不慣，改成linq，卻不熟延遲查詢的特性，那就是地獄
04/04 08:10
推 a12838910: linq 很棒欸04/04 08:56
→ a12838910: 我自己是真的遇到前人 寫很多累贅的程式碼04/04 08:56
→ a12838910: 在不影響邏輯的前提下優化後 少了很多行04/04 08:57
→ shooter555: 架構變好 效能變差很有可能啊 因為為了封裝 可能會多04/04 09:58
→ shooter555: 了不少資料傳遞的動作04/04 09:58
※ 編輯: bantime (223.140.83.27 臺灣), 04/04/2025 11:03:13
→ alan3100: 第3種就同事平均程度太差 async/await不懂的其實很多 04/04 12:54
→ alan3100: 就算小部分重構或新的才用新寫法 最終還是只有你能維護 04/04 12:56
這部分扯到需求問題，不是為了重構故意使用非同步，而是效能需要才使用，其他人跟不
上就不是我的問題了。
但如果只是為了自己看得爽，看不慣一些陳舊寫法而去重構，那就是自己的問題
※ 編輯: bantime (223.140.83.27 臺灣), 04/04/2025 13:36:28
推 devilkool: .NET開發者用async/await很基本了吧 除非傳慘= = 04/04 13:52
→ Firstshadow: = = 04/04 15:41
推 art1: 用習慣了 .net 跟 js 的非同步，python 的好難用... 04/04 17:58
→ Csongs: 就說是文人相輕 04/04 18:43
我不認為完全是文人相輕，畢竟是老古董，當年的技術程度寫出那樣已經很好了，只是沒
有隨著時代演進，我們現在覺得很好的方式幾年後也許也會被當成垃圾，所以需要持續迭
代，拿手機來說許多當年的神機現在也只是垃圾一台
※ 編輯: bantime (223.140.83.27 臺灣), 04/04/2025 19:54:33
→ testPtt: 看程式的規模 例如你要寫一套作業系統 不得不細分功能 04/04 20:21
推 shortoneal: 這種議題沒看到code一率都是保留態度，自我感覺良好的 04/04 21:51
→ shortoneal: 人很多lol 04/04 21:52
→ rogerlarger: 讀別人的code就像吃別人的屎，吃習慣就好 04/04 23:09
→ superpandal: 那就只有程式碼表現方式不同 概念想法做法很久前就04/05 03:52
→ superpandal: 有了 不會差太多 含效能 硬體拿來比就.... 04/05 03:53
→ superpandal: 習慣當然會有效率不同的問題 只要自己不用再維護別人 04/05 03:56
→ superpandal: 愛怎麼重構責任也不在你04/05 03:57
→ superpandal: 架構變好效能變差多半不是封裝導致 無用封裝再多層 04/05 04:05
→ superpandal: 也起不了作用 過於誇張的太少見 這也是為什麼框架可04/05 04:06
→ superpandal: 以藉此濫用用來隱藏實作細節的原因04/05 04:07
→ superpandal: 過度封裝的問題點在於擾亂視聽 04/05 04:14
→ superpandal: 效能問題在不是太差的機器上你根本看不出來04/05 04:20
推 wizozd84070: 學會習慣也是一種學習 04/05 08:02
同意，當年自己也是這樣看不慣
心態轉變後好很多了
※ 編輯: bantime (223.140.83.27 臺灣), 04/05/2025 08:05:34
推 VScode: 放下它 加入它 學會寫糞code以後很爽的 自己維護很快 04/05 11:01
→ VScode: 別人看不懂 效率upup 04/05 11:01
推 hakama99: 我第一次看到lamda覺得是邪魔外道XD04/05 11:11
推 NDark: 我覺得lamda就是一時爽 比複製貼上有得拚04/05 11:19
→ NDark: 時程很趕沒辦法顧好品質是勉強用了 但長期維護就很難 04/05 11:20
推 VScode: 我也不喜歡linq 底層封裝太多東西了 表面看起來很方便 但 04/05 13:03
→ VScode: 很容易踩到效能陷阱 還是自己手刻安心些 04/05 13:03
linq不是只有EF哦，我遇到蠻多把Linq跟EF劃上等號的人，除此之外比較常見所謂的效能
陷阱大概都是延遲查詢相關的部分，還是可以舉例來說一下有什麼效能陷阱呢？
※ 編輯: bantime (223.140.83.27 臺灣), 04/05/2025 18:55:38
推 VScode: 我不是在講EF 而是linq to object,做一些複雜查詢時很容易 04/05 19:57
→ VScode: 踩到雷 例如Where裡做Contains、Any判斷等等 04/05 19:57
→ VScode: 加上GroupBy Aggregate等操作寫了N層巢狀的也很難debug 04/05 19:58
原來如此啊，但如果是這樣應該不是linq的問題，因為就算不是在where內做，改成迴圈
在裡面做Any問題應該也是存在呢。
所以這些效能陷阱聽起來不像是linq的鍋，單純使用上不熟所造成，我是這樣認為啦。不
過無論什麼元件使用不熟對效能造成影響也是很正常的事情，但不認為鍋要在元件上就是
了。
不過複雜邏輯也沒人逼一定要一次用linq寫完，拆分混用都可以。
※ 編輯: bantime (223.140.83.27 臺灣), 04/05/2025 20:18:47
→ superpandal: 只要不被要求deadline前做好 被事後檢討那習慣倒是 04/05 20:43
→ superpandal: 還好 不然自己產出被檢視也很麻煩 04/05 20:44
→ superpandal: 只顧自己那不就是鬥後人？ 由此可見職場風氣真的差 04/05 20:46
→ superpandal: 理解糞code並不是說絕對不好 但如果你是被壓時間又要04/05 20:49
→ superpandal: 理解別人的糞code那很痛苦 04/05 20:50
→ stepnight: 不過你各位公司都沒有規範/CR的嗎？ 04/05 21:04
→ superpandal: 異地而處馬上又換嘴臉的太多了 糞code都不是最嚴重04/05 21:13
→ superpandal: 最嚴重的是雙標 大家互吃糞都還沒那麼不平衡 04/05 21:16
嘛……我是不太喜歡糞Code這個詞啦，雖然我也經歷過罵人糞Code的階段
但既然是前人的Code，蠻高機會應該都是上線的產品了，公司的營收這些程式碼多少也有
貢獻呢！
公司是賺錢的地方，不是拿來做學術理論的地方，我是這樣想的，在維持公司營收有餘裕
的前提下，再做動刀比較好。
那種為了後人啊，或是不重構就等著爆炸的話...嗯……通常是改了爆炸呢或是其他人接
手的時候又是說這啥糞Code呢～
除了自己的程式碼以外很少有人看別人的程式碼順眼的吧？XD
※ 編輯: bantime (223.140.83.27 臺灣), 04/05/2025 21:40:14
推 strlen: 不是這個問題 糞不糞code當然不是你說了算 是團隊說了算 04/05 21:45
→ strlen: 所以要頻繁跟人家吵架改code 偏偏工程師誰要跟人家吵這個 04/05 21:46
推 ricky60324: 不寫單元測試的我覺得才是最靠背的 有寫單元測試架構 04/05 23:33
→ ricky60324: 不會爛到哪邊 因為寫測試的時候很難寫就會自己改了 04/05 23:33
→ ricky60324: 遺留的code 沒有規格書 沒有單元測試 能賺錢也不代 04/05 23:34
→ ricky60324: 表他不糞XD 而且技術債遲早要還的 04/05 23:34
→ ricky60324: 當然大家都抱持著 不要爆在我手上就好 重構不是必要 04/05 23:35
→ ricky60324: 也建議不要花時間重構 新的code再寫好 舊的能動就好 04/05 23:35
→ ricky60324: 不然等著背鍋的就是重構的那位
這個要看產業/專案性質了，有些真的一點失誤都很嚴重
如果都是內部EMP還是什麼的，出一點小包都還不會怎樣，但是如果扯到錢或是安全問題
就大了
04/05 23:35
推 tsaigi: async/await 感覺真的很多人不懂 之前整個公司十幾個專案04/05 23:54
→ tsaigi: 都用到有問題的寫法 程式一直crash 還要我這個SRE下去修04/05 23:54
還有很多假非同步呢XD 以為寫了非同步，結果內部還是同步作業
※ 編輯: bantime (111.71.68.236 臺灣), 04/05/2025 23:57:28
※ 編輯: bantime (111.71.68.236 臺灣), 04/06/2025 00:01:50
推 viper9709: 推學會習慣也是一種學習XD 04/06 00:49
推 nicetw20xx: 推有寫單元測試，程式不會差到哪 04/06 09:00
→ testPtt: 寫成非同步有時候只是習慣 介面不會卡就懶得改了 04/06 09:37
非同步還有蠻多效能考量的，不只是UI，有機會練手我是就會練手，才不會等到真的要用
的時候才能夠信手拈來。
我自己也遇到蠻多這種說辭的，就是這個情境速度要求沒這麼快，不需要這樣寫，但我是
不太相信當速度要求提升的時候這些人是可以寫得出來的
※ 編輯: bantime (111.71.68.236 臺灣), 04/06/2025 09:52:17
推 aa0983163178: 我覺得不懂的技術，反而不要用比較好，遇過同事為了04/06 11:01
→ aa0983163178: 想寫非同步，結果線上一堆奇怪且難以解釋的bug XD 04/06 11:01
所以不懂的技術要找機會練習呀～
真正要用的時候才能夠信手拈來
※ 編輯: bantime (111.71.68.236 臺灣), 04/06/2025 12:28:52
推 tsaigi: 不懂確實不該用 但如果每個新技術都不懂 就等著被淘汰吧 04/06 13:25
講那個一點……我真的不認為Linq/async/await是“新”技術
※ 編輯: bantime (111.71.68.236 臺灣), 04/06/2025 13:39:05
→ superpandal: 最好有那麼多時間寫測試 測試本來就是寫的爛才需要保04/06 22:35
→ superpandal: 證 趕快寫好趕快休息才是真的 04/06 22:37
→ superpandal: 給你寫測試架構爛都是沒救 萬變不離其宗 掌握根本才 04/06 22:44
→ superpandal: 是最省心的 我講話也差不多這風格 04/06 22:45
→ superpandal: 發散的東西就是屎04/06 22:47
→ superpandal: 有脈絡的程式程式才反而不差 04/06 22:48
推 fatb: 我的經驗是除非你是公認的大神 不然不會有誰想看別人的code04/07 18:05
就算是大神的Code也是很多人不想看呦～啾咪～
※ 編輯: bantime (111.71.68.236 臺灣), 04/07/2025 19:30:39
→ wulouise: 不寫測試只爽到自己... 04/07 22:00
推 waiwailove: 寫C#還在串sql語法 call預存程序處理問題... 04/07 22:19
