DEV Community: Felix Coutinho

Mentorship is a Marathon

Felix Coutinho — Fri, 04 Oct 2024 17:49:44 +0000

TL;DR: Mentorship is a long-term journey, not a quick fix.

There’s a common misconception that getting a mentorship can provide instant career results. Having mentored software developers informally for over a decade and formally for the last two or three years, I’ve seen many of these people seeking guidance with unrealistic expectations and impossible timelines. More on timelines than expectations. Often, they hope for quick results after just a couple of sessions. But, this way of doing things really misses the point of what mentorship is all about.

Heads-up — I’m not a professional mentor. What follows is simply my conclusion about mentoring software developers, engineers, and architects, along with some insights from this process.

Spot the Difference: Mentorship vs. Consulting

Before going into effective mentorship, we need to understand the differences between mentoring and consulting:

Consulting is focused on solving specific problems, sometimes projects, or providing expert advice for immediate issues. It's usually short-term and handles specific issues.
Mentorship, on the other hand, is about making a long-term commitment to help someone grow and develop, and guiding their career over time.

Troubleshooting, debugging, and fixing a bug requires consultancy, not mentorship.

Effective Mentorship

Not about quick problem-solving

If you need a quick solution to an urgent problem, you’re looking for a consultant, not a mentor. Mentorship is about long-term growth, not quick fixes. It’s about developing skills, mindsets, and approaches that will serve you throughout your career.

For example, if you’re preparing for an interview and need help in advance, that’s more suited for a mock interview session. Sure, your mentor can help with interview prep, but that’s just one aspect of a broader mentoring process.

Similarly, troubleshooting or understanding a codebase requires consultancy (or maybe a freelancer), not mentorship.

Time is essential

The most successful mentorship relationships I’ve been part of have lasted 24-48 months. It’s rare to see meaningful results in under six months. This timeframe allows for real growth, the application of new skills, and the development of new habits.

Comprehensive Process

An effective mentorship process involves but is not limited to:

Regular 1:1 sessions
In-depth discussions
Practical exercises (coding, system design)
Mock presentations (design sessions, interviews)
Assessments
Ongoing feedback and adjustments

Commitment is Required

I typically recommend a 6-12 month initial period to my formal mentees. After this, we reassess their progress and decide together whether to continue for another 6-12 months.

It’s Personalized

Each person is unique. Each career is unique. Each mentorship should be tailored to an individual’s goals, strengths, and areas for improvement. What works for you may not work for someone else. I recognize this and you need to recognize this for the sake of your success.

Independent Learning

In technical fields, I often recommend books or resources for my mentees to study. This self-paced learning is crucial for deep understanding, allowing the mentee to exercise their brains on deeper topics instead of relying on shallow reads or quick videos.

As a side note, I’m a slow reader myself. It can take weeks or months to thoroughly go through a book—and that’s okay! Day by day, book by book, topic by topic, a mentee will get closer to their next level.

Proximity Can Enhance the Experience

In my experience mentoring developers within the workplace, I’ve seen tremendous success. With a paced schedule (biweekly, monthly, or bi-monthly), I can sometimes observe daily progress. This proximity allows frequent interactions and immediate feedback. I recommend people who want to become mentors start mentoring junior workmates first.

Remote Mentoring Has Its Challenges

Mentoring across different countries or continents presents its own challenges. Without structured exercises and regular check-ins, it’s harder to assess progress. This requires extra effort in planning and communication from both mentor and mentee. We can expect even longer mentoring periods here.

It Can Last a Lifetime

Some of my most pleasant and successful mentorship experiences have spanned a decade or more. I have mentees (now I call them friends) who started with me 10 years ago, and we’re still in regular contact through sessions and chats even though they live far from me. It’s incredibly fulfilling to witness their progress and achievements in professional and personal life over such a long period.

The Marathon

Remember, professional growth is a long-distance race, not a sprint. If you’re searching for mentorship, you need to be prepared to invest your time and effort not just in sessions, but in your learning between the 1:1 sessions.

Professional growth is a long-distance race, not a sprint.

The metaphor of a marathon fits mentorship well. Like a marathon runner, a mentee must be ready for the long journey. Progress may feel slow at times, but consistent effort over time leads to significant growth. The mentor cannot run for you but he/she can support you. The mentor, like a running coach, provides guidance and support, but the hard work of learning and growth is on you.

