公司的高層對這個通用語言用得很好
到了編程的階段，需要轉化成代碼，要用英文來表達了，
從中文到英文的轉換，往往丟失一部分業務資訊，產生一部分資訊噪音，或者發生概念上的偏移，
很快， 在不同的系統，甚至同一個系統中，針對同一個業務概念存在三種以上不同的詞匯，
模塊間負責人探討新功能的實作時，兩邊的溝通變得驢頭不對馬嘴
所以當你接手到這樣的系統時，讀代碼的時候肯定是會罵娘的，但是讀完之后也確實沒有什么辦法，
只要你負責維護，就持續地接受這種痛苦吧，
一個公司業務由多種語言實作，理論上可以吸引各種人才， 也會提供一個互相掐架的競技場
實際上，在現行的微服務架構下，除了業務本身的研發人力投入之外，支持系統也有很大的作業量
如果每個服務都是一種技術堆疊，好家伙，一個輪子得造五遍，
對研發來說，可能也就是熟悉了五種語言的語法，并且寫出了五種風格各異的 bug，
雖然公司對程式員的要求是可以隨意地在不同語言技術堆疊之間切換，但程式員一般都有自己執著的美學偏好，
三個月后，張大胖離職了，
對于一個公司來說，不應該聽信那些微服務布道師的胡言，任由公司內的技術堆疊隨意分裂，最終在公司調整或者變化的時刻才發現積重難返，
該怎么把業務拆分成微服務呢？目前業界的微服務方法論一般也沒有固定的套路，
在大企業中，頂著“架構師”頭銜的這些架構師們根本就不會管任何實作上的細節，
相對較大的業務需求，一般也是一線的開發商量怎么進行實作上的拆分，想要達到合適的職責劃分，需要多個合作方的所有人都靠譜才行，
于是，總會有些奇葩出現，
除了這些無法溝通的程式員，還有些奇葩的領導，
這樣造成的結果是，所有邏輯的分布都具有不確定性，即薛定諤邏輯，
在你把所有模塊的代碼都看過之前，你是沒法確定哪部分邏輯在哪個模塊里的，
當模塊發生負責人離職或者作業交接時，所有的開發都會進入非常痛苦的階段，我只看自己的模塊，根本沒法理清全域的業務邏輯！
既然術語不統一，邏輯四處分散，難道不能重構一下嗎？
在單體時代，重構有一套完整的方法論和最佳實踐，
但演化到微服務的時代，原來很簡單的重構就沒那么簡單了， 因為原本在代碼中的強聯系變成了分布式系統中的弱聯系
當然，想重構也是可能的， 各個模塊需要協調一致才可以，并且代價極為昂貴，
如果涉及到辦公室政治，想重構就更難了！
重組是不可能重組的，最終的結果是，本來是一個人兩天的活，生生堆了4個人，干了2個星期，
（完）
本漫畫授權改編自公眾號“TechPaper”
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/289645.html
標籤：其他
下一篇：C語言———冒泡演算法