推 drajan: 不學無術請別見怪 人間已經打好預防針了 05/09 20:49
推 CaptainH: 也有例子是過度抽象化 改版也改不動的 05/09 21:22
→ CaptainH: 簡潔應指邏輯和演算法簡潔, 不是語法簡潔 05/09 21:24
簡潔的確在軟體中有很多含意
在這我的確指的是邏輯易讀好懂
像是code會有點髒但比較好讀跟簡潔但不好讀的寫法
我同常還是會選擇前者
推 mithuang: 這篇要轉到軟體黑特版嗎XDD(誤) 05/09 21:43
我只黑特拖我下班時間的打字工(根本就不是工程師好嗎!!!)
※ 編輯: aoksc (114.42.229.138), 05/09/2016 21:50:30
推 laputaflutin: 原PO怨念深重 05/09 22:03
推 airkolf: 敏捷開發和重構需要拉扯一下 但是 05/09 22:29
→ airkolf: 複製貼上和單元化 工廠化 之間沒有什麼懸念呀 05/09 22:30
→ airkolf: 我曾經有一個多月和原Po有類似想法 鼓勵原Po多體會 DP意 05/09 22:31
→ airkolf: 義阿 05/09 22:31
→ Lordaeron: 嗯,物件大師, 高手. 05/09 22:32
→ Lordaeron: 用了物件導向,就必然好維護,寫得快. 準時下班. 05/09 22:33
也沒那麼神
也是有人濫用搞到最後我還是要多花時間去處理的例子
技術的好壞最後還是操之於實現的人
推 airkolf: 物件導向用的好的人 懂一些註解之美還是會讓程式很好讀 05/09 22:34
→ airkolf: 的 05/09 22:34
推 final01: 看完這篇感覺大大就是最會嘴炮那型吧?? 05/09 22:42
還好啦
至少我都嘴的有所本
不服的話我也很歡迎來討戰…喔是討論
→ femlro: 物件導向不夠潮惹 現在最潮的是AI debug還有ML 05/09 22:47
推 yyc1217: 有時候重複貼也不一定是壞事 例如一開始可以共用 05/09 22:47
→ yyc1217: 但後來因需求改變 必須獨立出來不再共用 重複貼就很方便 05/09 22:48
→ yyc1217: 所以我覺得這depend on project 很難說誰對誰錯 05/09 22:49
受教了
我會再思考看看什麼情況用複製貼上是最好解法
但我看過的Code幾乎都是為了複製貼上而複製貼上…
推 a47135: 你慘了,提到OOP,等一下又有人要跳出來推廣他的神見解了 05/09 23:04
→ a47135: 話說@yyc1217,有需要獨立出來再COPY就好了啊XD,怕東西以 05/09 23:05
→ a47135: 後會獨立出來所以就重複貼不是因噎廢食嗎XD 05/09 23:05
→ a47135: 想想aoksc加班前說的話(誤) 05/09 23:06
※ 編輯: aoksc (114.42.229.138), 05/09/2016 23:18:43
※ 編輯: aoksc (114.42.229.138), 05/09/2016 23:22:22
推 atpx: 現實上 C&P的人因為產出比較多, 生的比較快 05/09 23:49
→ atpx: 維護? 反正他升了, 這些東西留給下個人煩惱 05/09 23:49
→ yyc1217: 我遇到的是健保費 前人設計時沒想到後來有二代健保費 05/10 00:09
→ yyc1217: 科技部 自籌款 邁項頂尖大學計畫扣除的對象 比例都不同 05/10 00:11
→ yyc1217: 甚至學校 學院 系所等扣除的比例也不一樣 都是當初不會 05/10 00:11
→ yyc1217: 想到的 因為最初就一個健保費 誰知明後年會不會多個三代 05/10 00:12
→ yyc1217: 四代 又或是加收國保費之類的 05/10 00:13
→ yyc1217: 所以我想說的是複製貼上不一定是壞事 因為需求會一直變動 05/10 00:15
→ yyc1217: 最初設計的架構不一定能滿足後來的要求 05/10 00:15
→ yyc1217: 阿我講的是大學裡的狀況 05/10 00:18
推 Blueshiva: 複製貼上,用來因應的是一次性,或者可預見的未來不會 05/10 00:24
→ Blueshiva: 變動的需求,因為可能根本沒有下次用到的機會,或者跟 05/10 00:25
→ Blueshiva: 本沒有修改的需要。反倒是如果預期每年規則都會有些修 05/10 00:25
→ Blueshiva: 改,更需要設計一個有彈性的架構 05/10 00:26
推 bacdasdf: 同感 05/10 00:28
推 typepeter: 太中肯 05/10 00:43
推 tyc5116: 頗為同意 05/10 08:47
推 Argos: 我也同意 但有時就是人在江湖 身不由己 最好的解決辦法 就 05/10 09:21
→ Argos: 是換一個工作 不然就算拿你寫的跟主管據理力爭 大概又會被 05/10 09:22
→ Argos: 罵得更難聽 沒辦法 社會上這些人數量還不少 05/10 09:22
推 hung0724: 現在同事寫了十支程式 結果每支有90%是copy % paste 05/10 11:06
推 lovdkkkk: 請他們去維護寫得好的, 之後就會從那 copy 去改了 :D 05/10 13:34
→ atpx: 現實上要知道功能是不是一次性有時很難 05/10 16:11
→ Blueshiva: 沒那麼複雜,寫的時候問一下自己:下次什麼時候要跑這 05/10 17:23
→ Blueshiva: 個?跑的時候要不要改東西?是不是參數改一下就可以? 05/10 17:23
→ Blueshiva: 這樣大概就抓得出來。如果寫完下次要用發現要改code, 05/10 17:24
→ Blueshiva: 就可以開始評估要不要簡單refactor。 05/10 17:25
→ VisualStudio: 我之前有遇過要對兩種不同的class做很類似的事情 05/10 20:28
→ VisualStudio: 除了class不同之外要回傳的顯示訊息也不太一樣 05/10 20:29
→ VisualStudio: 還有兩個雖然做的是很類似的事但分屬不同功能區 05/10 20:29
→ VisualStudio: 但是因為只有兩種而且要做的東西已經發展滿成熟了 05/10 20:30
→ VisualStudio: 之後不太需要再變動 所以複製貼上應該也是不錯 05/10 20:31
→ VisualStudio: 可以直接看出兩個方法用的東西不一樣 05/10 20:32
→ VisualStudio: 不過如果勉強要抽離的話 我猜大概用泛型化或是參數 05/10 20:33
推 lovdkkkk: 樓上的狀況感覺蠻直觀, 丟個 msg map 進去要秀時 call 05/10 20:33
→ VisualStudio: 傳入的複雜一點 裡面還要做一些分流判斷機制做不 05/10 20:34
→ lovdkkkk: 方法 showMsg(key), 這樣可以用同一個方法秀不同訊息 05/10 20:34
→ VisualStudio: 同處理 不過為了兩種東西還有之後確定幾乎不會再 05/10 20:34
→ lovdkkkk: 做的事類似就抽 util 以上吃晚餐中隨便說 @@ 05/10 20:34
→ VisualStudio: 擴充的情況 我覺得複製貼上應該是比較清楚 05/10 20:35
→ lovdkkkk: 之後不會再動的話就隨便了 XD 05/10 20:35
→ VisualStudio: msg抽出來也是可以 不過我覺得例如錯誤訊息 05/10 20:36
→ VisualStudio: 直接寫在那個方法的catch本身應該比較好讀 05/10 20:37
→ VisualStudio: 例如有兩個類別在方法中間五各有5個trycatch訊息 05/10 20:38
→ VisualStudio: 都有些不同,全抽出來丟到一個msg用key判別 05/10 20:38
→ VisualStudio: 這樣看方法的時候每次看訊息都要再跑到msg方法裡找 05/10 20:39
推 atpx: 我說的很難判斷是不是一次性, 是指像是2代健保的狀況 05/10 20:51
→ lovdkkkk: 喔喔, 原來是 class 裡自己的訊息 @@ 05/10 20:51
→ atpx: 有些政策面的改變會導致過去的假設失效 05/10 20:52
→ atpx: 他沒有任何邏輯可言 05/10 20:52
推 VisualStudio: (補推 05/10 21:36
→ viper9709: 推這篇~觀念比較正確 05/10 23:13
推 Blueshiva: 2代健保當然是當成一次性啊 XDD 這種東西不會每個禮拜 05/11 01:30
→ Blueshiva: 改啦,至少是以年在計算的 05/11 01:33
推 roger00: 推 05/11 08:06
推 Masakiad: 我們team之前的做法是bad smell出現時會紀錄到管理技術 05/11 08:32
→ Masakiad: 債的表格,通常在下個sprint會做完修正,另外,紀錄的 05/11 08:32
→ Masakiad: 當下就會大略評估最晚何時要改。比如效能大約可以知道多 05/11 08:32
→ Masakiad: 少流量是極限,duplicate code這種我們會在出現第三次 05/11 08:32
→ Masakiad: 的時候開始設計重構。 05/11 08:32
推 FukadaKyoko: 講得不錯啊!然後居然有人覺得複製貼上較好,神奇 05/12 09:59