Just as a marathon runner doesn’t become a champion in two sessions of training, software developers don’t transform their careers in a couple of mentoring sessions. Again, it requires persistence, dedication, and guidance.

One More Metaphor

"No matter how great the talent or efforts, some things just take time. You can’t produce a baby in one month by getting nine women pregnant." - Warren Buffett

Although Buffett is the author of this phrase, it may have been inspired by a classic Software Project Management book called The Mythical Man Month (originally published in 1975, and still worth reading).

Here’s the original:

"The bearing of a child takes nine months, no matter how many women are assigned." (The Mythical Man Month, p. 17)

The point is, some tasks are, as the author would say, “sequentially constrained.” They require a certain amount of time, no matter how many people work on them. This is especially true for career development. You can accelerate it by finding a mentor and breaking inertia, but your career takes time to mature and see results.

Hey! If you liked this read and want to embark on the marathon of growing your career in software development, you can learn more about my mentorship approach and get started by visiting my MentorCruise profile or by sending me a connection request here on LinkedIn.

[PT-BR] Entendendo o Spring Framework na Prática

Felix Coutinho — Mon, 21 Aug 2023 15:39:20 +0000

No meetup realizado pelo JavaxCE em abril de 2023, tive a incrível oportunidade de compartilhar minha paixão pelo Spring, meu framework favorito, com todos os participantes.

Se você é um entusiasta de Java ou está ansioso para aprofundar seus conhecimentos sobre o Spring, não pode perder a gravação do evento, agora disponível no YouTube. Acompanhe todas as informações e insights valiosos que compartilhei durante minha palestra.

🎥 Assista à gravação do meetup:

Minha palestra se concentrou em fornecer tanto uma visão conceitual quanto prática para auxiliar os desenvolvedores a compreenderem integralmente o ecossistema do Spring Framework. Durante a sessão, mergulhamos nas complexidades das Rest APIs utilizando o Spring Web, exploramos as melhores práticas para acesso a dados com Spring Data e desvendamos os segredos de desenvolvimento ágil com Spring Boot. Ao longo da jornada, abordei os pilares fundamentais do Spring, como a Inversão de Controle, Injeção de Dependência, gerenciamento de preocupações transversais, adoção de convenções sobre configuração e muito mais.

📦 Confira o repositório de código que desenvolvemos ao vivo:

FelixCoutinho / meetup-javaxce-ecommerce-backend

Esse repositório contém a prova de conceito com alguns conceitos discutidos durante a apresentação de Abril de 2023 no JavaxCE.

meetup-javaxce-ecommerce-backend

Esse repositório contém a prova de conceito com alguns conceitos discutidos durante a apresentação de Abril de 2023 no JavaxCE.

Gravação no YouTube

https://www.youtube.com/watch?v=h5QDk2V4mrQ

Slides da aprensentação

https://speakerdeck.com/felixcoutinho/entendendo-o-spring-framework-na-pratica

View on GitHub

Para aqueles que desejam uma recapitulação visual, disponibilizei os slides da apresentação.

🖥️ Slides da apresentação:

Entendendo o Spring Framework na Prática - Speaker Deck

A palestra fornece um guia conceitual e prático para ajudar os desenvolvedores a entenderem o Spring Framework, cobrindo seus principais conceitos e componentes. Durante a sessão, serão explorados Rest APIs com Spring Web, acesso a dados com Spring Data e como desenvolver aplicativos rapidamente com Spring Boot, enquanto abordamos os fundamentos do Spring, tais como Inversão de Controle, Injeção de Dependência, Cross-cutting concerns, Convenção sobre Configuração e muito mais.

speakerdeck.com

Obrigado a todos que participaram e espero que essa experiência tenha contribuído para uma melhor compreensão e entusiasmo em relação ao Spring Framework. Fiquem à vontade para compartilhar seus comentários e sugestões aqui.

You should stop using Spring @Autowired

Felix Coutinho — Wed, 26 Apr 2023 17:18:14 +0000

Or "Why you shouldn't use Field Injection when using Spring".

*TL;DR *
Injecting beans directly into fields using @Autowired makes your dependencies "hidden" and encourages bad design. Use constructor-based injection instead.

It is very likely that you have already seen an @Autowired annotation when coding in a Java/Spring application. However, what most of my friends developers don't know is that auto-wiring is one of the most commonly seen anti-patterns in codebases that use the Spring IoC/DI Framework.

