作者 bantime (景)標題 Re: [討論] 寫程式的追求？時間 Thu Apr 3 11:28:36 2025
因為前人雜亂--＞所以造成維護上的難度？？？？
真的是雜亂造成的，還是自己不熟悉閱讀別人程式碼？
我甚至寫個最基本的async/await都有人會嫌難以維護了
看不懂別人程式碼通常有兩種狀況
一種是對方真的太爛，完全不想看
一種是你的程度無法跟上
就你一年半的經驗我推測後者機會比較高
你的最終結果只有講好的結果
模組化，好維護？（是你自己認為好維護），易讀？(也是你認為易讀)
有沒有考慮壞的？
效能變差，新舊不相容，因為太著重架構，然後一些超出架構範疇的需求完全無法做，就
跟上級說架構要打掉重做，花費更多時間一事無成，或是終於做出來了但只有你知道怎麼
好維護好讀（這些都是周圍真實發生過的案例）
接手老古董的經驗，我是新寫的就用新的方式去做，不要再讓污染擴大，舊的部分有需求
要異動調整才去小手術更動，QA也可以在不增加工作量的狀況下協助測試
全部重構？唯一優點大概只有滿足自己而已
不用講這麼冠冕堂皇，為了後人
大概就是媽媽這樣做都是為了你好的感覺
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.140.83.27 (臺灣)
※ 作者: bantime 2025-04-03 11:28:36
※ 文章代碼(AID): #1dxW1cDF (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1743650918.A.34F.html
※ 同主題文章:
Re: [討論] 寫程式的追求？
04-03 11:28 bantime
推 O187: 我也曾寫c#的lamda被人嗆 這只有你會寫 沒人這樣寫
也有開發一半的程式一離職被程度不佳的整個重寫 後來他作不出來也跑了1F 04/03 11:42
推 ILoveAMD: lamda等語法糖 很大的原因是原始設計偏向囉嗦 才改成這種奇妙的簡寫4F 04/03 11:46
推 stepnight: 曾經寫個功能易於擴展，不用動舊Code
只要新增，在介面都寫完整註解
離職後聽前同事說有個新人一來就說要重構
整天說：這怎麼這樣寫、那怎麼這樣寫
後來過一陣子問前同事是重構成怎樣了
：他後來發現好像也只能這樣寫了6F 04/03 12:48
推 wulouise: 我寫過c#到現在還是不懂linq12F 04/03 14:01
推 springfeel: 通常半調子的新人就是會有一堆美好想像 估計自己寫的code後人來看也是嫌的像一坨屎13F 04/03 14:50
推 NDark: 其實不用後人 每個人半年後都抱怨半年前自己在寫甚麼
但都沒想到 自己正在寫的 半年之後的自己也會抱怨
其實只有(商業)邏輯的"參數"才是黃金 程式碼都能花錢造
實作過程的所累積的經驗在人身上 這樣的人才重要15F 04/03 19:17
推 hobnob: 真的很多工程師不是自閉就是自傲欸19F 04/03 20:23
→ superpandal: 不然呢 重構本身就是要先幫助自己 雖然我通常是不重構那個 因為應該是沒收益
效能情況我沒見過屎山效能好的 我自己從頭開始整的效能倒是很不錯20F 04/03 22:39
推 VScode: 超級討厭過度設計的 搞到不知道在寫三小 我寧願看義大利麵糞扣 也不想看一堆封裝繼承oop24F 04/03 22:43
→ superpandal: 我也討厭過度封裝 我一直視為前人的陰謀 但基本架構還是要有的 否則全義大利麵也是很痛苦
全義大利麵只有給其它不相干的人最適合 可以搞生成code
自己內部看的與給別人的是不一樣的 模版有無限可能現在前端也差不多這樣 compile再compile26F 04/03 22:51
→ stepnight: 全義大利麵code就是給免洗員工最佳架構
反正誰來都可以繼續維護32F 04/03 23:08
→ superpandal: 商業邏輯參數也都不是黃金 多半只是公司專用的產物都免洗了還想維護義大利麵code 稍微施加需求壓力就爆了的東西 當然是能省心就省心
有經驗應該知道省心才是第一要務 其它根本不值得care當然有些人會想別人不省心我不就省心了嗎34F 04/03 23:09
推 jlhc: 全義大利麵真心不行... 要修改都牽一髮動全身..39F 04/04 00:14
→ viper9709: 推新寫的用新方式,舊的有異動的部分再去調+140F 04/04 01:07
推 prag222: 之前我手上重構也是排自己的工時進去,就整理一下包成物件不然每次呼叫都一堆重複程式碼跟麻煩的細節設定
有的功能你用早期web程式一行一行跑script lang會搞死人41F 04/04 04:56
推 pot1234: 效能變差我就覺得不算成功的refactor了。前人寫那麼差的話怎麼可能refactor到效能變差
44F 04/04 08:10
因為重構的人只是看不慣以前的寫法，能力卻不夠，新的寫法反而差，例如前人寫for/fo
reach看不慣，改成linq，卻不熟延遲查詢的特性，那就是地獄
04/04 08:10
推 a12838910: linq 很棒欸
我自己是真的遇到前人 寫很多累贅的程式碼
在不影響邏輯的前提下優化後 少了很多行46F 04/04 08:56
→ shooter555: 架構變好 效能變差很有可能啊 因為為了封裝 可能會多了不少資料傳遞的動作49F 04/04 09:58
※ 編輯: bantime (223.140.83.27 臺灣), 04/04/2025 11:03:13
→ alan3100: 第3種就同事平均程度太差 async/await不懂的其實很多
就算小部分重構或新的才用新寫法 最終還是只有你能維護51F 04/04 12:54
這部分扯到需求問題，不是為了重構故意使用非同步，而是效能需要才使用，其他人跟不
上就不是我的問題了。
但如果只是為了自己看得爽，看不慣一些陳舊寫法而去重構，那就是自己的問題
※ 編輯: bantime (223.140.83.27 臺灣), 04/04/2025 13:36:28
推 devilkool: .NET開發者用async/await很基本了吧 除非傳慘= =53F 04/04 13:52
--