说说我为什么开始放弃 Spring Framework

Answer 1

作为Java开发人员，Spring框架是我最常用的框架之一。Spring这个名字简洁而有寓意，它代表着程序员的春天，同时Spring还象征着弹性，提供强大的扩展性。然而，在使用Spring的过程中，我逐渐开始质疑它的一些核心特性。

首先，Spring带来了强大的魔法，如自动注入（IoC）和面向切面编程（AOP），这些特性使得代码管理更加高效，增强了代码的可增强性。然而，动态技术也带来了新的挑战。Java本来是一个静态类型语言，拥有严格的类型约束，但Spring的动态技术打破了这种约束。SpEL（Spring Expression Language）是一个动态表达式语言，虽然提供了简洁的逻辑构建方式，但缺乏类型检查，这使得在IDE中没有足够的提示功能。这样的设计使得编写代码时存在潜在的危险，如变量名错误但程序仍能运行的情况，虽然参数拼接总是null，但导致了使用相同缓存数据。使用API形式可以避免此类问题，但便利性会有所下降。

其次，Spring的复杂度问题也不容忽视。Spring框架在设计时遵循面向接口和面向对象的原则，导致了继承和依赖关系的复杂性。复杂的代码结构和动态字节码技术的运用使得阅读源码变得困难，方法跳转和理解实现逻辑需要花费大量时间。虽然这对于解决复杂问题至关重要，但在遇到错误排查或调试代码时，这一复杂性会成为障碍。

随着生态的不断发展，Spring已成为一个庞大的框架，学习曲线陡峭，需要较高的成本才能熟练掌握。这种复杂性导致了所谓的“Spring八股文”现象，即大量的面试题和攻略在互联网上流行。中等规模的Spring Boot项目通常需要消耗1G的内存，而部署一个Spring Boot实例所消耗的内存，足以部署五六个vert.x实例。某些项目甚至需要长达1分半的启动时间，这导致了资源占用和性能问题。

Spring的不可靠性也逐渐显现。动态技术带来了一系列坑，如事务失效的12种场景等。这些坑不仅增加了代码的复杂性，也使得问题难以察觉和解决。有些公司甚至禁止使用声明式事务，因为它们可能导致不明显的副作用，如缓存和校验失效。AOP技术的滥用也带来了不确定性，使得代码的执行路径难以追踪，增加了代码维护的难度。更糟糕的是，Spring Boot的自动配置可能存在安全风险，恶意代码可以通过自动配置在启动阶段执行。

经过深思熟虑，我发现Spring并不完美。动态字节码和代理技术虽然提供了灵活性，但也牺牲了静态语言的严谨性，使得编译期错误难以发现，只有运行时才能揭示问题。虽然IoC降低了耦合性，但我认为并非必须。在实际项目中，代码往往没有太多实现，不需要无缝替换或热插拔，而更高层次的抽象可能会导致失去部分原生特性的损失，甚至增加程序的复杂度。面向对象和面向接口的设计原则并不总是适用，有时过度设计反而会增加开发的复杂性。

基于以上考量，我决定不再局限于使用Spring框架。虽然Spring是一个有影响力的框架，但团队的一致性并非必须。探索其他解决方案对于我来说更具吸引力。在Java语言中，尽管存在不便之处，但动态字节码和代理技术并非解决所有问题的良药。了解其他语言并拓宽视野对于提升技术能力至关重要，这有助于打破固有思维模式，开阔开发者的思维格局。