Just to refresh your memory here is a short example of what I'm talking about.



@Service
public class UserService {

    @Autowired // Field Injection
    private UserRepository userRepository;

    // ...
}

It may seem like a simple and pragmatic way to do Dependency Injection, right? But the consequences of this can turn your codebase slowly (or fast) into spaghetti.

But why do developers keep choosing this approach? Possibly because it's easy to use and provides an out-of-the-box experience when a developer needs to inject a dependency into a class. However, similar to any other bad practice, this is very easy to replicate across the rest of the codebase, and usually people will never argue why that code design choice was made. And what's the result of using @Autowired? Your code will suffer from coupling, a bad test experience, hidden dependencies, and others.

In my perspective, the absence of comprehension of the underlying mechanics of a system can potentially result in disastrous codebases. This is applicable to the usage of '@Autowired' when using Spring. Without a thorough grasp of crucial concepts such as Inversion of Control and Dependency Injection, developers are more likely to make errors and become ensnared in this pitfall.

To gain a better understanding of code design best practices, it's important for developers and architects to review key concepts and explore different approaches to Dependency Injection with Spring. By doing so, we can evaluate which method is optimal for our needs, and potentially uncover the drawbacks of using @Autowired as a dependency injection strategy.

Dependency Injection with Spring

Dependency Injection is a crucial pattern in software development and is present in production-ready frameworks like Spring. It promotes loose coupling between classes, improves testability, and facilitates modularity.

There are basically three ways to do Dependency Injection using the Spring Framework:

Field Injection uses reflection to set the values of private attributes/fields.
Setter Injection uses public setters to set the value of the attributes/fields.
Constructor Injection happens at the time of creating the object itself.

Field Injection

Field injection can be achieved using Spring by adding the @Autowired annotation to a class field. And what does @Autowired do? @Autowired is an annotation provided by Spring that allows the automatic wiring of the dependency. When applied to a field, method, or constructor, Spring will try to find a suitable dependency of the required type and inject it into the target class.

@Autowired alone is not the root of all evil. The key aspect is WHERE you are using @Autowired. Most of the time, developers use it at the field/attribute level. Using it at the setter method can reduce the damage, but not eliminate all of it at all.

But why @Autowired is so bad? Basically, @Autowired violates some good code design principles.

Dependency Inversion (D from SOLID)

If you want to use your class outside the application container, for example for unit testing, you are forced to use a Spring container to instantiate your class as there is no other possible way (but reflection) to set the @Autowired fields.

When using field-based dependency injection with @Autowired, the class is inherently hiding these dependencies from the outside world. In other words, no point of injection exists.

Below you can see an example of this scenario.



@Component
public class Calculator {

   @Autowired 
   private Multiplier multiplier;

   public int add(int a, int b) {
      return a + b;
   }

   public int multiply(int a, int b) {
      return multiplier.multiply(a, b);
   }
}

@Component
public class Multiplier {
   public int multiply(int a, int b) {
      return a * b;
   }
}

Despite the fact of in runtime Spring will inject the dependency (an instance of Multiplier) there is no way to inject the dependency manually, for instance when unit testing this class.

The below unit test class will compile, but at runtime it's a good candidate to throw a NullPointerException, why? Because the dependency between Calculator and Multiplier was not satisfied.



public class CalculatorTest {

   @Test
   public void testAdd() {
      Calculator calculator = new Calculator();
      int result = calculator.add(2, 3);
      assertEquals(5, result);
   }

   @Test
   public void testMultiply() {
      Calculator calculator = new Calculator();
      int result = calculator.multiply(2, 3);
      assertEquals(6, result);
   }
}

Clean Code / Screaming Architecture / Single Responsibility Principle (S from SOLID)

Code must scream its design. And the SRP principle states that a class should have only one reason to change. This means that a class should have only one responsibility or concern. @Autowired annotation, in itself, does not violate this principle.

However, if a class has multiple responsibilities and dependencies injected through the @Autowired annotation, it could be a clear sign of a violation of the SRP. In this case, it might be better to refactor the class and extract the responsibilities into separate classes.

Otherwise, if constructor-based dependency injection is used instead, as more dependencies are added to your class, the constructor grows bigger and bigger and the code starts to smell, sending clear signals that something is wrong. This is described in the Clean Code / Screaming Architecture pattern in the book written by Robert C. Martin aka Uncle Bob.

Complexity

