As the title suggests, I'm back in Java.
The world you see is totally different. You only know when you get stronger. Did Java work like this? ?? Nice.
Thinking about infrastructure when adopting a new language for web application development
The mechanism means ↑.
The situation at the time of my fledgling
There were many things to remember, and I had no choice but to write controllers and services without deeply understanding them. (If you think about it now, if a veteran pulls you in pair programming, you can use the highway theory and the growth rate will be different.)
For the time being, I did my best to read technical books during the lunch break.
However, when I think about it now, I think the level was quite low. (Because it's a fledgling, I think it's natural ...)
At present, the description is generally known.
In that state, I will write the good points and bad points of Java that I saw again, including comparison with Node.js.
--Unlike Node.js, it's not asynchronous event driven, so it's easy to follow the code -Since there is a type, there is a sense of security that it will work relatively well as long as it compiles. ――Java is used and it is dead, so there is a sense of security. ――If you want to do it, you can write asynchronous processing ――If you google, various information will come out (the amount is too much and it is also noisy) --Since MongoDB is schemaless, it is very nice to be able to define the schema using types on the Java side.
--It takes time to compile ――I think there is a workaround, but it takes 2 minutes and 30 seconds at the moment of the project. --You can't develop without IntelliJ IDEA (Integrated Development Environment) (I want to do something about it ...) --In the case of Node.js, Vim and Visual Studio Code were free. --Test (JUnit) is harder to write than Node.js Mocha ――I want to explicitly write pre-processing and post-processing, but I have no choice but to write it in a mess in the test. --Difficult to implement due to Spring (situation where batch processing cannot be written properly) --If Spring just wants DI, there is also Google Juice -SparkJava I think it's simple -Is it because of the synchronous type? I don't know, but there is no performance at all ――In this regard, it is highly possible that the current project is not implemented properly. --Create a class even for objects with a short lifespan ――I think List and Map are good for VO class that is used only in 1 request path. --In Node.js, it seems that only List and Map are used, and it was still operational. ――If you can do test-driven development that prioritizes coding speed, I think you can go with List and Map. --Getter, Setter Don't you need it? --Maybe it's Maven, but the directory structure is awkward --Because of annotations, you may have a hard time not understanding how it works. -Does it work before the method? Does it work after the method? I don't know unless I see the implementation ――I don't think annotations are good because you can't understand the mechanism at a glance. -Lombok I think it's good
I think that what I wrote in a bad point can be changed at all depending on the implementation.
I feel that Java's traditional practices are just annoying.
Wouldn't it be interesting to try Node.js-like Java development? I think. (By the way, I think there was a person who was doing Node.js-like development using Play Framework when he was at CyberAgent.)
For me, in order to return early, I need to implement it quickly, so I want to create an environment where that can be done.
Recommended Posts