推 shieldsky: 但我覺得為了要弄懂那5%而改成共用函式,對於工作者本 07/24 20:43
→ shieldsky: 身的能力提升有幫助,當然也需要完整測試避免弄壞已經 07/24 20:43
→ shieldsky: 寫好的功能。 07/24 20:43
如果是未來還要維護 去搞懂就有意義
但乙方大部份寫完 專案就結束了 有時只是去救急
搞懂對你來說只是奇怪的知識增加了
有時候你會覺得你多花時間幫忙寫好一點是為他們好
但更多時候他們只會覺得你寫得比較慢
我曾經寫過一個功能 為了可以共用所以多花一點時間
那支共用可以節省專案一年的時間
但多花了幾星期將不同處改成設定檔用設定的
但甲方才不管這個 你幫他們省了一年時間
他們只覺得你一個案例多花了幾星期去寫
然後去溝通也沒意義 你又不是甲方的人
讓甲方覺得你有貢獻也拿不到什麼實質的獎勵
你也不會想待在那種甲方
所以寫完就算了 被唸就被唸 也過了
乙方真的是一個很奇妙的經歷
但是重來就算會被唸 我還是會寫共用 + 設定檔
因為實在太蠢了 明明是同一種邏輯
受不了複製貼上
寫好後 我根本是悠閒的完成類似需求
調調設定檔就好
整個團隊十幾人都沒人想去做共用
應該不是沒人發現可以共用
而是某種文化正在形成
→ abccbaandy: 研究垃圾有啥幫助... 07/24 20:51
推 Kroner: 黑瑪卡功效 07/25 16:34推 NDark: a/b/c也是你事後才知道. 規格出現的時候可能根本沒規格 07/24 20:52
我反而覺得這是照規格寫才寫成這樣
因為寫規格的人不見得會寫程式
不會理解程式中的有變數觀念
所以他們寫規格時很直觀的想
如果是這樣 就那樣
如果是那樣 就這樣
但會寫程式的人 因為有變數的觀念
才會懂這根本不用加判斷
→ knives: 推樓上 07/24 21:05
推 viper9709: a/b/c有可能臨時要多一個d,而且不只是印東西 07/24 22:27
推 Kroner: 蔓越莓益生菌推薦dcard 07/25 16:56
多一個d ,就上傳一張 d.jpg 的圖片 就解決了
完全不用動到程式
如果不只是印東西 那就要改需求了
原來的寫法也是要改
→ wuyiulin: 同意一樓,但是實務上通常很多需求都是追加,除非是有 07/24 23:27
→ wuyiulin: 經驗工程師/做同類型的產品做多了知道要哪裡留接口,不 07/24 23:27
→ wuyiulin: 然消除 if else 是一個假議題。 07/24 23:27
推 Kroner: 苦瓜胜肽 07/26 07:55
完全消除當然不可能
但那是一種追求
推 abc0922001: 我是不太喜歡if else 裡面還有 if else 07/25 00:10
→ Abbee: 看到這篇很有共感,為了把if else去掉,我在寫規格書時,整理 07/25 01:01
→ Abbee: 了原程式裡的差異和共通處,花了不少時間寫規格書,因為原程 07/25 01:01
推 Kroner: 馬卡推薦 07/26 07:58→ Abbee: 式每段幾乎一樣,但又有一點點不一樣,看到眼都花了,若是照翻 07/25 01:02
→ Abbee: 寫新程式,只是一樣都複製貼上,不用花什麼時間,但下次再加一 07/25 01:02
→ Abbee: 項,又要改程式走上線流程,把不同提出來放設定檔,都不用再上 07/25 01:03
推 Chricey: 益生菌 07/26 17:25→ Abbee: 線,但這只有好到維護的人,開發的人才不管這麼多 07/25 01:03
→ Abbee: 不是放設定檔的,也能之後只要加dll,而不動原程式,但新手無 07/25 01:05
→ Abbee: 法理解這樣作哪裡好 07/25 01:05
推 Chricey: 益生菌 07/26 22:24
我先去的地方比較偏做自己產品
會想說 當初前人要是程式多加個什麼
也許多花幾天
但今天程式就會好維護很多
要知道維護的時間遠遠大於開發
省一點開發時間 是造成維護的十倍時間
後來去要支援別人的部門(類乙方)
思考是完全不同的
幫別人想 在外界看來就是手腳慢
後來想通了
其實像function 95% 一樣
這個就是維護的甲方要負責去調整的
這不是乙方的工作
除非你也要負責維護
※ 編輯: chal (36.235.109.212 臺灣), 07/25/2024 01:45:56
→ brucetu: 現在你只要在甲乙丙下面寫 let filename剩下的copilot會 07/25 10:05
→ brucetu: 幫你完成,存檔測試搞定 07/25 10:05
→ brucetu: 所以這種單純的案例未來再重寫不會花什麼時間 07/25 10:06
推 Chricey: 鋅功效女性 07/26 22:24推 CRPKT: IoC 與 DI 都不是為了消滅 if else 07/25 10:21
噓 DrTech: 這例子根本不考慮,變數出現 a,b,c以外的特例。實務上常 07/25 13:13
→ DrTech: 常就是bug的來源。 07/25 13:13
推 Kroner: 維生素d推薦 07/26 22:24→ 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
其實這個需求很簡單
就是先由系統提供選項a/b/c
系統再根據user的選擇 顯示 其選擇
大家所擔心的例外與其他
會處理 但不會在這裡處理
一開始就給拒絕了
未來系統也可能新增d/e/f 選項
當然系統也要因此要做一些改動
但至少顯示的這個功能 可以不用動
只要上傳d.jpg e.jpg f.jgp 即可
其實我也不是在講什麼銀彈
我只是說 有很多地方的if else 根本沒必要
以這個真實遇到的情況來說
其實就是圖檔名稱與變數名稱不同所造成的
所以只要順手把圖檔名稱改成與變數一樣
那些if else就可以消除
※ 編輯: chal (36.235.109.212 臺灣), 07/25/2024 21:54:47
→ 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
exception else 其他情況都有考慮
在一開始判斷不對就return 回去了
一開始就給拒絕了
例子聚焦重點 所以沒有特別強調這些例外
→ 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
這個功能並無涉檔案
這不是讓user上傳下載檔案的功能
很單純就是
系統根據user提供選項 顯示user選擇的選項
假設這是一個無法顯示圖檔的古系統
user 選 a/b/c 系統就顯示 a/b/c 其中之一
其實就只是這樣的簡單功能
推 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
但這例子就是實際的個案
把個案 抽像化成通案以後
再反過來看 當然就不適用所有個案
其實我只是要說 有些if else 不必要
但任何例子在特殊情況下當然有例外
※ 編輯: chal (36.235.109.212 臺灣), 07/27/2024 00:02:17