@Autowired can make the code more complex, especially when dealing with circular dependencies. When two or more classes depend on each other, it becomes hard to determine the order in which they should be instantiated. This can lead to runtime errors that are hard to debug.

Most likely your project doesn't need @Autowired at all

What should you use instead?

The short answer is Constructor Injection.

In OOP we create an object by calling its constructor. If the constructor expects all required dependencies as parameters, then we can be 100% sure that the class will never be instantiated without having its dependencies injected.

Below an example using Constructor-based Dependency Injection instead of @Autowired.



@Component
public class Calculator {

   private Multiplier multiplier;

   // Default constructor. It will be used by Spring to 
   // inject the dependencies declared here.
   public Calculator(Multiplier multiplier) {
      this.multiplier = multiplier;
   }

   public int add(int a, int b) {
      return a + b;
   }

   public int multiply(int a, int b) {
      return multiplier.multiply(a, b);
   }
}

@Component
public class Multiplier {
   public int multiply(int a, int b) {
      return a * b;
   }
}

public class CalculatorTest {

   @Test
   public void testAdd() {
      Calculator calculator = new Calculator(mock(Multiplier.class));
      int result = calculator.add(2, 3);
      assertEquals(5, result);
   }

   @Test
   public void testMultiply() {
      Multiplier mockMultiplier = mock(Multiplier.class);
      when(mockMultiplier.multiply(2, 3)).thenReturn(6);
      Calculator calculator = new Calculator(mockMultiplier);
      int result = calculator.multiply(2, 3);
      assertEquals(6, result);
   }
}

Now the dependency between the two components was explicitly declared and the code design allows a mock instance of Multiplier to be injected at runtime.

Also, Constructor injection helps in creating immutable objects simply because a constructor is the only possible way to create objects. Once we create a bean, we cannot alter its dependencies anymore. On the other hand, by using setter injection, it’s possible to inject the dependency after creation or change the dependency, thus leading to mutable objects which, among other things, may not be thread-safe in a multi-threaded environment and are harder to debug due to their mutability.

By explicitly defining the dependencies of the class on the constructor, you can make the code more maintainable, testable, and flexible.

Maintainable because you rely only on OOP concepts to inject your class dependencies and any change to the class dependencies contract will be communicated to the other class with no effort.
Testable because you have a point of injection that will allow the unit tests to pass, for instance, a mock object instead of a concrete implementation. Besides, we make this class immutable by allowing only injections at the constructing time.
Flexible because you still able to add more dependencies to the class with minimum effort by adding more parameters to the default constructor.

This approach makes it easier to understand and track the dependencies of your classes. Additionally, it makes it easier to test the class in isolation by forcing your to explicitly providing mock objects for the required dependencies at coding time.

Setter Injection

One more method to do Dependency Injection using Spring is by using setter methods to inject a instance of the dependency.

Below you can see an example of how Setter Injection looks like when using Spring.



public class UserService {
    private UserRepository userRepository;        

    ...

    @Autowired // Setter Injection
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    ...
}

This approach can lead to problems such as:

Optional dependencies. Setter Injection allows for optional dependencies, which can lead to null pointer exceptions if the dependencies are not properly checked for null values.
Incomplete object state. If an object is partially constructed and a setter is called, it can result in the object being in an incomplete state, which can lead to unexpected behavior or null pointer exceptions again.
Hidden dependencies. As the dependency is not explicitly declared in the constructor, making it harder to understand the code and its dependencies.

Despite the drawbacks, Setter Injection sits somewhere between the Field and the Constructor Injection because at least we have a public method that allows developers to inject mocks instead of real implementation making the class easier to test.

Further Considerations

The @Autowired annotation can be omitted from codebases using Spring Framework 4.3 or higher and Spring will use the default constructor and inject all necessary dependencies for you when the class is being managed by the Application Context.. (https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-constructor-vs-setter-injection)

So, since the Spring team decided @Autowired should be optional to the default constructor. We can conclude since it's not helping the Spring framework to make a decision, its presence is just noise. Get rid of it!

The below comment from the Spring Framework development team gives one more reason to choose Constructor Injection as your default injection method.

"Furthermore, constructor-injected components are always returned to the client (calling) code in a fully initialized state." and "Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class."

Basically, what they are saying is by using constructor injection you can guarantee the ready-to-use state of the class. If you are using @Autowired or even setter injection your class instance can be instantiated by Spring in a bad state which can cause unexpected behaviour, such as NullPointerException.

