我個人感覺程式語言也是有語感的 跟學歷關係不大 我自己碰過一種寫法 if 變數 == a print 甲.jpg if 變數 == b print 乙.jpg if 變數 == c print 丙.jpg 看來邏輯沒問題 但其實這段 if else 根本就不需要 你只要改成 print 變數.jpg 就可以了 這樣寫 還可以未來擴充都不用修改 另外還有很多類似的例子 但其實一堆可以在業界完成工作的工程師 都沒辦法發現那樣寫的問題 他們只想完成工作與邏輯 但也有可能是我沒在更高階的程式環境 其實很多設計模式與多形 在我看來都是為了消除if else 例如依賴反轉與依賴注入 都可以減少if else 應該視 if else 為惡魔 時時想著要怎麼消除 if else 久了就會有進階的處理方式 我記得很久以前 可能有二十年前了 有人曾經說他一小時內可以寫幾千行程式來顯示自己很會寫 那像我這樣一直思考如何減少 if 程式碼的人 不就反而是他眼中很不會寫的人 台灣不是軟體為主的經濟體 當老闆的人不見得是專業的工程師出身 以老闆角度來說 不管怎麼寫 邏輯對都沒差 我還遇過一個老闆直接叫我直接加一個if 以減少工時 後來幾年後 那個項目就倒了 被同行說是爛到業界出名的產品 那個老闆也懂一點程式 所以反而更糟糕 這現象可能無解 他們還是能完成工作 就只能加強溝通與教育 然後做好自己的工作 拿出成果讓他們知道為什麼要這樣改 去其他公司 這種人還是不少 另外這跟你待在甲方乙方也有關係 有公司會找乙方來寫 代表這不是他們的核心業務 代表他們是為了求快才找乙方 所以你幫他寫得比較好有意義嗎 花時間寫得比較好 但對他們來說快速比較重要 某 funcation 有 95% 一樣 但你為了讓程式變好 共用 決心想去搞懂那 5% 的不同 這其實有風險 你要很懂系統 也要有完整的測試案例 其實會花更多時間 搞不好還會弄壞別人的功能 在乙方速度就是一切 因為台灣人找乙方就是為了快 我甚至認為理想的程式宇宙 不應該有乙方這種產業存在 但我也知道 現實社會就是有乙方需求 或許乙方應該一家獨大 極大化 大到可以要甲方乖乖聽話 慢慢寫 我知道這裡高手很多 但也明顯有一些新人上來問問題 所以也就講一下很基本的經驗 -- ※ 發信站: 批踢踢實業坊(ptt.org.tw), 來自: 36.235.109.212 (臺灣) ※ 文章網址: https://ptt.org.tw/Soft_Job/M.1721824065.A.9E6

推 shieldsky: 但我覺得為了要弄懂那5%而改成共用函式，對於工作者本 07/24 20:43

→ shieldsky: 身的能力提升有幫助，當然也需要完整測試避免弄壞已經 07/24 20:43

→ shieldsky: 寫好的功能。 07/24 20:43

→ abccbaandy: 研究垃圾有啥幫助... 07/24 20:51

推 NDark: a/b/c也是你事後才知道. 規格出現的時候可能根本沒規格 07/24 20:52

→ knives: 推樓上 07/24 21:05

推 viper9709: a/b/c有可能臨時要多一個d,而且不只是印東西 07/24 22:27

→ wuyiulin: 同意一樓，但是實務上通常很多需求都是追加，除非是有 07/24 23:27

→ wuyiulin: 經驗工程師/做同類型的產品做多了知道要哪裡留接口，不 07/24 23:27

→ wuyiulin: 然消除 if else 是一個假議題。 07/24 23:27

推 abc0922001: 我是不太喜歡if else 裡面還有 if else 07/25 00:10

→ Abbee: 看到這篇很有共感,為了把if else去掉,我在寫規格書時,整理 07/25 01:01

→ Abbee: 了原程式裡的差異和共通處,花了不少時間寫規格書,因為原程 07/25 01:01

→ Abbee: 式每段幾乎一樣,但又有一點點不一樣,看到眼都花了,若是照翻 07/25 01:02

→ Abbee: 寫新程式,只是一樣都複製貼上,不用花什麼時間,但下次再加一 07/25 01:02

→ Abbee: 項,又要改程式走上線流程,把不同提出來放設定檔,都不用再上 07/25 01:03

