PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 主管不認同書本的知識，說我沒學好程設

看板Soft_Job (軟體人)作者 (重出江湖)時間10年前 (2016/05/09 20:30), 10年前編輯推噓24(24推 0噓 59→)
留言83則, 23人參與, 最新討論串13/14 (看更多)
我只能說多數人很容易陷入以為全世界就是自己看的那樣 以成語來說大概就是以管窺天吧 你說每個類別都乖乖複製貼上 你有沒有遇過一次改版要改全部系統 然後你那些貼上的地方要一個一個改的情況? 我還真的有遇過而且才剛結束 有時候我真的很好奇是不是有公司用程式碼長度來算薪水的? 明明就是一樣的東西一樣的動作 就是有人不喜歡抽離成一個工具方法 然後每一個地方都複製貼上 最後如果要改版就得全部挖出來一個一個改 然後改的時候還要確認是不是有跟其他複製的地方不一樣 這樣有比較爽嘛? 我認為寫程式所謂的優美 指的是程式簡潔好讀 這不是什麼潔癖 而是為了讓你能準時下班的必備coding style 我名言就是「偷懶的最好方法就是一次把程式寫好」 一次寫好抽離能抽離的部份使之能改到最少 你程式問題少user也就少來靠北 你能準時下班的機會就多 一堆人寫出來的程式耦合性強到靠北 然後要改的時候就跟玩疊疊樂一樣 可能抽一塊積木就整個垮了 這時候也只能加班收拾自己造的孽不然還能幹麻? 然後因為耦合性太強太難改就會想一堆奇奇怪怪的解決方法 最後終於長成四不像的怪獸天天浪費自己甚至下一個接手人的生命 而且就我觀察 這種人幾乎都是覺得寫程式就是這樣阿 也不會再去思考是否有更好的解決方案 每次聽到有人在那邊大放厥詞說什麼物件導向、重構、設計模式沒用我就心裡偷笑 這跟公開大聲跟大家說「老子實力弱到連物件導向的好處都體會不到」一樣意思 這種東西你本來就是要會遇到你才知道他的好 沒有實際遇過你跟講一百遍你還是無法體會 寫過好幾年程式還不能體會這些好處 那我只能說什麼樣的人就會待在什麼樣等級的地方 這是我幹過駐點待過公司看過一堆人之後的心得 也是我給自己最大的警惕 ※ 引述《allenxxx (fufuxxx)》之銘言： : 個人是半路出家,去資策會閉關半年入這行的 : 不學無術先請別見怪 : 以我自己來說,從來不覺得程式寫法有甚麼優劣,程式是幫客戶解決問題的 : 只要能達到目的,效能可以達到,維護不困難 : 沒必要在那裏鼓吹什麼手法 : 當然或許是因為我做過很久的維運 : 個人反而不喜歡一堆抽象化的手法 : 當客戶火燒屁股電話追殺的時候 : 我還必須要追到抽象的類別或介面,然後判斷到底產生的是啥鳥物件 : 到底幹了那些好事 : 那開發者你還不如每一個類別乖乖地用複製貼上,我還比較好追 : 每個人都有自己立場 : 開發的人覺得自己的程式寫得很"優美",不重複 : 後頭維運的人如果技術層次跟不上 : 只有兩種可能,想辦法跟上,或是把問題踢回給你自己處理 : 另外像我有一個傾向 : 就是一個專案只要開始做,大家決定用甚麼技術後 : 不管有甚麼新的了不起技術 : 開會只要有人要用新東西,個人一概反對到底 : 除非不用無法解決現行問題,不然不管多沒水準還是一律要用一開始律定的技術 : 這是開發的紀律,要用請用在別的案子 : 很簡單,專案不是給你練功夫的 : 你懂別人不懂 : 不代表你厲害,只代表你"搖屁股",替"隊友"製造麻煩而已 : 像我就遇過很有進取心的同事 : 每一個功能,只要有進化的可能,他都要做點小修改 : 然後最初的功能跟最後寫的差很大... : 等到他走了 : 接手他的功能,大家幹到沒力! : 老兄,你還不如每個功能都一樣寫法! : 以RD來說,這當然是有點不進取,我也承認啦 : 不過就像前面說的 : 個人維運做很久 : 有時候必須想的不全然只有自己的立場 : 抱歉以上得罪諸多高手之處,再一次致上歉意 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.42.229.138 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462797038.A.76A.html
推
05/09 20:49, , 1F
不學無術請別見怪 人間已經打好預防針了
05/09 20:49, 1F
推
05/09 21:22, , 2F
也有例子是過度抽象化 改版也改不動的
05/09 21:22, 2F
→
05/09 21:24, , 3F
簡潔應指邏輯和演算法簡潔， 不是語法簡潔
05/09 21:24, 3F
簡潔的確在軟體中有很多含意 在這我的確指的是邏輯易讀好懂 像是code會有點髒但比較好讀跟簡潔但不好讀的寫法 我同常還是會選擇前者
推
05/09 21:43, , 4F
這篇要轉到軟體黑特版嗎XDD(誤)
05/09 21:43, 4F
我只黑特拖我下班時間的打字工(根本就不是工程師好嗎！！！) ※ 編輯: aoksc (114.42.229.138), 05/09/2016 21:50:30
推
05/09 22:03, , 5F
原PO怨念深重
05/09 22:03, 5F
推
05/09 22:29, , 6F
敏捷開發和重構需要拉扯一下 但是
05/09 22:29, 6F
→
05/09 22:30, , 7F
複製貼上和單元化 工廠化 之間沒有什麼懸念呀
05/09 22:30, 7F
→
05/09 22:31, , 8F
我曾經有一個多月和原Po有類似想法 鼓勵原Po多體會 DP意
05/09 22:31, 8F
→
05/09 22:31, , 9F
義阿
05/09 22:31, 9F
→
05/09 22:32, , 10F
嗯,物件大師, 高手.
05/09 22:32, 10F
→
05/09 22:33, , 11F
用了物件導向,就必然好維護,寫得快. 準時下班.
05/09 22:33, 11F
也沒那麼神 也是有人濫用搞到最後我還是要多花時間去處理的例子 技術的好壞最後還是操之於實現的人
推
05/09 22:34, , 12F
物件導向用的好的人 懂一些註解之美還是會讓程式很好讀
05/09 22:34, 12F
→
05/09 22:34, , 13F
的
05/09 22:34, 13F
推
05/09 22:42, , 14F
看完這篇感覺大大就是最會嘴炮那型吧??
05/09 22:42, 14F
還好啦 至少我都嘴的有所本 不服的話我也很歡迎來討戰…喔是討論
→
05/09 22:47, , 15F
物件導向不夠潮惹 現在最潮的是AI debug還有ML
05/09 22:47, 15F
推
05/09 22:47, , 16F
有時候重複貼也不一定是壞事 例如一開始可以共用
05/09 22:47, 16F
→
05/09 22:48, , 17F
但後來因需求改變 必須獨立出來不再共用 重複貼就很方便
05/09 22:48, 17F
→
05/09 22:49, , 18F
所以我覺得這depend on project 很難說誰對誰錯
05/09 22:49, 18F
受教了 我會再思考看看什麼情況用複製貼上是最好解法 但我看過的Code幾乎都是為了複製貼上而複製貼上…
推
05/09 23:04, , 19F
你慘了，提到OOP，等一下又有人要跳出來推廣他的神見解了
05/09 23:04, 19F
→
05/09 23:05, , 20F
話說@yyc1217，有需要獨立出來再COPY就好了啊XD，怕東西以
05/09 23:05, 20F
→
05/09 23:05, , 21F
後會獨立出來所以就重複貼不是因噎廢食嗎XD
05/09 23:05, 21F
→
05/09 23:06, , 22F
想想aoksc加班前說的話(誤)
05/09 23:06, 22F
※ 編輯: aoksc (114.42.229.138), 05/09/2016 23:18:43 ※ 編輯: aoksc (114.42.229.138), 05/09/2016 23:22:22
推
05/09 23:49, , 23F
現實上 C&P的人因為產出比較多, 生的比較快
05/09 23:49, 23F
→
05/09 23:49, , 24F
維護? 反正他升了, 這些東西留給下個人煩惱
05/09 23:49, 24F
→
05/10 00:09, , 25F
我遇到的是健保費 前人設計時沒想到後來有二代健保費
05/10 00:09, 25F
→
05/10 00:11, , 26F
科技部 自籌款 邁項頂尖大學計畫扣除的對象 比例都不同
05/10 00:11, 26F
→
05/10 00:11, , 27F
甚至學校 學院 系所等扣除的比例也不一樣 都是當初不會
05/10 00:11, 27F
→
05/10 00:12, , 28F
想到的 因為最初就一個健保費 誰知明後年會不會多個三代
05/10 00:12, 28F
→
05/10 00:13, , 29F
四代 又或是加收國保費之類的
05/10 00:13, 29F
→
05/10 00:15, , 30F
所以我想說的是複製貼上不一定是壞事 因為需求會一直變動
05/10 00:15, 30F
→
05/10 00:15, , 31F
最初設計的架構不一定能滿足後來的要求
05/10 00:15, 31F
→
05/10 00:18, , 32F
阿我講的是大學裡的狀況
05/10 00:18, 32F
推
05/10 00:24, , 33F
複製貼上，用來因應的是一次性，或者可預見的未來不會
05/10 00:24, 33F
→
05/10 00:25, , 34F
變動的需求，因為可能根本沒有下次用到的機會，或者跟
05/10 00:25, 34F
→
05/10 00:25, , 35F
本沒有修改的需要。反倒是如果預期每年規則都會有些修
05/10 00:25, 35F
→
05/10 00:26, , 36F
改，更需要設計一個有彈性的架構
05/10 00:26, 36F
推
05/10 00:28, , 37F
同感
05/10 00:28, 37F
推
05/10 00:43, , 38F
太中肯
05/10 00:43, 38F
推
05/10 08:47, , 39F
頗為同意
05/10 08:47, 39F
推
05/10 09:21, , 40F
我也同意 但有時就是人在江湖 身不由己 最好的解決辦法 就
05/10 09:21, 40F
→
05/10 09:22, , 41F
是換一個工作 不然就算拿你寫的跟主管據理力爭 大概又會被
05/10 09:22, 41F
→
05/10 09:22, , 42F
罵得更難聽 沒辦法 社會上這些人數量還不少
05/10 09:22, 42F
推
05/10 11:06, , 43F
現在同事寫了十支程式 結果每支有90%是copy % paste
05/10 11:06, 43F
推
05/10 13:34, , 44F
請他們去維護寫得好的, 之後就會從那 copy 去改了 :D
05/10 13:34, 44F
→
05/10 16:11, , 45F
現實上要知道功能是不是一次性有時很難
05/10 16:11, 45F
→
05/10 17:23, , 46F
沒那麼複雜，寫的時候問一下自己：下次什麼時候要跑這
05/10 17:23, 46F
→
05/10 17:23, , 47F
個？跑的時候要不要改東西？是不是參數改一下就可以？
05/10 17:23, 47F
→
05/10 17:24, , 48F
這樣大概就抓得出來。如果寫完下次要用發現要改code，
05/10 17:24, 48F
→
05/10 17:25, , 49F
就可以開始評估要不要簡單refactor。
05/10 17:25, 49F
→
05/10 20:28, , 50F
我之前有遇過要對兩種不同的class做很類似的事情
05/10 20:28, 50F
→
05/10 20:29, , 51F
除了class不同之外要回傳的顯示訊息也不太一樣
05/10 20:29, 51F
→
05/10 20:29, , 52F
還有兩個雖然做的是很類似的事但分屬不同功能區
05/10 20:29, 52F
→
05/10 20:30, , 53F
但是因為只有兩種而且要做的東西已經發展滿成熟了
05/10 20:30, 53F
→
05/10 20:31, , 54F
之後不太需要再變動 所以複製貼上應該也是不錯
05/10 20:31, 54F
→
05/10 20:32, , 55F
可以直接看出兩個方法用的東西不一樣
05/10 20:32, 55F
→
05/10 20:33, , 56F
不過如果勉強要抽離的話 我猜大概用泛型化或是參數
05/10 20:33, 56F
推
05/10 20:33, , 57F
樓上的狀況感覺蠻直觀, 丟個 msg map 進去要秀時 call
05/10 20:33, 57F
→
05/10 20:34, , 58F
傳入的複雜一點 裡面還要做一些分流判斷機制做不
05/10 20:34, 58F
→
05/10 20:34, , 59F
方法 showMsg(key), 這樣可以用同一個方法秀不同訊息
05/10 20:34, 59F
→
05/10 20:34, , 60F
同處理 不過為了兩種東西還有之後確定幾乎不會再
05/10 20:34, 60F
→
05/10 20:34, , 61F
做的事類似就抽 util 以上吃晚餐中隨便說 @@
05/10 20:34, 61F
→
05/10 20:35, , 62F
擴充的情況 我覺得複製貼上應該是比較清楚
05/10 20:35, 62F
→
05/10 20:35, , 63F
之後不會再動的話就隨便了 XD
05/10 20:35, 63F
→
05/10 20:36, , 64F
msg抽出來也是可以 不過我覺得例如錯誤訊息
05/10 20:36, 64F
→
05/10 20:37, , 65F
直接寫在那個方法的catch本身應該比較好讀
05/10 20:37, 65F
→
05/10 20:38, , 66F
例如有兩個類別在方法中間五各有5個trycatch訊息
05/10 20:38, 66F
→
05/10 20:38, , 67F
都有些不同，全抽出來丟到一個msg用key判別
05/10 20:38, 67F
→
05/10 20:39, , 68F
這樣看方法的時候每次看訊息都要再跑到msg方法裡找
05/10 20:39, 68F
推
05/10 20:51, , 69F
我說的很難判斷是不是一次性, 是指像是2代健保的狀況
05/10 20:51, 69F
→
05/10 20:51, , 70F
喔喔, 原來是 class 裡自己的訊息 @@
05/10 20:51, 70F
→
05/10 20:52, , 71F
有些政策面的改變會導致過去的假設失效
05/10 20:52, 71F
→
05/10 20:52, , 72F
他沒有任何邏輯可言
05/10 20:52, 72F
推
05/10 21:36, , 73F
(補推
05/10 21:36, 73F
→
05/10 23:13, , 74F
推這篇~觀念比較正確
05/10 23:13, 74F
推
05/11 01:30, , 75F
2代健保當然是當成一次性啊 XDD 這種東西不會每個禮拜
05/11 01:30, 75F
→
05/11 01:33, , 76F
改啦，至少是以年在計算的
05/11 01:33, 76F
推
05/11 08:06, , 77F
推
05/11 08:06, 77F
推
05/11 08:32, , 78F
我們team之前的做法是bad smell出現時會紀錄到管理技術
05/11 08:32, 78F
→
05/11 08:32, , 79F
債的表格，通常在下個sprint會做完修正，另外，紀錄的
05/11 08:32, 79F
→
05/11 08:32, , 80F
當下就會大略評估最晚何時要改。比如效能大約可以知道多
05/11 08:32, 80F
→
05/11 08:32, , 81F
少流量是極限，duplicate code這種我們會在出現第三次
05/11 08:32, 81F
→
05/11 08:32, , 82F
的時候開始設計重構。
05/11 08:32, 82F
推
05/12 09:59, , 83F
講得不錯啊！然後居然有人覺得複製貼上較好，神奇
05/12 09:59, 83F
‣ 更多 aoksc 的文章
文章代碼(AID): #1NC8BkTg (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 13 之 14 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共14篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 aoksc 的文章
文章代碼(AID): #1NC8BkTg (Soft_Job)