DEV Community: Alberto Talone

The Devil’s Clean Code: Lessons from Migrating a 20-Year-Old Legacy Project

Alberto Talone — Mon, 19 Jan 2026 17:41:31 +0000

TL;DR

Write tests. You don't truly realize how messy code is until you try to write a unit test for it.
Understand your annotations. Don’t use @Data when @Getter and @Setter are all you need.
Don't fear the refactor. If you have the chance to rewrite and simplify, take it.

The Ghost of Architecture Past

In 2025, I took on a daunting challenge: migrating a 20-year-old JSP project into a modern microservice architecture.

To understand the business logic, I had to dive deep into ancient JSP files, trying to decipher what a developer two decades ago was trying to achieve. The client’s initial request sounded simple but proved to be a nightmare: "Copy the models into the new project and transform the beans into services."

The reality was a mess. I found hundreds of model classes scattered across dozens of domain packages. Every package contained at least one "utility" class bloated with static methods for manipulating DAOs and DTOs. The inheritance trees were like Matryoshka dolls—classes extending classes, extending other classes, until the original purpose was lost.

Under pressure to move fast, we made a classic mistake: we copy-pasted the old structures into the new service. We thought converting stateful variables into stateless method parameters would be enough. We were wrong.

Confronting the "Bugfest"

Once the code lived in its new "modern" home, we ran it through SonarQube. It was a disaster.

The report was a "bugfest" of epic proportions: SQL injection vulnerabilities, non-standard naming conventions, and massive blocks of duplicated code. My daily routine became a cycle of frustration: cursing the original developers, questioning my career choices, and ultimately, rolling up my sleeves to clean the mess.

By the end of the cleanup phase, I had:

Deleted nearly 2,000 unused classes.
Eliminated 30% of duplicated code.
Fixed hundreds of bugs and suppressed legacy warnings.

The "microservice" was finally starting to look like one, sitting at 900 classes and 55,000 lines of code. It was time for the final boss: 80% test coverage.

Writing Tests for the "Devil's Clean Code"

Writing tests for legacy code you didn't author is a unique kind of challenge. I leaned heavily on AI assistants to generate test scaffolding, which significantly sped up the process. However, as I looked at the logic I was testing, I realized I was reading the "Devil’s version" of Clean Code.

I encountered:

Indentation Hell: Methods with 8 to 10 levels of nested if and for loops.
Condition Fatigue: if statements with 10~15 different logic gates.
Dead Wood: Massive amounts of unreachable code and unused variables.

Testing forced me to confront these issues. If a branch is impossible to reach in a test, it shouldn't exist in the code.

What I Learned (The Hard Way)

1. Tests are a Diagnostic Tool

Tests are the best way to understand someone else's code. They reveal exactly where the "spaghetti" is. If a method is too hard to test, it’s a signal that the code needs to be rewritten, not just patched.

// BEFORE: The "Pyramid of Doom" (Deeply nested logic)
public void processLegacyRuo(RuoDir ruoDir) {
    if (ruoDir != null) {
        if ("ACTIVE".equals(ruoDir.getTPRuo())) {
            if (ruoDir.getRuoArr() != null) {
                for (RuoItem item : ruoDir.getRuoArr()) {
                    if (item.getGG() > 0) {
                        // Business logic buried 5 levels deep
                        performOperation(item);
                    }
                }
            }
        }
    }
}

// AFTER: Flattened logic using Guard Clauses and Streams
public void processRuo(RuoDir ruoDir) {
    // 1. Exit early if the object is invalid or not in the right state
    if (ruoDir == null || !"ACTIVE".equals(ruoDir.getTPRuo())) {
        return;
    }

    // 2. Handle null collections gracefully
    if (ruoDir.getRuoArr() == null) {
        return;
    }

    // 3. Use Functional Programming to handle the collection
    ruoDir.getRuoArr().stream()
          .filter(item -> item.getGG() > 0)
          .forEach(this::performOperation);
}

2. The Lombok Trap

One of my biggest "Aha!" moments involved Lombok. We initially used @Data on all our models to save time. However, we realized our branch coverage was suffering.

