※ 引述《neo5277 (I am an agent of chaos)》之銘言：
: 純粹對工作上來說
: 好抽換，好接手(易閱讀)，好維護(包含升級，測試
好接手，易閱讀…
我想到一個故事
幾年前有個同事，號稱國中時期就開始接案寫代碼
clean code,DDD滾瓜爛熟,對coding極度潔癖
印象比較深的是入職時說了句：我看到不規範的代碼會非常生氣
上工第一案子，設計一個工具網站，拆了七個GitHub repo
Micro services, grpc當年流行的工具全套了一輪
說是將低耦合，高內聚做到極致
其中一個repo 甚至只放了一個utils
後來來了另一個人接手
改個功能要先看懂七個repo之間關聯，跟找大秘寶似的
在review code階段，還埋個彩蛋，發現了隱藏的第八個repo
新來的同事說改不動了，就算加個menu都很麻煩
心一橫，提案該網站功能也不複雜，全部打掉重做
就自己埋頭花了兩週重做了那個網站加遷移
工程師追求的很簡單，(自己）好閱讀，（自己）好維護就行了

推"尋寶遊戲"！XD

確實，設計得亂七八糟但是連文件都不寫

尋寶XDD

哇... 高內聚低耦合已經不知道多少年沒聽到了...

那依然是個很好的概念 只是要知道 過猶不及R

[自己] 是對的。

這種就Overengineering 我之前遇過一個同事也這樣要維護這種code有夠痛苦 跟義大利麵code半斤八兩

我最後trace code是用全域搜尋 懶得找定義了 根本找不到

這種設計以我的認知，根本不算好閱讀好維護，有些人曲解這個意思了過度拆分本身就導致維護管理困難，要跨一堆專案來看更稱不上好閱讀，有的人會因為書上或個人的強迫症導致變成這樣然後認為自己的東西很簡潔乾淨

現在一堆人跟風什麼都 DI，全部都是 interface 找不到實作，找到後也會發現99%根本只有一個 class實作，浪費後人多少生命時間。而且 DI 的存在不就是為了單元測試隔離相依？結果這99%寫 DI 的專案裡根本完全沒有單元測試的專案！媽的寫心酸的喔？

老實說我是覺得開發時程吃緊根本不用做什麼interface功能穩定跟拆多少沒太多關係...

這篇真的有寫實

沒文件的專案都是大便 文件很爛的專案跟大便沒兩樣

推 尋寶遊戲

太真實

尋寶遊戲，笑死

over design 了

確實是過油不及啦 還是要抓平衡

我最怕遇到接手一大堆搞自動化Gen code的神人專案，每次要改都不知道從哪裡改，結論就是一路擺爛到重構

如果改一個功能七個 repo 都要動，那叫做高耦合。高內聚低耦合不是這樣搞的

DI並不需要拆interface，最基本的用途應該是讓物件生命週期能跟著某個context又不用自己new，倒不完全是為了測試interface都是等有第二種實作再重構抽的

他可能以前是寫ejb的…

我也遇過一個，做了三個月，產出0，整天跟人吵架

.NET的Mock Library幾乎都只能Mock interface跟virtual method，不然我也不想弄這麼多interface

改個東西要了解七大密寶叫什麼低耦合？這完全是人的問題低耦合的標準 其實就看程式語言本身的功能就懂啦每天都在用一堆內建函式 完全不需要理解函式怎麼運作的吧只要知道用它會發生啥事就好 每個模組就應該設計成這樣沒辦法達成這種效果 低耦合都馬自己講所以之前才說 要搞敏捷 搞agile 搞clean code 搞設計模式不是你說了算 你說clean就clean？是要大家來吵架決定的真正好維護的code 就是團隊緊密溝通（吵架）才弄得出來的但是齁 基本上工程師都馬文人相輕啦 看不起別人 都覺得別人寫得都垃圾 又自以為最聰明 其它人都低能 大頭症工程師滿街都是 這樣態度要合作？要吵架？有得吵了 呵呵吵到最後還有EQ不好的開始砍人勒 怕爆

兩週的工作量 可以弄到8個 也是人才

這個設計是為了以後團隊成長到幾萬人在開發這個專案

很同意前幾樓說的，DI本來可以方便測試，結果一個測試也沒見到，XD

8個repo算少了，我接手過一個single page app快100 repo大量的DI，說要重複使用，各種抽換結果連angular升版都做不到，整個砍掉重做（原作者做不到）

拆越多通常問題也越多，比那種幾千行的還難維護

尋寶遊戲，笑死

功能本來就要做成顯示調用 隱藏實作細節的沒有不是垃

等到規模夠大才有差

圾的 難以追蹤也學不到東西 很可惜很多語言的DI是隱式的 好的程式就是minimal外加不寫死保留點彈性簡單來講就是可愛 但不利不被取代 主要是做成lib而非弄微服務 這東西多數人用不到 全用http也很驚悚

這種就標準過度設計,殺雞用牛刀...

這篇很寫實XD

我超討厭微服務的 服務夠大就會拆部門了啊 等到那時候再拆就好了 除非是業務需求需要切出去 (例如某個服務預期會有大量流量要擴展) 現在一堆為拆而拆的 真的找 log 都跟在找大秘寶一樣...

會寫function+struct就很神了 真的 不止寫code 還有一堆流程之神 加個三層檢查才能進code, 解個bug開新branch 搞很多毛 有兩層做的有效的話就很好了

cleancode前幾頁就說寫程式是社交活動 然後他只會生氣叫他會去重看

"是要大家來吵架決定的" XD

我自己是覺得不要眼高手低啦 能讓你慢慢吵架寫一個超讚程式的環境幾乎不存在 大家平常忙死了誰要管你啊 如果你是香香妹子工程師那還願意花點時間跟你交流交流 但平常遇到都馬肥宅佔九成 說個話都能聞到口臭 誰想蕉流所以還是照著團隊的寫法跟著寫 絕不會錯大家怎麼寫 你就模仿大家怎麼寫 不要在那邊亂 標新立異要搞東搞西你的理想國自己side project愛怎玩就怎玩

桑原老師說過 架是要兩個人才能吵的

這就是標準的over design看過書不可能做出這種東西

大祕寶XD

這個叫架構魔怔，設計時都會說擴充多方便，實際上擴充次數不到兩次，然後要加個新功能極為麻煩重劍無鋒，大巧不工，越是符合原生的應用，邏輯越簡單又能達到目標越好，抽象注入太多一堆魔怔，最後都是只有原設計者看得懂，後人接到改個幾次覺得很怪就重新打掉了，真正可以留下來後人會維護的code，反而都是沒什麼抽象的架構的code

over design 真的不行

就跟正規化一樣 你過度正規化只會找自己麻煩而已且沒必要

這只是你單純沒接手dependency management跟IDE吧2個禮拜能做出來的東西 如何over design到看不懂

推跟過度正規化一樣+1

這叫the show

spring framework:.....我教的...

確實

凡事都加個interface,就spring 起的頭，然後蔓延出去.

一個 repo 只放一個 utils 是三小!

關spring啥事？ 他實作通常不只一個好嗎...

其實選對 IDE 這些都不算是問題拉 認真的大型專案,掛個十來個 dependancy 是家常便飯不要搞不清楚概念亂設計,那種對 clean 一隻半解的才恐怖遇過那種一個 lib 做抽象,然後實踐實作在各種 lib 中的垃圾,開新 method 沒重複名稱功能全憑運氣

太多這種案例了 頭很痛

spring寫的通常實作確實一個居多 沒什麼多實作的應用情境的ide多專案切換就是個麻煩了 編譯執行debug都是麻煩跨專案字串補全 搜檔案都是

spring自己是很多interface，但用spring寫東西根本用不到interface吧，spring的一個惡名不就是動態改你的class生成proxy，實際在跑的bytecode跟你寫的東西不同嗎?連直接呼叫的method都能被偷改了，幹麻用inteface?

最多是替換實現 執行時改原來的類需要一些java底層知識 通常就只是外面套一層用反射去hack

搞不好他只是在練功 刻意練習

你是不是在臭某網紅？

KISS

(自己)

只有一個git repo跟很多repo 我支持很多repo....All in one真的很噁心...