July 26, 2017 at 18:33Why i hate spring
- Transfer
At the beginning of my career, I really fell in love with Spring . I have been waiting for him for so long. I used it in all my projects. In addition, I even managed to stuff a bunch of stuff from Spring Integration . I was something like the king of XML. I made an RPC layer based on JMS, protobufs and Kaazing for our entire department and the bank as a whole. I thought: “This is so configurable. Just a couple of XML files is really flexible. ” I was very pleased with myself.
But some of my colleagues were inclined to disagree. They had problems when they tried to connect everything the way they want; they didn’t know where which XML files they needed. There were problems with Spring versions, how to make friends with them (I also went far with modularity: we had 5 or 6 different modules with different version numbers, and we couldn’t just figure out which one to use without asking me). These were alarming calls, but I did not notice them; I thought more documentation was needed or that those guys were just dumb. This situation is typical in itself: the pleas of users of one of the most unloved and difficult to use frameworks for help often break down about “yes there is one file and a few parameters, it’s not so difficult”, while everyone else is trying to find all day a magical combination of files and parameters,
I still work in the same organization, but now I am a user of my old framework. As a result of this feeding my dog’s food, I began to hate Sam (author means himself - approx. Per. ) 2009-2010 for several reasons, but mostly for Spring. Spring is evil in good weather, but when it is included in the library or API that other programmers use, it is a different level of evil: as the fruit of Hitler and the devil's love. Do not let Spring stick out of your API.
Spring sucks for a number of reasons, and I felt that they should be listed, because there are no clear counterarguments on google.
The thing is that I'm sure: it’s theoretically successful to use Spring in an applicationperhaps. I have never seen this before, and this is a problem. As for me, all the “goodies” that he offers are quite possible without him. When we ask about Spring for an interview, the candidate usually answers: “With Spring, you have clean code, separation of responsibilities, and it’s really good for testing.” In general, all those things that I am a big fan of (especially testing), but in reality these are the results not of using Spring, but of good programming. For beginners, Spring may be a good crutch for developing ideas such as dependency injection, mocking, and testing, but they are actually orthogonal to Spring. If you use a TDD, you have in the code will not be setters and getters - only dependency injection through constructors that you can, "the deputy of"for testing", and then, when you bundle your application together, simply use the often forgotten way to create objects - the keyword "new". Often we create the “ApplicationContext” class, which is responsible for linking everything together. It is clean, everything is testable, I have compile time safety, and my tests run damn fast.
But some of my colleagues were inclined to disagree. They had problems when they tried to connect everything the way they want; they didn’t know where which XML files they needed. There were problems with Spring versions, how to make friends with them (I also went far with modularity: we had 5 or 6 different modules with different version numbers, and we couldn’t just figure out which one to use without asking me). These were alarming calls, but I did not notice them; I thought more documentation was needed or that those guys were just dumb. This situation is typical in itself: the pleas of users of one of the most unloved and difficult to use frameworks for help often break down about “yes there is one file and a few parameters, it’s not so difficult”, while everyone else is trying to find all day a magical combination of files and parameters,
I still work in the same organization, but now I am a user of my old framework. As a result of this feeding my dog’s food, I began to hate Sam (author means himself - approx. Per. ) 2009-2010 for several reasons, but mostly for Spring. Spring is evil in good weather, but when it is included in the library or API that other programmers use, it is a different level of evil: as the fruit of Hitler and the devil's love. Do not let Spring stick out of your API.
Spring sucks for a number of reasons, and I felt that they should be listed, because there are no clear counterarguments on google.
- Configuration in XML. I would like to think that we, as a profession, have left XML in the past. He is incredibly verbose, but these are still flowers. More importantly, I do not want to program in XML. Linking all classes together is an extremely important part of your application. You are a Java developer, not an XML developer. One of the charm of Java as a language is compile time safety. I can compile my applications that do not have Spring, and be 100% sure that everything is assembled, connected and ready to go. But if there is Spring in the application, you start it, wait 30-60 seconds until it initializes the beans before it falls. In the modern world, this is crazy, especially if it is also multiplied by a bunch of integration tests in which you need to twist the container this way or that. A separate place in the hit list deserves "this means that I can change the implementation without recompilation!". So no one does. Never.
- Magic. Here usually follows a remark: “Now you can do everything with the help of annotations! No more XML! ” It's great when you don't need to program in XML, but annotations are still magic. Until you start the application, you have no idea whether it will contact correctly. And even then you do not know whether it is connected correctly; you just know that it is connected. I do not like magic.
- Importing other Spring files. At the moment, it pisses me off the most. I found that there is a tendency to split Spring files into smaller ones and scatter them into modules. I just killed 2 weeks pushing through the JARs and trying to find the right combination / order / version of the Spring files for something to work. Spring files in JARs are a bad, bad idea. Horrible. Every time you smear dependent Spring files into JARs, a child dies somewhere.
- Complexity. When you ask a candidate at an interview: "What are the pitfalls in Spring?" - most often you hear in response that he has a steep learning curve. Whether this is true or not is a separate topic, but I would like to emphasize the fact that Spring is now so complex that it has its own framework - Spring Boot . A framework for a framework. We are in “Framework Inception” - a film about Leonardo DiCaprio, who is trying to find his long-lost Java code, deeper and deeper plunging into layers of XML and annotations before finally committing suicide.
The thing is that I'm sure: it’s theoretically successful to use Spring in an applicationperhaps. I have never seen this before, and this is a problem. As for me, all the “goodies” that he offers are quite possible without him. When we ask about Spring for an interview, the candidate usually answers: “With Spring, you have clean code, separation of responsibilities, and it’s really good for testing.” In general, all those things that I am a big fan of (especially testing), but in reality these are the results not of using Spring, but of good programming. For beginners, Spring may be a good crutch for developing ideas such as dependency injection, mocking, and testing, but they are actually orthogonal to Spring. If you use a TDD, you have in the code will not be setters and getters - only dependency injection through constructors that you can, "the deputy of"for testing", and then, when you bundle your application together, simply use the often forgotten way to create objects - the keyword "new". Often we create the “ApplicationContext” class, which is responsible for linking everything together. It is clean, everything is testable, I have compile time safety, and my tests run damn fast.