Why? Because @Data automatically generates @EqualsAndHashCode and @ToString. These methods create many hidden logical branches that need to be tested to reach high coverage percentages. By switching to specific @Getter and @Setter annotations, we removed unnecessary complexity and made our coverage targets achievable.

// BEFORE: @Data generates equals, hashCode, and toString, adding hidden branches
@Data
public class UserDto {
    private Long id;
    private String name;
    private String email;
}

// AFTER: Explicit annotations only for what we actually use
@Getter
@Setter
@NoArgsConstructor
public class UserDto {
    private Long id;
    private String name;
    private String email;
}

3. Don't Fear the Rewrite

Legacy code can be intimidating, but you shouldn't be afraid to change it. If you understand the intent of the code, rewrite it for clarity. Your future self (and your team) will thank you.

// BEFORE: A maintenance nightmare with 20+ conditions
if ((input.getDtVersAA() == null || input.getDtVersAA().trim().isEmpty()) && 
    (input.getDtVersMM() == null || input.getDtVersMM().trim().isEmpty()) &&
    // ... imagine 15 more lines of this ...
    (input.getCodFisc() == null || input.getCodFisc().trim().isEmpty())) {

    // Do something if everything is empty
}

// AFTER: Using Method References and Streams for clarity
List<Supplier<String>> fieldsToCheck = Arrays.asList(
        input::getDtVersAA,    input::getDtVersMM, 
        // ... add all 15 more lines ...
        input::getCodFisc
);

// We use a helper method (checkCampoVuoto) and allMatch to verify the state
boolean allFieldsEmpty = fieldsToCheck.stream()
        .allMatch(fieldGetter -> checkCampoVuoto(fieldGetter.get()));

if (allFieldsEmpty) {
    // Logic is now readable and easy to extend
}

Final Thoughts

Migrating legacy systems isn't just about moving code from one place to another; it's about translating old ideas into modern standards. It’s a messy, frustrating, but ultimately rewarding process.

What’s the worst legacy code you’ve ever had to migrate? Let’s swap horror stories in the comments!

Microfrontend Architecture: Breaking Down Monolith Frontends

Alberto Talone — Tue, 11 Feb 2025 22:57:33 +0000

A microfrontend is an architectural style for frontend development where a web application is divided into smaller, independent modules or features. Each module can be developed, deployed, and maintained autonomously, much like the concept of microservices in backend architecture.

In a traditional monolithic frontend, all parts of the application (like the navigation bar, product listing, checkout page, etc.) are together. This makes the system tightly coupled, which can lead to challenges as the application grows.
Using microfrontends, you can treat each part of the application as a standalone piece, that can be managed independently.

Keep in mind that this architecture is not a silver bullet...so let's dive into a simple analysis.

Key Principles of Microfrontends

1. Independence

Each microfrontend is a self-contained unit that operates independently from the others. This means:

Teams can develop and deploy their microfrontend without waiting for changes in other parts of the application.
Each microfrontend has its own build, deployment, and runtime process.
If one microfrontend fails, the rest of the application remains unaffected, improving resilience.

For example, in an e-commerce application, the checkout module can be deployed separately from the product listing page without disrupting the overall user experience.

2. Technology Agnosticism

Microfrontends allow different parts of the application to be built using different technologies. This flexibility provides several advantages:

Teams can select the best tool for their specific needs, such as React for product catalogs, Vue for shopping carts, or Angular for checkout pages.
Organizations can gradually migrate from older technologies (e.g., from AngularJS to React) without a complete rewrite.
It enables incremental upgrades, allowing different teams to evolve their stacks independently.

However, technology diversity should be managed carefully to avoid excessive complexity in the integration process.

3. Isolated Codebases

Each microfrontend has its own repository, build process, and deployment pipeline. This separation leads to:

Lower interdependencies: A change in one module does not require modifying others.
Faster development cycles: Teams can work in parallel without conflicts.
Easier debugging and maintenance: Since each module has its own lifecycle, it is easier to identify and fix issues in isolation.

For example, if the user profile module has a bug, developers can debug and patch it without affecting the navigation bar or search module.