Why @Autowired even exist?

If you need to inject optional or changeable dependencies, you may want to use @Autowired to mark the setter method (or a non-default constructor) as the point of injection. But it only makes sense if your dependency is optional or changeable and your implementation can handle the absence of that dependency (nulls).

If several constructors are available and there is no primary/default constructor, at least one of the constructors must be annotated with @Autowired to instruct Spring which one to use. This is a scenario where @Autowired can be considered.

Conclusion

At the end of the day, @Autowired can be useful for small, simple projects, but it is not a good choice for large, complex, and production-ready projects where the code design should be open for extension, flexible, and easy to test. Instead, the recommendation is to use explicit Dependency Injection via class constructor. By doing so, you can ensure that your code remains robust and adaptable.

Something that you and your team will gain for free is that the rest of the project will implicitly reflect this code design decision. Sometimes, developers never learn about proper Dependency Injection, class contracts, or even how to test code effectively simply because they use @Autowired and never question its real necessity and applicability.

Additional reading and references

https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-constructor-vs-setter-injection
https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-autowired-annotation
https://betulsahinn.medium.com/why-is-autowired-annotation-not-recommended-4939c46da1f8
https://blog.marcnuri.com/field-injection-is-not-recommended
https://reflectoring.io/constructor-injection/
https://kinbiko.com/posts/2018-02-13-spring-dependency-injection-patterns/
https://blog.frankel.ch/my-case-against-autowiring/
https://www.linkedin.com/pulse/when-autowire-spring-boot-omar-ismail/?trk=articles_directory
https://eng.zemosolabs.com/when-not-to-autowire-in-spring-spring-boot-93e6a01cb793
https://stackoverflow.com/questions/41092751/spring-injects-dependencies-in-constructor-without-autowired-annotation

Creating Effective Code using Java Records

Felix Coutinho — Fri, 13 Jan 2023 17:45:34 +0000

Java Records is a new feature introduced in Java 14 to make it easier for developers to create immutable classes. A record is a special type of class (and a new keyword too) that acts as a data container or a data object, and it's used to hold a fixed set of values.

Let's check a short Java Records example.

record Point(int x, int y) {}

This creates a new record class called Point, with two fields x and y. These fields are automatically marked as final, so they cannot be modified once the record is created.

Under the hood a few methods are going to be generated to help you, such as:

A constructor that initializes all the fields
Accessor methods (getters and setters) for each field
And toString, hashCode, and equals methods

This means that you don't have to write boilerplate code for these common tasks, making it much easier to create and maintain your code. And also by using Java Records you can eliminate a lot of use cases for the loved and hated Lombok library.

Why use Records?

The short answer is Records are more expressive, readable and faster than traditional DTO classes.

Using the example we already presented above, of a point in 2D space, you can easily use a record to clearly express that the class only has two fields and nothing else. Showing how readable and expressive record classes are.

DTOs vs Record

This is a inevitable comparison even though DTOs are not the only use case for Java Records. Both are used to hold a fixed set of values, but they have some key differences. When we compare Records with a DTO stylish class we can see a big difference in expressiveness and readability.

We can replace about 40 lines of code with 1 line only. Check the Point class written using the DTO pattern.

class PointDTO {

    private int x;

    private int y;

    public PointDTO(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return x;
    }

    public int getY() {
        return y;
    }

    @Override
    public String toString() {
        return "PointDTO{" +
                "x=" + x +
                ", y=" + y +
                '}';
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        PointDTO pointDTO = (PointDTO) o;
        return x == pointDTO.x &&
                y == pointDTO.y;
    }

    @Override
    public int hashCode() {
        return Objects.hash(x, y);
    }
}

As you can see, compared to the Record class, the DTO class contains a lot more code (boilerplate code), including the constructor, getter methods, and the methods toString, hashCode, and equals which are common to most DTOs.

Unlike DTOs, records are immutable by nature, meaning their fields cannot be modified once the record is created. This makes records more suitable for functional programming and improves code safety.
Records have built-in support for common methods like toString, hashCode, and equals, which eliminates the need for boilerplate code.
Records are a more modern and expressive way of creating data classes compared to DTOs, which could make it easier for new developers to read and understand the codebase.

And we can point out more reasons to use Records.

JVM loves Records (and vice versa)

Java Records are more efficient than traditional classes in terms of memory usage and performance because of their immutable nature, the way they are implemented in the JVM, and the techniques like compacting and inlining that the JVM can apply to classes markes as records.

