Re: [請益] 痾 遇到這種事情 是不是需要趕快離職了?
我個人感覺程式語言也是有語感的
跟學歷關係不大
我自己碰過一種寫法
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% 的不同
這其實有風險
你要很懂系統 也要有完整的測試案例
其實會花更多時間
搞不好還會弄壞別人的功能
在乙方速度就是一切
因為台灣人找乙方就是為了快
我甚至認為理想的程式宇宙
不應該有乙方這種產業存在
但我也知道 現實社會就是有乙方需求
或許乙方應該一家獨大 極大化
大到可以要甲方乖乖聽話 慢慢寫
我知道這裡高手很多
但也明顯有一些新人上來問問題
所以也就講一下很基本的經驗
--
但我覺得為了要弄懂那5%而改成共用函式,對於工作者本
身的能力提升有幫助,當然也需要完整測試避免弄壞已經
寫好的功能。
如果是未來還要維護 去搞懂就有意義 但乙方大部份寫完 專案就結束了 有時只是去救急 搞懂對你來說只是奇怪的知識增加了 有時候你會覺得你多花時間幫忙寫好一點是為他們好 但更多時候他們只會覺得你寫得比較慢 我曾經寫過一個功能 為了可以共用所以多花一點時間 那支共用可以節省專案一年的時間 但多花了幾星期將不同處改成設定檔用設定的 但甲方才不管這個 你幫他們省了一年時間 他們只覺得你一個案例多花了幾星期去寫 然後去溝通也沒意義 你又不是甲方的人 讓甲方覺得你有貢獻也拿不到什麼實質的獎勵 你也不會想待在那種甲方 所以寫完就算了 被唸就被唸 也過了 乙方真的是一個很奇妙的經歷 但是重來就算會被唸 我還是會寫共用 + 設定檔 因為實在太蠢了 明明是同一種邏輯 受不了複製貼上 寫好後 我根本是悠閒的完成類似需求 調調設定檔就好 整個團隊十幾人都沒人想去做共用 應該不是沒人發現可以共用 而是某種文化正在形成
研究垃圾有啥幫助...
a/b/c也是你事後才知道. 規格出現的時候可能根本沒規格
我反而覺得這是照規格寫才寫成這樣 因為寫規格的人不見得會寫程式 不會理解程式中的有變數觀念 所以他們寫規格時很直觀的想 如果是這樣 就那樣 如果是那樣 就這樣 但會寫程式的人 因為有變數的觀念 才會懂這根本不用加判斷
推樓上
a/b/c有可能臨時要多一個d,而且不只是印東西
多一個d ,就上傳一張 d.jpg 的圖片 就解決了 完全不用動到程式 如果不只是印東西 那就要改需求了 原來的寫法也是要改
同意一樓,但是實務上通常很多需求都是追加,除非是有
經驗工程師/做同類型的產品做多了知道要哪裡留接口,不
然消除 if else 是一個假議題。
完全消除當然不可能 但那是一種追求
我是不太喜歡if else 裡面還有 if else
看到這篇很有共感,為了把if else去掉,我在寫規格書時,整理
了原程式裡的差異和共通處,花了不少時間寫規格書,因為原程
式每段幾乎一樣,但又有一點點不一樣,看到眼都花了,若是照翻
寫新程式,只是一樣都複製貼上,不用花什麼時間,但下次再加一
項,又要改程式走上線流程,把不同提出來放設定檔,都不用再上
線,但這只有好到維護的人,開發的人才不管這麼多
不是放設定檔的,也能之後只要加dll,而不動原程式,但新手無
法理解這樣作哪裡好
我先去的地方比較偏做自己產品 會想說 當初前人要是程式多加個什麼 也許多花幾天 但今天程式就會好維護很多 要知道維護的時間遠遠大於開發 省一點開發時間 是造成維護的十倍時間 後來去要支援別人的部門(類乙方) 思考是完全不同的 幫別人想 在外界看來就是手腳慢 後來想通了 其實像function 95% 一樣 這個就是維護的甲方要負責去調整的 這不是乙方的工作 除非你也要負責維護
※ 編輯: chal (36.235.109.212 臺灣), 07/25/2024 01:45:56現在你只要在甲乙丙下面寫 let filename剩下的copilot會
幫你完成,存檔測試搞定
所以這種單純的案例未來再重寫不會花什麼時間
IoC 與 DI 都不是為了消滅 if else
這例子根本不考慮,變數出現 a,b,c以外的特例。實務上常
常就是bug的來源。
正常,有規模與品質的公司,測試部門的unit test就不會過
了啦。
推樓上,一堆工程師自以為優化,實際上業務邏輯=程式
是最理想的狀況,業務邏輯bug最常出現在這
不要認為有什麼 標準答案,或銀彈。還是要看實際業務場景
來判斷程式該怎麼寫。此文已經假設,永遠只有a,b,c三種數
值,並不符合所有業務狀況。太多實際狀況,就是會出現a,b,
c以外的數值,讓你程式品質無法預期。
這時候用else,真的比較好保證程式品質。
萬一a,b,c以外的狀況有無限擴充,難以設條件,難道要不斷
寫if?用else真的沒那麼糟糕。
推樓上
第一種寫法至少有個else知道有不符合abc的條件
第二種寫法運氣不好直接噴一個NPE讓你加班Hotfix
但不是說第二種寫法不好,要先瞭解專案的歷史再決定
同意樓上,要考慮abc以外的情況,至少要有個報錯或防呆
其實這個需求很簡單 就是先由系統提供選項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一般的寫法是if a else b else c else Exception
因為你先知道abc和jpg對應,但若這功能都是這類設計
拋錯時根本不知道是哪邊漏什麼東西,只能逐行找
如果真的很想一勞永逸拿掉if,你abc選項要從jpg來產
出才行
exception else 其他情況都有考慮 在一開始判斷不對就return 回去了 一開始就給拒絕了 例子聚焦重點 所以沒有特別強調這些例外
丟一個你沒想到的變數 直接搞掛 讚啦
同上
喵的 突然想到同事寫的一個拿檔案的動作,就是前端給檔名然
後當變數進去,結果人家就可以拿所有的東西,因為你提供一
個萬用接口,為了這種東西還要防注入攻擊太蠢了...
這種前端寫久了的做法用來做後端真是誰倒楣誰接手
這個功能並無涉檔案 這不是讓user上傳下載檔案的功能 很單純就是 系統根據user提供選項 顯示user選擇的選項 假設這是一個無法顯示圖檔的古系統 user 選 a/b/c 系統就顯示 a/b/c 其中之一 其實就只是這樣的簡單功能
不是什麼都抽象化就是好欸,該要 concrete 的地方最好還
是要 concrete,該 explicit 的地方就是該 explicit
你應該要以現實中的邏輯當基準來選擇要用(由低到高)邏
輯分支/演算法/語言特性/程式架構來實作
以你的例子,if else 就是一種邏輯分支,你說的抽象成變
數就是一種演算法,實際要看哪一種描述原本的邏輯更貼切
,並沒有哪一種一定比較好
但這例子就是實際的個案 把個案 抽像化成通案以後 再反過來看 當然就不適用所有個案 其實我只是要說 有些if else 不必要 但任何例子在特殊情況下當然有例外
※ 編輯: chal (36.235.109.212 臺灣), 07/27/2024 00:02:1724
首Po小魯目前在一家還算大的公司工作 現在有兩三位頂大的junior的同事 寫程式的習慣讓我覺得是不是要趕快跑了 舉兩個例子好了 他們都喜歡if-else combo, 沒巢狀到波動拳那麼深 但就是動不動就if-else 三層 然後三層裡面還會再if-else 第二個例子就是如果有function 90%(50~100行)適合他們想要的用途,X
氣 : 公司也沒人想要當壞人 code review也沒人出聲 而且大家都知道 上市公司每個都喜歡 : 有學歷的人當門面 反正真正主力有人會扛 XDDDD : 每次改到他們經手過的code都很痛苦 若是要幫忙擦屁股根本擦不完阿 因為一直拉.... : 自己寶貴的時間也都被吃掉了23
等等,我原本以為只是一個簡單的問題 居然歪樓了 推動coding conventions 可以從你我做起 像原原po的問題是 if4
實況寫程式的 Tsoding 最新原型作品 - 多人遊戲的伺服器端與客戶端(Typescript) 一堆 if else 裡面還有 if else,最多好像是三層,應該還不至於看不懂,原型的標準 比較低,快速產出才是王道
爆
[討論] 打張善政標案的綠粉 是真的不懂還是在裝?我是認真文 很認真的想知道這些綠粉心態 是單純「選舉抹黑」 還是「在裝不懂」? 我把想得到的點 一點點列點 Q1 與林智堅論文案相比爆
Re: [新聞]麻將遊戲不會算台建商怒告手遊設計公司看到這篇有點驚訝,原來上新聞了 這件案子從頭到尾我在處理的,真的做到有夠幹的,幹到冒煙,極度噁心 想跟版友分享一些心得 1.創業盡量不要在網路上找軟體外包,踩雷機率九成以上 只能找"靠譜"親友介紹的或是工作上認識已知工作能力還不錯的X
[心得] 年薪破百萬的前端工程師冏冏 前天一份矽谷軟體工程師的薪資統計被到處轉貼,很多人表示入錯行、生錯國家。我剛好 約了以前的同事來聊天,她是一位年薪破百萬的前端工程師。其他人們可能想知道的資訊 如下:26
[請益] 甲方跳乙方請益目前已經36了 只有java 4年多經驗,是進公司才學的 雖然本身的興趣也是寫程式 不過因為是在金融業,碰到的都是老技術和維運相關 也滿討厭目前浪費時間的公司文化,想跳槽17
[問卦] 業界寫程式用 i++ 多還是 ++i 多?寫程式要讓一個變數加一有很多種方式, 以 C 語言的索引 i 為例, 其中兩種方法為在 i 前面寫 ++ 和在 i 後面寫 ++, 業界寫程式用 i++ 多還是 ++i 多? --6
Re: [討論] 有人真的跟自己老闆說加薪成功的嗎?補充一下我的看法 順便設定一下大前提,那就是公司是一個"正常"的公司 所謂正常的公司就是不會提出不合理的 loading 的要求 例如該多少人月就做出多少品質/進度 而不是明明人月不足還要求做不到的品質/進度5
Re: [金光] 黃立綱請三弦當總經理應該是真的。推 e2000: 這種自己不是那行的佼佼者,在那邊教人怎 42.75.206.115 03/30 12:32 → e2000: 麼做老闆,怎麼IOS板,卓二板,科技業板都 42.75.206.115 03/30 12:32 → e2000: 有這種人,有些甚至還沒出社會,現在布袋 42.75.206.115 03/30 12:32 → e2000: 戲板又看到了 42.75.206.115 03/30 12:32 用你的邏輯說5
Re: [請益] 工作不順,想請大家給點建議只看你前面的敘述就猜到你八成在接案公司 這應該是公司覺得請你划不來吧 你的薪水五萬 那你的產值至少一個月也要有六七萬以上對公司才算打平 超過十萬以上對公司才算有賺3
Re: [請益] 新鮮人未來發展方向請益(金融業)從剛入行到現在也膜拜不少大大的文章參考 我也分享一點淺淺的快三年的金融業IT經驗 最早剛入行也是從核心的古老的舊時代系統語言開始磨練 上手不難,也更加瞭解DB等應用 只是寫著寫著不免擔心被大環境淘汰1
Re: [請益] PM懂程式有優勢嗎?半懂裝懂更可怕之前遇過號稱寫過程式的夥伴 寫程式不難,你上的課會讓你寫程式沒錯 但是一個比較大的專案牽扯到很多經驗 和很多套件的導入以及其他有的沒的鬼怪問題 而且每個寫法不同做法不同