4. Team Ownership

In a microfrontend architecture, different teams own and manage specific microfrontends. This decentralized approach offers:

Autonomous development: Teams can work independently with full control over their features.
Domain-driven design (DDD): Each team focuses on a business domain (e.g., payments, search, or authentication).
Improved collaboration: Since teams have clear ownership, they can align better with business goals and user needs.

For example, a dedicated team for checkout ensures that the payment process is always optimized for performance and security without affecting the rest of the application.

5. Seamless Integration

Even though microfrontends are built independently, they must integrate smoothly to create a unified user experience. This requires:

Consistent design: UI components and styles should match across different microfrontends (e.g., using a shared design system).
State management strategies: Communication between microfrontends should be handled carefully to ensure data consistency (e.g., using events, APIs, or shared state managers).
Routing and navigation: Users should not notice any difference when transitioning between microfrontends.

For example, when switching from the homepage to the cart module, the user experience should feel seamless, as if it's a single-page application rather than multiple independent apps.

Benefits of Microfrontends

Microfrontend architecture offers several advantages over traditional monolithic frontend applications. By breaking down a large frontend into smaller, independently managed pieces, organizations can improve scalability, flexibility, and overall development efficiency. Below are some of the key benefits:

1. Scalability

Microfrontends enable teams to scale both their development processes and infrastructure efficiently.

Independent Team Development: Different teams can work on separate microfrontends without interfering with each other. This allows for parallel development and faster feature releases.
Load Distribution: Since each microfrontend can be deployed separately, resources can be allocated dynamically based on demand, optimizing performance.
Modular Growth: As the application expands, new microfrontends can be added without significantly impacting existing functionality.

For example, in an e-commerce application, the search functionality can scale independently from the checkout system, ensuring a smooth user experience even during high traffic periods.

2. Faster Deployments

With microfrontends, teams can deploy updates and new features more frequently without affecting the entire application.

Smaller Codebases: Each microfrontend has a smaller, more manageable codebase, reducing build times and deployment complexity.
Independent Deployment Pipelines: Teams can deploy changes to their specific microfrontend without waiting for other teams to finish their work.
Reduced Downtime: Since deployments are smaller and isolated, the risk of breaking the entire application is significantly reduced.

For example, a company can push an update to the product recommendation section without requiring a full application redeployment, allowing for rapid experimentation and A/B testing.

3. Flexibility in Technology Choices

Microfrontends allow teams to choose the best technology for their specific use case, rather than being locked into a single framework.

Technology-Agnostic Approach: Each microfrontend can be built using different frameworks or libraries (e.g., React for one module, Vue for another).
Incremental Migrations: Organizations can migrate legacy applications gradually by introducing new microfrontends while still maintaining the old ones.
Freedom for Innovation: Different teams can experiment with new technologies without disrupting the rest of the system.

For example, a company using Angular for its existing frontend can introduce a new dashboard built with React without needing to rewrite the entire application.

4. Resilience and Fault Isolation

One of the major advantages of microfrontends is that failures in one module do not necessarily impact the entire application.

Improved Fault Tolerance: If one microfrontend crashes or experiences a bug, the rest of the application remains functional.
Service Decomposition: Each microfrontend can operate independently, reducing the risk of widespread failures.
Graceful Degradation: If a microfrontend fails, fallback mechanisms (e.g., loading a static version) can be used to maintain usability.

For example, if the shopping cart microfrontend encounters an error, the user can still browse products and use other features without being blocked.

5. Improved Developer Productivity

Microfrontends promote team autonomy and improve the efficiency of the development lifecycle.

Decentralized Ownership: Each team owns its microfrontend, enabling them to focus on delivering high-quality features without dependencies on other teams.
Faster Onboarding: New developers can quickly ramp up by working on a single microfrontend instead of navigating a massive monolithic codebase.
Clear Code Boundaries: Smaller, well-defined codebases are easier to maintain and refactor over time.

For example, a newly hired developer can start contributing to the "user profile" microfrontend without needing to understand the entire application.

6. Better Maintainability and Code Reusability

