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

作者: aoksc (重出江湖)   2016-05-09 20:30:34
我只能說多數人很容易陷入以為全世界就是自己看的那樣
以成語來說大概就是以管窺天吧
你說每個類別都乖乖複製貼上
你有沒有遇過一次改版要改全部系統
然後你那些貼上的地方要一個一個改的情況?
我還真的有遇過而且才剛結束
有時候我真的很好奇是不是有公司用程式碼長度來算薪水的?
明明就是一樣的東西一樣的動作
就是有人不喜歡抽離成一個工具方法
然後每一個地方都複製貼上
最後如果要改版就得全部挖出來一個一個改
然後改的時候還要確認是不是有跟其他複製的地方不一樣
這樣有比較爽嘛?
我認為寫程式所謂的優美
指的是程式簡潔好讀
這不是什麼潔癖
而是為了讓你能準時下班的必備coding style
我名言就是「偷懶的最好方法就是一次把程式寫好」
一次寫好抽離能抽離的部份使之能改到最少
你程式問題少user也就少來靠北
你能準時下班的機會就多
一堆人寫出來的程式耦合性強到靠北
然後要改的時候就跟玩疊疊樂一樣
可能抽一塊積木就整個垮了
這時候也只能加班收拾自己造的孽不然還能幹麻?
然後因為耦合性太強太難改就會想一堆奇奇怪怪的解決方法
最後終於長成四不像的怪獸天天浪費自己甚至下一個接手人的生命
而且就我觀察
這種人幾乎都是覺得寫程式就是這樣阿
也不會再去思考是否有更好的解決方案
每次聽到有人在那邊大放厥詞說什麼物件導向、重構、設計模式沒用我就心裡偷笑
這跟公開大聲跟大家說「老子實力弱到連物件導向的好處都體會不到」一樣意思
這種東西你本來就是要會遇到你才知道他的好
沒有實際遇過你跟講一百遍你還是無法體會
寫過好幾年程式還不能體會這些好處
那我只能說什麼樣的人就會待在什麼樣等級的地方
這是我幹過駐點待過公司看過一堆人之後的心得
也是我給自己最大的警惕
※ 引述《allenxxx (fufuxxx)》之銘言:
: 個人是半路出家,去資策會閉關半年入這行的
: 不學無術先請別見怪
: 以我自己來說,從來不覺得程式寫法有甚麼優劣,程式是幫客戶解決問題的
: 只要能達到目的,效能可以達到,維護不困難
: 沒必要在那裏鼓吹什麼手法
: 當然或許是因為我做過很久的維運
: 個人反而不喜歡一堆抽象化的手法
: 當客戶火燒屁股電話追殺的時候
: 我還必須要追到抽象的類別或介面,然後判斷到底產生的是啥鳥物件
: 到底幹了那些好事
: 那開發者你還不如每一個類別乖乖地用複製貼上,我還比較好追
: 每個人都有自己立場
: 開發的人覺得自己的程式寫得很"優美",不重複
: 後頭維運的人如果技術層次跟不上
: 只有兩種可能,想辦法跟上,或是把問題踢回給你自己處理
: 另外像我有一個傾向
: 就是一個專案只要開始做,大家決定用甚麼技術後
: 不管有甚麼新的了不起技術
: 開會只要有人要用新東西,個人一概反對到底
: 除非不用無法解決現行問題,不然不管多沒水準還是一律要用一開始律定的技術
: 這是開發的紀律,要用請用在別的案子
: 很簡單,專案不是給你練功夫的
: 你懂別人不懂
: 不代表你厲害,只代表你"搖屁股",替"隊友"製造麻煩而已
: 像我就遇過很有進取心的同事
: 每一個功能,只要有進化的可能,他都要做點小修改
: 然後最初的功能跟最後寫的差很大...
: 等到他走了
: 接手他的功能,大家幹到沒力!
: 老兄,你還不如每個功能都一樣寫法!
: 以RD來說,這當然是有點不進取,我也承認啦
: 不過就像前面說的
: 個人維運做很久
: 有時候必須想的不全然只有自己的立場
: 抱歉以上得罪諸多高手之處,再一次致上歉意
作者: drajan (EasoN)   2016-05-09 20:49:00
不學無術請別見怪 人間已經打好預防針了
作者: CaptainH (Cannon)   2016-05-09 21:22:00
也有例子是過度抽象化 改版也改不動的簡潔應指邏輯和演算法簡潔, 不是語法簡潔
作者: mithuang (阿明)   2016-05-09 21:43:00
這篇要轉到軟體黑特版嗎XDD(誤)
作者: laputaflutin (很恐怖,不要問)   2016-05-09 22:03:00
原PO怨念深重
作者: airkolf (高雄特快車)   2016-05-09 22:29:00
敏捷開發和重構需要拉扯一下 但是複製貼上和單元化 工廠化 之間沒有什麼懸念呀我曾經有一個多月和原Po有類似想法 鼓勵原Po多體會 DP意義阿
作者: Lordaeron (Terry)   2016-05-09 22:32:00
嗯,物件大師, 高手.用了物件導向,就必然好維護,寫得快. 準時下班.
作者: airkolf (高雄特快車)   2016-05-09 22:34:00
物件導向用的好的人 懂一些註解之美還是會讓程式很好讀的
作者: final01 (牛頓運動定律)   2016-05-09 22:42:00
看完這篇感覺大大就是最會嘴炮那型吧??
作者: femlro (母豬教謀神異端審問官1.5)   2016-05-09 22:47:00
物件導向不夠潮惹 現在最潮的是AI debug還有ML
作者: yyc1217 (somo)   2016-05-09 22:47:00
有時候重複貼也不一定是壞事 例如一開始可以共用但後來因需求改變 必須獨立出來不再共用 重複貼就很方便所以我覺得這depend on project 很難說誰對誰錯
作者: a47135 (金屬史萊姆)   2016-05-09 23:04:00
你慘了,提到OOP,等一下又有人要跳出來推廣他的神見解了話說@yyc1217,有需要獨立出來再COPY就好了啊XD,怕東西以後會獨立出來所以就重複貼不是因噎廢食嗎XD想想aoksc加班前說的話(誤)
作者: atpx (秋雨的心情)   2016-05-09 23:49:00
現實上 C&P的人因為產出比較多, 生的比較快維護? 反正他升了, 這些東西留給下個人煩惱
作者: yyc1217 (somo)   2016-05-10 00:09:00
我遇到的是健保費 前人設計時沒想到後來有二代健保費科技部 自籌款 邁項頂尖大學計畫扣除的對象 比例都不同甚至學校 學院 系所等扣除的比例也不一樣 都是當初不會想到的 因為最初就一個健保費 誰知明後年會不會多個三代四代 又或是加收國保費之類的所以我想說的是複製貼上不一定是壞事 因為需求會一直變動最初設計的架構不一定能滿足後來的要求阿我講的是大學裡的狀況
作者: Blueshiva (龍野南雲)   2016-05-10 00:24:00
複製貼上,用來因應的是一次性,或者可預見的未來不會變動的需求,因為可能根本沒有下次用到的機會,或者跟本沒有修改的需要。反倒是如果預期每年規則都會有些修改,更需要設計一個有彈性的架構
作者: bacdasdf (醬爆)   2016-05-10 00:28:00
同感
作者: typepeter (∵Peter∴笑點)   2016-05-10 00:43:00
太中肯
作者: tyc5116 (累人啊....)   2016-05-10 08:47:00
頗為同意
作者: Argos (Big doge is watching u)   2016-05-10 09:21:00
我也同意 但有時就是人在江湖 身不由己 最好的解決辦法 就是換一個工作 不然就算拿你寫的跟主管據理力爭 大概又會被罵得更難聽 沒辦法 社會上這些人數量還不少
作者: hung0724 (三頭)   2016-05-10 11:06:00
現在同事寫了十支程式 結果每支有90%是copy % paste
作者: lovdkkkk (dk)   2016-05-10 13:34:00
請他們去維護寫得好的, 之後就會從那 copy 去改了 :D
作者: atpx (秋雨的心情)   2016-05-10 16:11:00
現實上要知道功能是不是一次性有時很難
作者: Blueshiva (龍野南雲)   2016-05-10 17:23:00
沒那麼複雜,寫的時候問一下自己:下次什麼時候要跑這個?跑的時候要不要改東西?是不是參數改一下就可以?這樣大概就抓得出來。如果寫完下次要用發現要改code,就可以開始評估要不要簡單refactor。
作者: VisualStudio (2015)   2016-05-10 20:28:00
我之前有遇過要對兩種不同的class做很類似的事情除了class不同之外要回傳的顯示訊息也不太一樣還有兩個雖然做的是很類似的事但分屬不同功能區但是因為只有兩種而且要做的東西已經發展滿成熟了之後不太需要再變動 所以複製貼上應該也是不錯可以直接看出兩個方法用的東西不一樣不過如果勉強要抽離的話 我猜大概用泛型化或是參數
作者: lovdkkkk (dk)   2016-05-10 20:33:00
樓上的狀況感覺蠻直觀, 丟個 msg map 進去要秀時 call
作者: VisualStudio (2015)   2016-05-10 20:34:00
傳入的複雜一點 裡面還要做一些分流判斷機制做不
作者: lovdkkkk (dk)   2016-05-10 20:34:00
方法 showMsg(key), 這樣可以用同一個方法秀不同訊息
作者: VisualStudio (2015)   2016-05-10 20:35:00
擴充的情況 我覺得複製貼上應該是比較清楚
作者: lovdkkkk (dk)   2016-05-10 20:35:00
之後不會再動的話就隨便了 XD
作者: VisualStudio (2015)   2016-05-10 20:36:00
msg抽出來也是可以 不過我覺得例如錯誤訊息直接寫在那個方法的catch本身應該比較好讀例如有兩個類別在方法中間五各有5個trycatch訊息都有些不同,全抽出來丟到一個msg用key判別這樣看方法的時候每次看訊息都要再跑到msg方法裡找
作者: atpx (秋雨的心情)   2016-05-10 20:51:00
我說的很難判斷是不是一次性, 是指像是2代健保的狀況
作者: lovdkkkk (dk)   2016-05-10 20:51:00
喔喔, 原來是 class 裡自己的訊息 @@
作者: atpx (秋雨的心情)   2016-05-10 20:52:00
有些政策面的改變會導致過去的假設失效他沒有任何邏輯可言
作者: VisualStudio (2015)   2016-05-10 21:36:00
(補推
作者: viper9709 (阿達)   2016-05-10 23:13:00
推這篇~觀念比較正確
作者: Blueshiva (龍野南雲)   2016-05-11 01:30:00
2代健保當然是當成一次性啊 XDD 這種東西不會每個禮拜改啦,至少是以年在計算的
作者: roger00 (Stage Column(?))   2016-05-11 08:06:00
作者: Masakiad (Masaki)   2016-05-11 08:32:00
我們team之前的做法是bad smell出現時會紀錄到管理技術債的表格,通常在下個sprint會做完修正,另外,紀錄的當下就會大略評估最晚何時要改。比如效能大約可以知道多少流量是極限,duplicate code這種我們會在出現第三次的時候開始設計重構。
作者: FukadaKyoko (小毛哥)   2016-05-12 09:59:00
講得不錯啊!然後居然有人覺得複製貼上較好,神奇

Links booklink

Contact Us: admin [ a t ] ucptt.com