Records eliminate the need for defensive copying (check Guideline 6-2), which can improve performance by reducing the number of operations that need to be performed on the data.

Because Records don't have any additional methods or fields, the JVM can use more aggressive optimization techniques for records, like inlining (check Phase 1), that can further improve performance. But, it doesn't mean more methods can be added, you still can adding more methods as you need.

Disadvantages of using Records

As with everything in life (technology especially), there are also some drawbacks when using records.

Java Records are not suitable for use as JPA (Java Persistence API) entity classes because they have some limitations that make them incompatible with the requirements of JPA entities.

JPA entities are required to have a no-arg constructor, which is not provided by default for records. This means that you would have to manually add a no-arg constructor to the record class, which would defeat the purpose of using a record in the first place.
JPA entities are required to have setter methods for each field so that the entity manager can update the fields in the database. However, records do not have setter methods by default, as their fields are automatically marked as final.
JPA entities can have additional methods and fields that are not part of the record.
JPA entities can be extended or implemented interfaces or classes, while records cannot.

As you can see while records provide a concise and efficient way to create immutable classes, they are not suitable for use as JPA entities due to the limitations on constructors, setter methods, additional methods, fields and interfaces or classes that JPA entities require.

To wrap up

When I first saw Records my thought was to replace all of my DTOs and JPA Entities with Records right away but I was partially wrong. Clearly, DTOs and data classes are good candidates to be replaced by Records but not our lovely and long JPA Entities because of the limitation we discussed here.

One more time writing and diving into concepts I like such as Records made me more confident to make choices about whether recommend or not Records for my Java projects or even better to refactor or not to use Records. And due to the simple use and low cost of Records it can be used in different parts of a Java codebase and not blocking you to use other type of classes such as Entities in different parts of the code base.

What about you? Are you using Records in your projects? How is the experience so far?

Lombok: The Good, The Bad, and The Controversial

Felix Coutinho — Tue, 01 Feb 2022 22:32:26 +0000

Java developers, particularly those coming from other programming languages, have long complained about the overwhelming amount of boilerplate code found in Java codebases. In Object-Oriented Java development, the necessity of ensuring encapsulation and immutability of objects only adds to the amount of boilerplate code required. This issue is a common pain point for developers and can be exemplified by tens or even hundreds of lines of getter and setter methods per source file, as well as extensive class constructors. In response to this problem, Project Lombok was created.

Lombok