Microfrontends help in keeping the codebase maintainable and encourage reusability.

Smaller, More Manageable Codebases: Since each microfrontend focuses on a specific domain, it is easier to debug, refactor, and enhance.
Easier Upgrades: If a new feature or optimization is needed, only the affected microfrontend needs modification, reducing the overall risk.

For example, a company using a shared component library can update the navigation bar across all microfrontends without rewriting each module separately.

7. Enhanced User Experience Through Independent Improvements

With microfrontends, teams can improve individual features without waiting for large-scale application updates.

Incremental Feature Releases: Teams can introduce new UI/UX improvements in one microfrontend without requiring updates to the entire application.
Localized Performance Optimization: Performance bottlenecks in one microfrontend can be addressed independently, improving overall responsiveness.
Gradual Feature Rollouts: New features can be released to specific user segments for testing before a full rollout.

For example, a company can launch a redesigned checkout flow as an experimental microfrontend for a small percentage of users before making it the default experience.

Drawbacks of Microfrontend Architecture

While microfrontend architecture offers numerous advantages, it also comes with challenges that developers and organizations must consider before adopting it. Below are some of the key drawbacks:

1. Increased Complexity

Microfrontends introduce additional complexity in multiple areas:

Multiple Codebases: Instead of a single frontend, you now have multiple repositories and projects to manage.
Integration Overhead: Combining different microfrontends into a seamless application requires extra effort in routing, communication, and shared state management.
Build & Deployment Challenges: Coordinating multiple independent deployments can be tricky, requiring careful versioning and testing.

For example, ensuring that microfrontends work correctly together when deployed separately can lead to integration headaches, requiring sophisticated CI/CD pipelines.

2. Performance Overhead

Since microfrontends are often loaded dynamically at runtime, they can introduce performance issues such as:

Increased Bundle Size: Loading multiple microfrontends means downloading multiple JavaScript bundles, potentially leading to slower page loads.
Higher Network Requests: Each microfrontend might have its own dependencies, increasing HTTP requests and affecting performance.
CSS Conflicts & Style Loading: Ensuring that different microfrontends share consistent styles without conflicts can be challenging.

For example, if a microfrontend loads React, but the host application already includes React, it might lead to unnecessary duplication, increasing load time.

3. State Management Complexity

Since each microfrontend operates independently, sharing global state between them can be difficult:

Duplication of Data: Each microfrontend might fetch the same data separately, leading to inefficiencies.
Inconsistent User Experience: If state synchronization is not handled properly, users might experience issues like cart data not updating across microfrontends.
Communication Overhead: Using APIs, event buses, or shared stores (e.g., Redux, Zustand) can add additional layers of complexity.

For example a logged user in one microfrontend, has to be logged in the others. So microfrontends need to be aware of the authentication state, requiring inter-module communication.

4. Difficult Debugging & Testing

With microfrontends, debugging and testing become more complex because:

Distributed Logs & Errors: Since each microfrontend is independent, tracing errors across multiple modules can be challenging.
Multiple Testing Pipelines: Each microfrontend needs its own testing strategy, leading to increased testing effort.
Cross-Module Integration Testing: Ensuring that all microfrontends work well together requires additional end-to-end (E2E) tests.

For example, an error in one microfrontend might not appear in isolation but only when integrated with others, making debugging more difficult.

5. Technology Fragmentation

Although microfrontends allow teams to use different frameworks and technologies, this can also become a disadvantage:

Inconsistent User Experience: Different UI frameworks may result in slight variations in styles and interactions.
Larger Bundle Sizes: If different microfrontends use different versions of the same library, it increases the overall application size.
Developer Learning Curve: Teams working on different stacks may struggle to collaborate effectively.

For example, if microfrontends are built with different technologies (one with Vue, another with React) maintaining a uniform UI and behavior can become a challenge.

6. Security Risks

Microfrontend architectures introduce additional security concerns:

Cross-Origin Issues: If microfrontends are served from different domains, CORS (Cross-Origin Resource Sharing) policies need to be carefully managed.
Data Leaks: Since multiple microfrontends interact with shared resources, they may accidentally expose sensitive data.
Authentication & Authorization: Implementing a consistent authentication mechanism across multiple microfrontends requires careful planning.

