Re: [討論] 系統越開發越多，負責的東西越來越多

其實我不是在講很嚴格的微服務 微服務如果單論工具的話 其實spirng cloud 出的工具 大概花一點時間學不會太難 工具主要是提供服務之間的溝通與發現 其實就是一些工具設定 但我覺得微服務主要的難點有二個 一個是 服務怎麼切 以及 系統小時候你沒機會用微服務 系統大的時成本太大 服務怎麼切有一個作法是DDD 裡面又延伸很多術語 DDD是早於微服務的 我也不是全部都懂就不多說了 DDD的副標是 軟體核心複雜度的解決方法 我覺得這個才是治本的作法 有很多管理複雜度的作法 比如說去code review 人員教育 都是比較事後 且要公司有餘裕的條件下才能做的治標作法 我是覺得程式會亂是出於每個人的思考都是不同的 還有時間壓力 所以要靠事後的管理來維持程式的不混亂是很難的 而且成本不小 可以提昇品質 但很難維持 換個主管說不定政策就變了 有的程式是老鳥寫的 早已離職 有的程式是菜鳥寫的 沒辦法寫的好 時間壓力下能動就上線是台灣公司常態 另外程式的寫法有百百種 不同的思考也可以完成相同的目的 這也是程式的一種亂 既然亂是改變不了的 那我們就不該想的是讓他不亂 而是說亂是一定會亂的 但是控制他的大小 就像你有一個像汽車一樣大的毛線球 非常紊亂而且預期汽車毛線球還會一直長大 VS 你有300顆棒球大小的毛線球 而主要核心的毛線球可能十來顆 你控制的不是亂 而是大小 很小的毛線球再怎麼亂你也有能力救 另一個難題就是系統很大時才要改微服務 比如說把會員服務抽出來（不同DB） 你以前撈會員資料是用sql撈 現在要改用token串api接json 那可能5000支程式裡有幾百支直接間接用到的程式都要改 花半年改了以後 老闆問你花半年的時間 系統怎麼沒有任何變化 所以我也不是鼓勵大老系統去改這個 而是說 作法上概念可以往這方面接近 例如新的業務就不要再加在原來的大老系統上 總之 我不是在講很嚴格定義的微服務 而是在說 控制系統越來越大越來越亂的方法 可以有兩個維度 一個做法是專注在讓它不要亂 另一個是專注在讓它不要長大 想辦法讓他不要長大 小東西就算亂 也亂不到那裡去 有天你想好好整理 小東西也是看得到隧道的光亮 控制大小是利用框架與工具 控制品質則是主管與人的思考教育 我是覺得控制大小才是長遠的解決之道 但也不是說兩者衝突 其實也可以並行 只是在不同時間點的優先順序不同