Know more and connect with me on [Linkedin Profile].

Saturday, November 17, 2018

JHipster Pros and Cons

Jhipster is a web application scaffold that generates backend and frontend code for CRUD applications. You describe entities in JDL format among other options and Jhipster generates backend server and frontend UI for you.

Here are some of the advantages:

  • Fast application code scaffold. In a short time, an application is generated. 
  • Many options exist on the frontend side such as React, and Angular. Vue.js is under development.
  • Also, many options exist on the backend side, such as monolithic or service-oriented architecture. 
  • Backend code is generated in Java code only. There is an in-progress work for Kotlin.
  • It generates automated tests of all kinds, unit, integration, performance and even e2e tests.
  • The code is well organized and uses best practices. You can learn a lot from it.
On the negative side:
  • Jhipster generates tons of code with many libraries that you probably do not know some of them. You can not go ahead and add your business logic and modifications without reading tutorials about these technologies.
  • Somewhat overuse of component, libraries, and frameworks that make your initial greenfield project complex from day one. It is like start big, rather than start small, but that was your choice from the beginning!
Alternatives:
  • JHipster is based on Yeomen. There are so many other scaffold generators, look at http://yeoman.io/generators/
  • You can create your own Yemon generator to generate the code that is just right for you.

Refactoring and Git Developer Story

I refactored a critical long class that has very long member functions. My main intention was to:

  • Extract many smaller member functions to enhance class modifiability.
  • By breaking the long member functions into smaller ones, it will be much easier to understand what the class is really doing.
  • By having many smaller member functions, we have the chance to discover if the class is not cohesive. We may then consider extracting a new class. This will be a good news as the class is already too long.
  • Enhance the memory footprint for the main class API. 

I did many commits, each with a logical and small refactoring step. When the code is sent for code review, the reviewer complained of time wasted reviewing all these commits. He asked, for next time, can you make it one big commit?

No, we can not, and here is why it is better to have fine-grained commits.

If you are doing a real code review that you have to understand each change to ensure it meets quality checks, ensure there is no bug injected and evaluate side effects and to propose QA test cases to cover them, then one small logical commit is much easier and accurate to review. It will take time, but it is worth the time.

For the developer himself, I find it very crucial to commit changes bit by bit, ensuring logical and small change is committed and a good comment is written. It is like a self-review and organized way even before code review.

If still, the reviewer needs to see all changes in one shot, he can easily check out the old class and the final edited class and used any diff tool to see all differences at once.

Happy coding!