For example, if authentication is handled differently in each microfrontend, users might experience inconsistent login behavior.

7. Higher Maintenance Effort

Maintaining a microfrontend-based system requires:

More Infrastructure Management: More services mean more DevOps work for deployments, monitoring, and logging.
Dependency Management: Ensuring that all microfrontends stay up-to-date without breaking compatibility can be challenging.
Increased Coordination Between Teams: Although teams work independently, they still need to align on integration points and shared resources.

For example, if a shared UI component library is updated, all microfrontends depending on it might need updates, leading to coordination challenges.

Conclusion

While microfrontend architecture provides scalability, flexibility, and independent deployments, it also introduces challenges such as complexity, performance overhead, and debugging difficulties. An architect must carefully weigh the pros and cons before adopting this approach, ensuring that the benefits outweigh the added effort and technical debt.

In essence, microfrontends empower organizations to build large-scale applications with greater flexibility and efficiency, overcoming many of the limitations of traditional monolithic frontends.

Shopping List: my way to learn stuff

Alberto Talone — Sat, 14 Nov 2020 21:20:25 +0000

Shopping list

Hi devs, I want to show you a simple app I have create for playing with Ionic 5 and Java Spring.

Let me introduce you to Shopping List

Shopping List is a simple app for manage my stuff to buy from grocery to clothes and other stuff when I go out.

But why create your own app when there are plenty of them? Just for learn some stuff, get my hands dirty and stress a bit my Raspberry :D

Let's take a look to a few key elements for the app and the server.

APP

The app is created with Ionic 5 and Angular 10.

The idea, behind this project, was to write some clean code and play a bit with RxJS operators, interceptors and guards.

The HTTP interceptor is necessary because I have to inject the OAUTH2 Token for all the request to the server.

    intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

        const currentUser = this.authService.currentUserValue;

        if (currentUser != null) {
            const token: string = currentUser.access_token;
            if (token) {
                request = request.clone({ headers: request.headers.set('Authorization', 'Bearer ' + token) });
            }
        }

        if (!request.headers.has('Content-Type')) {
            request = request.clone({ headers: request.headers.set('Content-Type', 'application/json') });
        }

        request = request.clone({ headers: request.headers.set('Accept', 'application/json') });

        return next.handle(request).pipe(
            map((event: HttpEvent<any>) => {
                return event;
            }),
            catchError((error: HttpErrorResponse) => {
                // TODO: Add 401 Handler
                return throwError(error);
            })
        );
    }

I used the RxJS operators for manipulate all the Observables used for calling the server.

I really used and loved a lot the catchError for handling server error response and throw them were I have subscribed to this observables.

Here is an example about an Observable I have created for retrieve the full list of shops.

    getShops(): Observable<IShopsResponse> {

    return this.http.get<IShopsResponse>(this.url + 'getAll').pipe((
      catchError((error: HttpErrorResponse) => {
        let err: IShopsResponse = null;
        err.status = error.status;
        err.message = error.error;
        return throwError(err);
      })
    ))
  }

Here is where I subscribe to the Observable and how I manage the error, and what to show to the user.

getAllShops() {
    this.shopService.getShops().subscribe(
      (response: IShopsResponse) => {
        this.list = response.data;
      },
      (error) => {
        let title = this.langService.getString('ALERT.error');
        let msg = this.langService.getString('ERROR.retrieve_list');
        this.alertService.showAlert(title, msg).then(
          (alertBox) => { alertBox.present(); }
        );
      }
    );
  }

Remember to take a look, if you haven't at RxJS documentation

SERVER

The server is created using Spring Boot framework.

The basic idea was to create a simple server with a basic authentication for the REST using OAuth2 following this tutorial.

After following this tutorial I decided to take a look at Spring Boot potentials and I find out the possibility of retrieve user informations without doing a ping-pong with ids and other private informations using SecurityContextHolder.

Here is a snipping of the function for the current user:

