13 Keeping up to date with trends vs. cost of maintenance of your code

With software engineering, new libraries or concepts emerge regularly (indeed, almost every week). As soon as you adapt your application or architecture to a brand new shiny framework or pattern, another one is developed and popularized. We have microservices, reactive programming, serverless applications, and so on. Each of those patterns offers many benefits, such as loose coupling, better performance, or less resource consumption. However, each of those patterns and libraries comes with its own complexities.

For example, let’s assume that we decide to change our whole application processing from thread per request to the asynchronous reactive pattern. If our decision is mainly based on programming trends and popularity, we might have problems. It may turn out that the time investment, and the new model does not suit our application processing model.

13.1 When to use dependency injection frameworks

13.1.1 Do-it-yourself (DIY) dependency injection

13.1.2 Using a dependency injection framework

13.2 When to use reactive programming

13.2.1 Creating single-threaded, blocking processing

13.2.2 Using CompletableFuture

13.2.3 Implementing a reactive solution

13.3 When to use functional programming

13.3.1 Creating functional code in a nonfunctional language

13.3.2 Tail recursion optimization

13.3.3 Leveraging immutability

13.4 Using lazy vs. eager evaluation

Summary