Project Lombok is a java library that automatically plugs into your editor and building tools, spicing up your java. Never write another getter or equals method again, with one annotation your class has a fully featured builder, automates your logging variables, and much more. (from https://projectlombok.org/)

Basically, Lombok uses meta-programming to generate code at compile time. In addition to the possibility of generating getters/setters methods, it can generate equals methods, hash code and a variety of class constructors. Besides the possibility of generating class-level attributes, for instance, a logger attribute using LOG4J. It may seem mysterious, but in fact, Lombok uses two native Java features to generate this code. Let's explore these features below.

How does Lombok work?

Annotations

Annotations were introduced in Java a long time ago, in version 6. And Lombok has a series of annotations that can be used to identify/mark the need to generate new code within that class.

AST (Abstract Syntax Tree)

Abstract Syntax Tree is the way the compiler represents the steps that need to be performed for the final program to be generated. AST Java is a kind of intermediate structure that is created before the byte code is generated. Java has its own AST and it can be manipulated.

Image source [https://sewiki.iai.uni-bonn.de/_media/research/jtransformer/lmp.jpg]

So, if we join these two technologies/features everything starts to make sense. During the compilation phase, Lombok annotations are identified and Lombok manipulates AST to insert code that did not exist before into existing classes.

However, Lombok doesn't do this in a snap. It needs to intercept calls to the Java compiler in order to handle the intermediate code that will be generated. This is done through plugins, either in your IDE (IntelliJ, VSCode, Eclipse) or via building tools (Maven/Gradle/Make). If your IDE or your dependency/build manager does not support Lombok your code will not compile.

Considerations

Compilation time

Due to Lombok performing its magic at compilation time, you can expect an increase in the compilation time of your Java project/codebase. And this increase can have a high impact, especially on large codebases, the more code to generate the more AST to handle. The Lombok development team has been working to lessen this impact and has succeeded, but the time is still longer with Lombok than without it.

Java Standards

Let's say you're trying to compile your source code using only javac (the java compiler) and the source code uses a get method generated by Lombok in this case you will get a compilation error saying that the get method doesn't exist.

It happens because a source code that uses Lombok annotations is not a valid Java source code. (Controversial but sincere)

Is this a problem? The answer is yes and no. Yes, because you will always depend on Lombok plugins for your source code compilation to work. No, because in most cases developers use IDEs or building tools to compile their Java code.

Compatibility

Another point of attention is the compatibility with future and previous versions of Java. With each version, Java may change the way AST is generated and interpreted. In version 8 it can be one way and in version 9 another way. So Project Lombok needs to update its dependency library to generate the code in the most up-to-date way, and of course, maintain backward compatibility as well.

If you are using Lombok, it is possible that your project will fail to compile if you upgrade your Java release.

It's a problem? Yes and no. Yes, because you will only notice that your code stopped compiling after you perform the Java upgrade. No, because Project Lombok usually releases library updates before the final versions of Java. But remember, if you use Lombok be aware of possible future compilation failures for the reason I've described above.

Boilerplate code

This is where Lombok gains popularity, in the emotional and most visible part of the source code. No doubt Lombok drastically reduces the amount of boilerplate code in your Java classes, especially in domain classes (TOs, DTOs, Entities) where usually we have a lot of class-level attributes.

If we count 3 lines of code for each get method and 3 more lines of code for each set method we will end up having a reason of 6 lines less for each class attribute if you are using Lombok to generate get and set for all of the class attributes. In a class with 10 attributes, you will save 60 lines of code minus the lines containing Lombok annotations. Besides equals, hash code, toString and other methods.

That is good? Yes and no. Yes, because your source code file will be smaller, simpler, and for instance, if you add a new attribute the boilerplate code related to that attribute will be generated automatically. No, because all IDEs, from the simplest to the most complete, can generate this boilerplate code with one or two clicks.

Concluding

Lombok has its advantages, but it also has its drawbacks. A major issue in my opinion is that it can make your code less readable, especially for developers who are not familiar with Lombok's annotations. This is because the annotations can hide what the code is doing, and may make it more difficult for other developers to understand what is happening behind the scenes.

Another potential drawback is that Lombok is not supported by all IDEs out of the box, which can make it more difficult to set up and use. And Lombok doesn't always play nicely with other libraries or frameworks, which can cause compatibility issues and make debugging tricky and longer.

Despite these, Lombok can be a powerful tool for simplifying your code and reducing boilerplate. It's up to you to weigh the pros and cons and decide whether or not it's worth using this library in your project. Ultimately, whether or not to use Lombok comes down to a matter of personal preference and what works best for your team and your project.

Personally

In my personal experience, I tend to avoid using Lombok in my projects. When discussing this topic with my team, I share the points mentioned in this post, and we make a decision based on the project requirements and context. In some Java teams, we've used Lombok, and in others, we haven't, without any negative impact on the project. One noteworthy project I worked on in recent years did not use Lombok, yet it was still very successful. The decision to use Lombok or not depends on a variety of factors and should be evaluated on a case-by-case basis.

The clear advantage is having less code to maintain. However, this type of code (boilerplate) is not considered critical and can be easily generated by your favourite IDE. And the drawback is adding more complexity to your codebase, especially on the project building time and compatibility with future Java versions.

Some of the use cases for using Lombok can be tackled by using Java Records, check my other article.

Lombok will not determine the success or failure of your project. But if you need to decrease the size of your Java classes Lombok can be helpful. But don't forget to take into account the points that were listed here.

Designing cloud-native microservices [Deck/References/Links]

Felix Coutinho — Tue, 01 Feb 2022 22:15:23 +0000

Hello fellow developers and architects! As we venture into the world of cloud-native microservices, I have compiled a collection of valuable resources that formed the basis of my "Designing Cloud-Native Microservices Using Patterns" presentation. Whether you are a seasoned developer or an aspiring architect, these references provide an excellent starting point for developing a microservices mindset and creating your microservices with skill.

There are a lot of resources available for designing microservices, including cloud-native microservices. These resources can help you overcome challenges and provide a comprehensive perspective. If you're interested, you can check out my presentation deck for future reference when starting your projects.

🎨 Presentation Deck:

Designing cloud-native microservices using patterns - Speaker Deck

Designing cloud-native microservices using patterns Felix Coutinho Cloud-native applications are a collection of small, independent, and loosely coupled services. How can you as a developer or an architect design microservices that comply with this definition? And more, how can you do this using industry-level design patterns such as fanout, mat-view, observability, CQRS? The intent of this talk is to give real-world examples and feed the participants with confidence that cloud-native microservices are possible to implement since you design them properly.

speakerdeck.com

Now, if you're ready to dive deeper, I encourage you to engage with the video recording of the presentation. Please note that the recording is in Portuguese, my apologies for any inconvenience. But if you need it in English, check the TDC Online section below.

📹 Video Recording (Portuguese only):

If you're eager to explore further and expand your knowledge, I also had the honor of delivering this presentation at the TDC Connection conference. To gain access to this content, a subscription is required. Here's a glimpse:

TDC Online

For more details on the TDC Connection conference and how to access the content, visit: TDC Online.

This resource compilation includes books and links to help you better understand and use cloud-native microservices. It's a valuable tool for enhancing your knowledge and implementation of this technology.

If you want to recommend books, please add a comment to this article.

📚 Books

🔗 Links

You can use these resources to begin your journey to becoming a cloud-native microservices developer or architect. Use them as inspiration to develop your skills in creating and executing solutions that utilize cloud-native patterns. And again, feel free to explore further, educate yourself, and share your findings with us in the comments.

The Highly Standardized Code Syndrome

Felix Coutinho — Tue, 01 Feb 2022 22:10:33 +0000

Dear reader, this article is about a theory under construction and it's been improved and nurtured over time by me. Your feedback is more than appreciated.

A little bit of history

There was a time when programming standards and good practices were created in silos. Big companies like IBM, Microsoft, Oracle, Sun and even NASA had their best practice manuals and some were kept as secret as they did with industrial secrets. As the practice of developing software became more common, not-so-large companies started to create their own software and the desire for standardization became increasingly evident, as is the goal of all industrial practices.

Over the years, the Software Engineering literature has established a series of standards and good practices that have taken software development to an industrial level. Design patterns, paradigms, principles, concepts and techniques were established over time so that the source code produced would have a more industrial and less personal character. Furthermore, introducing these best practices allows the source code to be better understood, better maintainable and at a lower cost for everyone, programmers and companies.

This level of maturity has allowed software development to become a reproducible discipline anywhere in the world, true engineering.

However, many of these standards have been thought, grounded, tested and established in silos. Real problems in real teams and companies that do not necessarily reproduce the scenario that a developer lives. In addition, these concepts are often mutually exclusive, when applying one of them you cannot apply the other.

As well as the lack of standards is a problem for the delivered source code, and the use of too many of these standards can be a problem as well. This is the fundamental ground where can establish the Highly Standardized Code Syndrome.

The Highly Standardized Code Syndrome occurs when a software engineer believes he needs to use as many design patterns, principles, concepts and techniques as possible from the existing literature or from the industry. Consequently, his code takes a long time to be produced and delivered and he strongly believes that this will guarantee the final quality of the code produced - Felix Coutinho 2021

In some ways the Highly Standardized Code Syndrome is comparable or I can say has its foundations in the historical article from Donald E. Knuth as you can see below.

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." (The emphasis is mine)

Of course, the Highly Standardized Code Syndrome is about standards and not about optimization but they are quite related due to the nature of the intention of their use which is the outcome of the work. In both cases, it can fail a project or at least delay of the delivery.

Detecting the syndrome

The picture below can give you a clear sense of when the Highly Standardized Code Syndrome arises. The ascendance and the peak of the curve represent the first symptoms of the syndrome

Image by Flavio Copes via Twitter

Feedback first, optimization last

A good exercise for software developers, architects and engineers is finding the right balance when applying existing industry standards.

The simplest formula we can establish is problem, scenario and solution.

In other words, you should wait until you have a real problem sourced by feedback and then you can find a solution within your scenario. Otherwise, the result will be an excess of solutions to problems that you don't have at all which will very possibly result in the Highly Standardized Code Syndrome. The developer will have spent a lot of time on problems that he doesn't have.

And in general, finding the right balance between standardization and flexibility is important for a successful software development project.

[Changelog]
6th version on Feb 9th, 2023
5th version on Feb 8th, 2022
4th version on Feb 1st, 2022
3rd version on Aug 21th, 2021
2nd version on Jul 21st, 2021
1st version on May 13th, 2021