→ Abbee: 線,但這只有好到維護的人,開發的人才不管這麼多 07/25 01:03

→ Abbee: 不是放設定檔的,也能之後只要加dll,而不動原程式,但新手無 07/25 01:05

→ Abbee: 法理解這樣作哪裡好 07/25 01:05

→ brucetu: 現在你只要在甲乙丙下面寫 let filename剩下的copilot會 07/25 10:05

→ brucetu: 幫你完成，存檔測試搞定 07/25 10:05

→ brucetu: 所以這種單純的案例未來再重寫不會花什麼時間 07/25 10:06

推 CRPKT: IoC 與 DI 都不是為了消滅 if else 07/25 10:21

噓 DrTech: 這例子根本不考慮，變數出現 a,b,c以外的特例。實務上常 07/25 13:13

→ DrTech: 常就是bug的來源。 07/25 13:13

→ DrTech: 正常，有規模與品質的公司，測試部門的unit test就不會過 07/25 13:14

→ DrTech: 了啦。 07/25 13:14

→ abccbaandy: 推樓上，一堆工程師自以為優化，實際上業務邏輯=程式 07/25 13:32

→ abccbaandy: 是最理想的狀況，業務邏輯bug最常出現在這 07/25 13:33

→ DrTech: 不要認為有什麼 標準答案，或銀彈。還是要看實際業務場景 07/25 13:37

→ DrTech: 來判斷程式該怎麼寫。此文已經假設，永遠只有a,b,c三種數 07/25 13:37

→ DrTech: 值，並不符合所有業務狀況。太多實際狀況，就是會出現a,b, 07/25 13:37

→ DrTech: c以外的數值，讓你程式品質無法預期。 07/25 13:37

→ DrTech: 這時候用else，真的比較好保證程式品質。 07/25 13:38

→ DrTech: 萬一a,b,c以外的狀況有無限擴充，難以設條件，難道要不斷 07/25 13:41

→ DrTech: 寫if？用else真的沒那麼糟糕。 07/25 13:41

推 viper9709: 推樓上 07/25 16:34

推 anandydy529: 第一種寫法至少有個else知道有不符合abc的條件 07/25 16:53

→ anandydy529: 第二種寫法運氣不好直接噴一個NPE讓你加班Hotfix 07/25 16:54

→ anandydy529: 但不是說第二種寫法不好，要先瞭解專案的歷史再決定 07/25 16:56

推 akito117: 同意樓上，要考慮abc以外的情況，至少要有個報錯或防呆 07/25 18:44

→ lazarus1121: 一般的寫法是if a else b else c else Exception 07/26 07:50

→ lazarus1121: 因為你先知道abc和jpg對應，但若這功能都是這類設計 07/26 07:55

→ lazarus1121: 拋錯時根本不知道是哪邊漏什麼東西，只能逐行找 07/26 07:57

→ lazarus1121: 如果真的很想一勞永逸拿掉if，你abc選項要從jpg來產 07/26 07:58

→ lazarus1121: 出才行 07/26 07:58

→ LiebeLion: 丟一個你沒想到的變數 直接搞掛 讚啦 07/26 13:30

噓 ck237: 喵的 突然想到同事寫的一個拿檔案的動作，就是前端給檔名然 07/26 17:25

→ ck237: 後當變數進去，結果人家就可以拿所有的東西，因為你提供一 07/26 17:25

→ ck237: 個萬用接口，為了這種東西還要防注入攻擊太蠢了... 07/26 17:26

→ ck237: 這種前端寫久了的做法用來做後端真是誰倒楣誰接手 07/26 17:27

推 CoNsTaR: 不是什麼都抽象化就是好欸，該要 concrete 的地方最好還 07/26 22:24

→ CoNsTaR: 是要 concrete，該 explicit 的地方就是該 explicit 07/26 22:24

→ CoNsTaR: 你應該要以現實中的邏輯當基準來選擇要用（由低到高）邏 07/26 22:24

→ CoNsTaR: 輯分支/演算法/語言特性/程式架構來實作 07/26 22:24

→ CoNsTaR: 以你的例子，if else 就是一種邏輯分支，你說的抽象成變 07/26 22:24

→ CoNsTaR: 數就是一種演算法，實際要看哪一種描述原本的邏輯更貼切 07/26 22:24

→ CoNsTaR: ，並沒有哪一種一定比較好 07/26 22:24