阅读 174

为什们不喜欢viper和spring的设计

Viper

viper是golang里面的一个框架,一般用来解析配置文件,并将配置项作为全局变量放置在系统中,以供随时调用

Spring(Boot)

Spring是Java生态里面的最重要的框架之一,支持将Java代码作为类似于嵌入式脚本的方式运行,术语应该是Bean

通性

两者本是风马牛不相及的东西,生态和功能完全不在一个频道,没有理由放在一起,但是这两个还是让我不那么喜欢,因为它们都在做不那么合适的抽象

viper支持多种配置文件的解析,只要设置好配置文件可能在的目录,目录可能包含多个,viper就会每个目录每种格式的配置文件去查找,找到了就按照扩展名标识的格式去解析,然后作为一个全局变量存在下去,直到系统停止运行,非常方便。

Springs更加牛了,按照规定的装饰字段标识好类或者变量后,就可以将其通过配置文件运行起来,其间的乱七八糟的问题全部帮你搞定

为什么这么好的东西还不喜欢?

不是我矫情,也不是不欢迎先进的生产工具,主要原因是我不喜欢这种封装后带来的结果

首先系统和代码的可维护性是第一位的,系统的架构最好的应该是对人说一遍别人就能理解,而代码的逻辑甚至是自解释的才好 viper带来了便利,但同时也带来了一些没有必要的抽象和逻辑封装,换句话说,如果在项目中使用了viper,那除非你去仔细看一下viper的逻辑规则,否则你不知道怎么用。如果采用另外一种方案,规定好配置文件,然后直接解析对应的格式,解析的结果直接返回,那么即使第一次看代码的人也知道是怎么回事。viper只是一个简单的配置文件功能,如果不是一个简单的功能呢?例如Spring。

Spring的封装,如果没有非常详细的文档,你根本不知道怎么使用,除非能去阅读源码,但是成本非常高,还不如不用框架。

有很多人为Spring叫好,认为提高了生产效率,但是有一点,谁在叫好?

那些希望将程序员变成流水线工人的人在叫好,找来一批新人,只要会Java,培训一星期,就可以干活了,多好,多便宜,如果听话那就更加得到领导的喜欢了。

如果喜欢程序员的工作,那应该深刻意识到Spring带来的害处,不要局限于Java,出来看一下,世界还是很大的,也有更加精彩的地方。

去除系统中那些非必要的抽象,直接一点,不仅技术上更清晰,干活也没有那么累,岂不甚好?