公司的高层对这个通用语言用得很好

到了编程的阶段,需要转化成代码,要用英文来表达了。

从中文到英文的转换,往往丢失一部分业务信息,产生一部分信息噪音,或者发生概念上的偏移。

很快, 在不同的系统,甚至同一个系统中,针对同一个业务概念存在三种以上不同的词汇。

模块间负责人探讨新功能的实现时,两边的沟通变得驴头不对马嘴

所以当你接手到这样的系统时,读代码的时候肯定是会骂娘的,但是读完之后也确实没有什么办法。

只要你负责维护,就持续地接受这种痛苦吧。

一个公司业务由多种语言实现,理论上可以吸引各种人才, 也会提供一个互相掐架的竞技场

实际上,在现行的微服务架构下,除了业务本身的研发人力投入之外,支持系统也有很大的工作量

如果每个服务都是一种技术栈,好家伙,一个轮子得造五遍。

对研发来说,可能也就是熟悉了五种语言的语法,并且写出了五种风格各异的 bug。

虽然公司对程序员的要求是可以随意地在不同语言技术栈之间切换,但程序员一般都有自己执著的美学偏好。

三个月后,张大胖离职了。

对于一个公司来说,不应该听信那些微服务布道师的胡言,任由公司内的技术栈随意分裂,最终在公司调整或者变化的时刻才发现积重难返。

该怎么把业务拆分成微服务呢?目前业界的微服务方法论一般也没有固定的套路。

在大企业中,顶着“架构师”头衔的这些架构师们根本就不会管任何实现上的细节。

相对较大的业务需求,一般也是一线的开发商量怎么进行实现上的拆分。想要达到合适的职责划分,需要多个合作方的所有人都靠谱才行。

于是,总会有些奇葩出现。

除了这些无法沟通的程序员,还有些奇葩的领导。

这样造成的结果是,所有逻辑的分布都具有不确定性,即薛定谔逻辑。

在你把所有模块的代码都看过之前,你是没法确定哪部分逻辑在哪个模块里的。

当模块发生负责人离职或者工作交接时,所有的开发都会进入非常痛苦的阶段,我只看自己的模块,根本没法理清全局的业务逻辑!

既然术语不统一,逻辑四处分散,难道不能重构一下吗?

在单体时代,重构有一套完整的方法论和最佳实践。

但演化到微服务的时代,原来很简单的重构就没那么简单了, 因为原本在代码中的强联系变成了分布式系统中的弱联系

当然,想重构也是可能的, 各个模块需要协调一致才可以,并且代价极为昂贵。

如果涉及到办公室政治,想重构就更难了!

重组是不可能重组的,最终的结果是,本来是一个人两天的活,生生堆了4个人,干了2个星期。

(完)

本漫画授权改编自公众号“TechPaper

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