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% 的不同
這其實有風險
你要很懂系統 也要有完整的測試案例
其實會花更多時間
搞不好還會弄壞別人的功能
在乙方速度就是一切
因為台灣人找乙方就是為了快
我甚至認為理想的程式宇宙
不應該有乙方這種產業存在
但我也知道 現實社會就是有乙方需求
或許乙方應該一家獨大 極大化
大到可以要甲方乖乖聽話 慢慢寫
我知道這裡高手很多
但也明顯有一些新人上來問問題
所以也就講一下很基本的經驗
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.235.109.212 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1721824065.A.9E6.html
推
07/24 20:43,
1月前
, 1F
07/24 20:43, 1F
→
07/24 20:43,
1月前
, 2F
07/24 20:43, 2F
→
07/24 20:43,
1月前
, 3F
07/24 20:43, 3F
如果是未來還要維護 去搞懂就有意義
但乙方大部份寫完 專案就結束了 有時只是去救急
搞懂對你來說只是奇怪的知識增加了
有時候你會覺得你多花時間幫忙寫好一點是為他們好
但更多時候他們只會覺得你寫得比較慢
我曾經寫過一個功能 為了可以共用所以多花一點時間
那支共用可以節省專案一年的時間
但多花了幾星期將不同處改成設定檔用設定的
但甲方才不管這個 你幫他們省了一年時間
他們只覺得你一個案例多花了幾星期去寫
然後去溝通也沒意義 你又不是甲方的人
讓甲方覺得你有貢獻也拿不到什麼實質的獎勵
你也不會想待在那種甲方
所以寫完就算了 被唸就被唸 也過了
乙方真的是一個很奇妙的經歷
但是重來就算會被唸 我還是會寫共用 + 設定檔
因為實在太蠢了 明明是同一種邏輯
受不了複製貼上
寫好後 我根本是悠閒的完成類似需求
調調設定檔就好
整個團隊十幾人都沒人想去做共用
應該不是沒人發現可以共用
而是某種文化正在形成
→
07/24 20:51,
1月前
, 4F
07/24 20:51, 4F
推
07/24 20:52,
1月前
, 5F
07/24 20:52, 5F
我反而覺得這是照規格寫才寫成這樣
因為寫規格的人不見得會寫程式
不會理解程式中的有變數觀念
所以他們寫規格時很直觀的想
如果是這樣 就那樣
如果是那樣 就這樣
但會寫程式的人 因為有變數的觀念
才會懂這根本不用加判斷
→
07/24 21:05,
1月前
, 6F
07/24 21:05, 6F
推
07/24 22:27,
1月前
, 7F
07/24 22:27, 7F
多一個d ,就上傳一張 d.jpg 的圖片 就解決了
完全不用動到程式
如果不只是印東西 那就要改需求了
原來的寫法也是要改
→
07/24 23:27,
1月前
, 8F
07/24 23:27, 8F
→
07/24 23:27,
1月前
, 9F
07/24 23:27, 9F
→
07/24 23:27,
1月前
, 10F
07/24 23:27, 10F
完全消除當然不可能
但那是一種追求
推
07/25 00:10,
1月前
, 11F
07/25 00:10, 11F
→
07/25 01:01,
1月前
, 12F
07/25 01:01, 12F
→
07/25 01:01,
1月前
, 13F
07/25 01:01, 13F
→
07/25 01:02,
1月前
, 14F
07/25 01:02, 14F
→
07/25 01:02,
1月前
, 15F
07/25 01:02, 15F
→
07/25 01:03,
1月前
, 16F
07/25 01:03, 16F
→
07/25 01:03,
1月前
, 17F
07/25 01:03, 17F
→
07/25 01:05,
1月前
, 18F
07/25 01:05, 18F
→
07/25 01:05,
1月前
, 19F
07/25 01:05, 19F
我先去的地方比較偏做自己產品
會想說 當初前人要是程式多加個什麼
也許多花幾天
但今天程式就會好維護很多
要知道維護的時間遠遠大於開發
省一點開發時間 是造成維護的十倍時間
後來去要支援別人的部門(類乙方)
思考是完全不同的
幫別人想 在外界看來就是手腳慢
後來想通了
其實像function 95% 一樣
這個就是維護的甲方要負責去調整的
這不是乙方的工作
除非你也要負責維護
※ 編輯: chal (36.235.109.212 臺灣), 07/25/2024 01:45:56
→
07/25 10:05,
1月前
, 20F
07/25 10:05, 20F
→
07/25 10:05,
1月前
, 21F
07/25 10:05, 21F
→
07/25 10:06,
1月前
, 22F
07/25 10:06, 22F
推
07/25 10:21,
1月前
, 23F
07/25 10:21, 23F
噓
07/25 13:13,
1月前
, 24F
07/25 13:13, 24F
→
07/25 13:13,
1月前
, 25F
07/25 13:13, 25F
→
07/25 13:14,
1月前
, 26F
07/25 13:14, 26F
→
07/25 13:14,
1月前
, 27F
07/25 13:14, 27F
→
07/25 13:32,
1月前
, 28F
07/25 13:32, 28F
→
07/25 13:33,
1月前
, 29F
07/25 13:33, 29F
→
07/25 13:37,
1月前
, 30F
07/25 13:37, 30F
→
07/25 13:37,
1月前
, 31F
07/25 13:37, 31F
→
07/25 13:37,
1月前
, 32F
07/25 13:37, 32F
→
07/25 13:37,
1月前
, 33F
07/25 13:37, 33F
→
07/25 13:38,
1月前
, 34F
07/25 13:38, 34F
→
07/25 13:41,
1月前
, 35F
07/25 13:41, 35F
→
07/25 13:41,
1月前
, 36F
07/25 13:41, 36F
推
07/25 16:34,
1月前
, 37F
07/25 16:34, 37F
推
07/25 16:53,
1月前
, 38F
07/25 16:53, 38F
→
07/25 16:54,
1月前
, 39F
07/25 16:54, 39F
→
07/25 16:56,
1月前
, 40F
07/25 16:56, 40F
推
07/25 18:44,
1月前
, 41F
07/25 18:44, 41F
其實這個需求很簡單
就是先由系統提供選項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
→
07/26 07:50,
1月前
, 42F
07/26 07:50, 42F
→
07/26 07:55,
1月前
, 43F
07/26 07:55, 43F
→
07/26 07:57,
1月前
, 44F
07/26 07:57, 44F
→
07/26 07:58,
1月前
, 45F
07/26 07:58, 45F
→
07/26 07:58,
1月前
, 46F
07/26 07:58, 46F
exception else 其他情況都有考慮
在一開始判斷不對就return 回去了
一開始就給拒絕了
例子聚焦重點 所以沒有特別強調這些例外
→
07/26 13:30,
1月前
, 47F
07/26 13:30, 47F
同上
噓
07/26 17:25,
1月前
, 48F
07/26 17:25, 48F
→
07/26 17:25,
1月前
, 49F
07/26 17:25, 49F
→
07/26 17:26,
1月前
, 50F
07/26 17:26, 50F
→
07/26 17:27,
1月前
, 51F
07/26 17:27, 51F
這個功能並無涉檔案
這不是讓user上傳下載檔案的功能
很單純就是
系統根據user提供選項 顯示user選擇的選項
假設這是一個無法顯示圖檔的古系統
user 選 a/b/c 系統就顯示 a/b/c 其中之一
其實就只是這樣的簡單功能
推
07/26 22:24,
1月前
, 52F
07/26 22:24, 52F
→
07/26 22:24,
1月前
, 53F
07/26 22:24, 53F
→
07/26 22:24,
1月前
, 54F
07/26 22:24, 54F
→
07/26 22:24,
1月前
, 55F
07/26 22:24, 55F
→
07/26 22:24,
1月前
, 56F
07/26 22:24, 56F
→
07/26 22:24,
1月前
, 57F
07/26 22:24, 57F
→
07/26 22:24,
1月前
, 58F
07/26 22:24, 58F
但這例子就是實際的個案
把個案 抽像化成通案以後
再反過來看 當然就不適用所有個案
其實我只是要說 有些if else 不必要
但任何例子在特殊情況下當然有例外
※ 編輯: chal (36.235.109.212 臺灣), 07/27/2024 00:02:17
討論串 (同標題文章)
完整討論串 (本文為第 4 之 5 篇):
29
181
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章