推 marra: 推"尋寶遊戲"！XD 05/07 07:23
→ nh60211as: 確實，設計得亂七八糟但是連文件都不寫 05/07 07:27
推 lianpig5566: 尋寶XDD 05/07 08:11
→ gname: 哇... 高內聚低耦合已經不知道多少年沒聽到了... 05/07 08:35
→ Ekmund: 那依然是個很好的概念 只是要知道 過猶不及R 05/07 09:30
推 Lordaeron: [自己] 是對的。 05/07 09:43
推 kurtsgm: 這種就Overengineering 我之前遇過一個同事也這樣 05/07 09:50
→ kurtsgm: 要維護這種code有夠痛苦 跟義大利麵code半斤八兩 05/07 09:51
推 VScode: 我最後trace code是用全域搜尋 懶得找定義了 根本找不到 05/07 10:32
推 ypps6055: 這種設計以我的認知，根本不算好閱讀好維護，有些人曲 05/07 11:21
→ ypps6055: 解這個意思了 05/07 11:21
→ ypps6055: 過度拆分本身就導致維護管理困難，要跨一堆專案來看更 05/07 11:24
→ ypps6055: 稱不上好閱讀，有的人會因為書上或個人的強迫症導致變 05/07 11:24
→ ypps6055: 成這樣然後認為自己的東西很簡潔乾淨 05/07 11:24
推 accessdenied: 現在一堆人跟風什麼都 DI，全部都是 interface 找 05/07 11:44
→ accessdenied: 不到實作，找到後也會發現99%根本只有一個 class 05/07 11:44
→ accessdenied: 實作，浪費後人多少生命時間。 05/07 11:44
→ accessdenied: 而且 DI 的存在不就是為了單元測試隔離相依？結果這 05/07 11:44
→ accessdenied: 99%寫 DI 的專案裡根本完全沒有單元測試的專案！媽 05/07 11:45
→ accessdenied: 的寫心酸的喔？ 05/07 11:45
推 TPAsavelove: 老實說我是覺得開發時程吃緊根本不用做什麼interface 05/07 12:21
→ TPAsavelove: 功能穩定跟拆多少沒太多關係... 05/07 12:21
推 lonelytea: 這篇真的有寫實 05/07 12:39
推 zyxx: 沒文件的專案都是大便 文件很爛的專案跟大便沒兩樣 05/07 12:40
推 ck237: 推 尋寶遊戲 05/07 12:45
推 stepnight: 太真實 05/07 12:51
推 Lhmstu: 尋寶遊戲，笑死 05/07 13:04
→ Lipraxde: over design 了 05/07 13:07
推 k7ji91ab5m: 確實是過油不及啦 還是要抓平衡 05/07 14:09
推 kuosos520: 我最怕遇到接手一大堆搞自動化Gen code的神人專案 05/07 14:13
→ kuosos520: ，每次要改都不知道從哪裡改，結論就是一路擺爛到 05/07 14:13
→ kuosos520: 重構 05/07 14:13
→ tofuflower: 如果改一個功能七個 repo 都要動，那叫做高耦合。高 05/07 14:42
→ tofuflower: 內聚低耦合不是這樣搞的 05/07 14:42
→ ssccg: DI並不需要拆interface，最基本的用途應該是讓物件生命週期 05/07 14:42
→ ssccg: 能跟著某個context又不用自己new，倒不完全是為了測試 05/07 14:42
→ ssccg: interface都是等有第二種實作再重構抽的 05/07 14:43
推 SHANGOYANYI: 他可能以前是寫ejb的… 05/07 14:48
推 kattte: 我也遇過一個，做了三個月，產出0，整天跟人吵架 05/07 15:50
→ devilkool: .NET的Mock Library幾乎都只能Mock interface跟 05/07 17:38
→ devilkool: virtual method，不然我也不想弄這麼多interface 05/07 17:39
推 strlen: 改個東西要了解七大密寶叫什麼低耦合？這完全是人的問題 05/07 17:55
→ strlen: 低耦合的標準 其實就看程式語言本身的功能就懂啦 05/07 17:56
→ strlen: 每天都在用一堆內建函式 完全不需要理解函式怎麼運作的吧 05/07 17:59
→ strlen: 只要知道用它會發生啥事就好 每個模組就應該設計成這樣 05/07 17:59
→ strlen: 沒辦法達成這種效果 低耦合都馬自己講 05/07 18:00
→ strlen: 所以之前才說 要搞敏捷 搞agile 搞clean code 搞設計模式 05/07 18:00
→ strlen: 不是你說了算 你說clean就clean？是要大家來吵架決定的 05/07 18:01
→ strlen: 真正好維護的code 就是團隊緊密溝通（吵架）才弄得出來的 05/07 18:02
→ strlen: 但是齁 基本上工程師都馬文人相輕啦 看不起別人 都覺得別 05/07 18:02
→ strlen: 人寫得都垃圾 又自以為最聰明 其它人都低能 大頭症工程師 05/07 18:02
→ strlen: 滿街都是 這樣態度要合作？要吵架？有得吵了 呵呵 05/07 18:03
→ strlen: 吵到最後還有EQ不好的開始砍人勒 怕爆 05/07 18:03
推 qwe78971: 兩週的工作量 可以弄到8個 也是人才 05/07 18:56
推 luke72: 這個設計是為了以後團隊成長到幾萬人在開發這個專案 05/07 20:05
推 internetms52: 很同意前幾樓說的，DI本來可以方便測試，結果一個 05/07 20:07
→ internetms52: 測試也沒見到，XD 05/07 20:07
推 luke72: 8個repo算少了，我接手過一個single page app快100 repo 05/07 20:08
→ luke72: 大量的DI，說要重複使用，各種抽換 05/07 20:10
→ luke72: 結果連angular升版都做不到，整個砍掉重做 05/07 20:11
→ luke72: （原作者做不到） 05/07 20:11
推 abccbaandy: 拆越多通常問題也越多，比那種幾千行的還難維護 05/07 21:50
推 brianwu1201: 尋寶遊戲，笑死 05/07 22:12
→ superpandal: 功能本來就要做成顯示調用 隱藏實作細節的沒有不是垃 05/07 22:54
→ shooter555: 等到規模夠大才有差 05/07 22:56
→ superpandal: 圾的 難以追蹤也學不到東西 很可惜很多語言的DI是隱 05/07 22:56
→ superpandal: 式的 好的程式就是minimal外加不寫死保留點彈性 05/07 22:58
→ superpandal: 簡單來講就是可愛 但不利不被取代 主要是做成lib而非 05/07 23:02
→ superpandal: 弄微服務 這東西多數人用不到 全用http也很驚悚 05/07 23:04
推 viper9709: 這種就標準過度設計,殺雞用牛刀... 05/08 00:20
推 umidaisuki: 這篇很寫實XD 05/08 00:22
推 yuidzeon: 我超討厭微服務的 服務夠大就會拆部門了啊 等到那時候再 05/08 00:23
→ yuidzeon: 拆就好了 除非是業務需求需要切出去 (例如某個服務預期 05/08 00:23
→ yuidzeon: 會有大量流量要擴展) 現在一堆為拆而拆的 真的找 log 都 05/08 00:23
→ yuidzeon: 跟在找大秘寶一樣... 05/08 00:23
→ saladim: 會寫function+struct就很神了 真的 不止寫code 還有一堆 05/08 02:52
→ saladim: 流程之神 加個三層檢查才能進code, 解個bug開新branch 搞 05/08 02:54
→ saladim: 很多毛 有兩層做的有效的話就很好了 05/08 02:55
推 leftless: cleancode前幾頁就說寫程式是社交活動 然後他只會生氣 05/08 03:04
→ leftless: 叫他會去重看 05/08 03:05
推 marra: "是要大家來吵架決定的" XD 05/08 04:17
→ strlen: 我自己是覺得不要眼高手低啦 能讓你慢慢吵架寫一個超讚程 05/08 10:28
→ strlen: 式的環境幾乎不存在 大家平常忙死了誰要管你啊 如果你是香 05/08 10:29
→ strlen: 香妹子工程師那還願意花點時間跟你交流交流 但平常遇到都 05/08 10:29
→ strlen: 馬肥宅佔九成 說個話都能聞到口臭 誰想蕉流 05/08 10:30
→ strlen: 所以還是照著團隊的寫法跟著寫 絕不會錯 05/08 10:30
→ strlen: 大家怎麼寫 你就模仿大家怎麼寫 不要在那邊亂 標新立異 05/08 10:31
→ strlen: 要搞東搞西你的理想國自己side project愛怎玩就怎玩 05/08 10:31
推 gino0717: 桑原老師說過 架是要兩個人才能吵的 05/08 11:55
→ Suleika: 這就是標準的over design看過書不可能做出這種東西 05/08 12:36
推 transforman: 大祕寶XD 05/08 14:38
推 as6633208: 這個叫架構魔怔，設計時都會說擴充多方便，實際上擴充 05/08 17:46
→ as6633208: 次數不到兩次，然後要加個新功能極為麻煩 05/08 17:46
→ as6633208: 重劍無鋒，大巧不工，越是符合原生的應用，邏輯越簡單 05/08 17:49
→ as6633208: 又能達到目標越好，抽象注入太多一堆魔怔，最後都是只 05/08 17:49
→ as6633208: 有原設計者看得懂，後人接到改個幾次覺得很怪就重新打 05/08 17:49
→ as6633208: 掉了，真正可以留下來後人會維護的code，反而都是沒什 05/08 17:49
→ as6633208: 麼抽象的架構的code 05/08 17:49
推 tsaigi: over design 真的不行 05/08 18:11
推 awenracious: 就跟正規化一樣 你過度正規化只會找自己麻煩而已且 05/08 18:14
→ awenracious: 沒必要 05/08 18:14
→ alan3100: 這只是你單純沒接手dependency management跟IDE吧 05/08 23:46
→ alan3100: 2個禮拜能做出來的東西 如何over design到看不懂 05/08 23:46
推 viper9709: 推跟過度正規化一樣+1 05/09 00:36
推 jen1121: 這叫the show 05/09 00:47
→ Lordaeron: spring framework:.....我教的... 05/09 07:25
推 Csongs: 確實 05/09 09:03
→ Lordaeron: 凡事都加個interface,就spring 起的頭，然後蔓延出去. 05/09 09:58
→ b85040312: 一個 repo 只放一個 utils 是三小! 05/09 17:24
推 abccbaandy: 關spring啥事？ 他實作通常不只一個好嗎... 05/09 23:25
→ acgotaku: 其實選對 IDE 這些都不算是問題拉 認真的 05/09 23:58
→ acgotaku: 大型專案,掛個十來個 dependancy 是家常便飯 05/09 23:59
→ acgotaku: 不要搞不清楚概念亂設計,那種對 clean 一隻半解的才恐怖 05/10 00:04
→ acgotaku: 遇過那種一個 lib 做抽象,然後實踐實作在各種 lib 中 05/10 00:06
→ acgotaku: 的垃圾,開新 method 沒重複名稱功能全憑運氣 05/10 00:07
推 notimenofree: 太多這種案例了 頭很痛 05/10 05:49
→ superpandal: spring寫的通常實作確實一個居多 沒什麼多實作的應用 05/10 08:10
→ superpandal: 情境的 05/10 08:12
→ superpandal: ide多專案切換就是個麻煩了 編譯執行debug都是麻煩 05/10 08:17
→ superpandal: 跨專案字串補全 搜檔案都是 05/10 08:21
→ superpandal: 界面開新method然後物件已經有該method？ 05/10 08:27
→ superpandal: 沒聽懂你講什麼 這種東西應該是會報錯的 05/10 08:36
→ superpandal: 而且實作為何要獨立一包lib? 05/10 08:46
→ ssccg: spring自己是很多interface，但用spring寫東西根本用不到 05/10 15:16
→ ssccg: interface吧，spring的一個惡名不就是動態改你的class生成 05/10 15:18
→ ssccg: proxy，實際在跑的bytecode跟你寫的東西不同嗎? 05/10 15:18
→ ssccg: 連直接呼叫的method都能被偷改了，幹麻用inteface? 05/10 15:22
→ superpandal: 最多是替換實現 執行時改原來的類需要一些java底層知 05/10 20:53
→ superpandal: 識 通常就只是外面套一層用反射去hack 05/10 20:54
→ TaiwanUp: 搞不好他只是在練功 刻意練習 05/11 11:04
推 pttano: 你是不是在臭某網紅？ 05/11 17:48
推 jackypan1989: KISS 05/11 21:19