public User getCurrentUser(){
  Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
  if ((authentication instanceof AnonymousAuthenticationToken)) {
    return null;
  }

  String email = authentication.getName();
  Optional<User> optUser = userRepo.findByEmail(email);
  if(optUser.isEmpty()){
      return null;
  }

  return optUser.get();
}

Another element that I decide to add was a logger for request and response, a very usefull way to analyze future server errors.
For achieve this I had to create a specific class that extends HandlerInterceptorAdapter and with the some extra manipulation I was able to get my logs.

Here are the methods I created for the logs:

public void writeRequestPayloadAudit(ResettableStreamHttpServletRequest wrappedRequest) {
  try {
    String requestHeaders = getRawHeaders(wrappedRequest);
    String requestBody = org.apache.commons.io.IOUtils.toString(wrappedRequest.getReader());

    LOGGER.info("=================================== Request Start ===================================");
    LOGGER.info("Request Method: " + wrappedRequest.getMethod());
    LOGGER.info("Request URL: " + wrappedRequest.getRequestURI());
    LOGGER.info("Request Headers:" + requestHeaders.replace("\n", ","));
    LOGGER.info("Request Body:" + requestBody.replace("\n", ""));
    LOGGER.info("==================================== Request End ====================================");

  } catch (Exception e) {
    LOGGER.error("Exception Request" + e.getMessage());
  }
}

public void writeResponsePayloadAudit(ResettableStreamHttpServletResponse wrappedResponse) {
  String rawHeaders = getRawHeaders(wrappedResponse);

  LOGGER.info("=================================== Response Start ===================================");
  LOGGER.info("Response Status: " + wrappedResponse.getStatus());
  LOGGER.info("Response Headers:" + rawHeaders.replace("\n", ","));

  byte[] data = new byte[wrappedResponse.rawData.size()];
  for (int i = 0; i < data.length; i++) {
          data[i] = (byte) wrappedResponse.rawData.get(i);
  }

  String responseBody = new String(data);
  LOGGER.info("Response body:" + responseBody);
  LOGGER.info("==================================== Response End ====================================");
}

And here is how my logs looks like:

2020-10-30 18:32:35,583 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] =================================== Request Start ===================================
2020-10-30 18:32:35,584 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] Request Method: GET
2020-10-30 18:32:35,585 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] Request Headers:content-type:application/json,authorization:Bearer 6de79b7b-03bd-4e05-a8f8-af7f618d2fbc,user-agent:PostmanRuntime/7.26.5,accept:*/*,postman-token:18287157-4a9d-483f-9031-62cc2b3aa5dd,host:localhost:8080,accept-encoding:gzip, deflate, br,connection:keep-alive,
2020-10-30 18:32:35,585 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] Request body:
2020-10-30 18:32:35,586 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] ==================================== Request End ====================================
2020-10-30 18:32:35,647 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] =================================== Response Start ===================================
2020-10-30 18:32:35,648 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] Response Status: 200
2020-10-30 18:32:35,648 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] Response Headers:Vary:Origin,Vary:Origin,Vary:Origin,
2020-10-30 18:32:35,649 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] Response body:{"status":200,"message":"","data":[[{"id":1,"name":"Supermercato 1","createdAt":"2020-10-29T22:44:33","updatedAt":"2020-10-29T22:44:33","deleted":0,"total":0,"bought":0,"items":[]}],[{"id":2,"name":"Supermercato 2","createdAt":"2020-10-29T22:44:41","updatedAt":"2020-10-29T22:44:41","deleted":0,"total":0,"bought":0,"items":[]}],[{"id":13,"name":"Supermercato 3","createdAt":"2020-10-29T22:49:06","updatedAt":"2020-10-29T22:49:06","deleted":0,"total":0,"bought":0,"items":[]}]]}
2020-10-30 18:32:35,649 INFO com.bebetos.shoppinglist.interceptors.LoggerInterceptor [http-nio-8080-exec-3] ==================================== Response End ====================================

Special credits to my friend Alessandro Valenti for Angular advices.

For extra code informations here is the link to the repository.

What are your opinions/advices?