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

Viper

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

Spring(Boot)

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

通性

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

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

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

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

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

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

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

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

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

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

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