Clebert Figueiredo

Hoje venho aqui compartilhar um processo que (em minha opinião) foi a melhor coisa que aconteceu para o projeto do qual faço parte.

Já faz alguns anos que faço parte do projeto de uma das maiores empresas de comunicação e streaming do Brasil, e isso é simplesmente incrível, pois venho aprendendo e evoluindo muito desde então. Lidar com desafios técnicos e de negócio que envolve milhões de usuários é algo realmente que muda a visão de um software e de seu impacto na vida das pessoas.

Logo que entrei no projeto fui designado para o famoso time de sustentação (bom, famoso entre eles, pois nunca trabalhei com sustentação na vida, ou achava que não). Após algum período de onboarding ficou claro qual seria o meu papel, e fiquei bastante animado com isso, pois era algo completamente novo, com diversos desafios jamais explorados.

O meu papel era bem simples: Solucionar o problema de dezenas, centenas ou milhares de clientes o mais rápido possível. Quanto maior a quantidade de clientes impactados, maior é a prioridade.

Podemos dividir "problema" em 2 categorias:

1. Backlog: É quando temos 1 ou mais clientes impactados que precisam ser corrigidos de alguma maneira;
2. Causa Raiz: É o que de fato está causando o problema. É aqui onde a torneira esta pingando e você precisa fazer ela parar de pingar, caso contrário você sempre terá um backlog para tratar.

Já sabe qual a prioridade, né?! TUDO!!

Aqui temos que ter trabalho em equipe, pois enquanto tem alguém focado no tratamento do backlog, o outro está investigando onde danado está a causa raiz, e não é nada tão simples o quanto parece, pois estamos lidando com DEZENAS de aplicações interligadas, onde uma depende da outra. É um trabalho bastante árduo essa investigação.

Com isso já da pra imaginar que precisamos de uma coisa muito importante: Entender o NEGÓCIO!
E em minha humilde opinião, está é a maior vantagem de se trabalhar em um time de sustentação, pois você acaba precisando de fato lidar na prática com o negócio.

Um exemplo simples: Vários clientes não estão conseguindo comprar algum produto e um aviso de "você tem outra compra em andamento!" é exibido.

Neste exemplo você tem uma percepção do negócio, e passa a matutar (pensar) quais seriam as aplicações que podem estar resultando naquele problema para o cliente.

Agora que você já conhece um pouco do mundo da sustentação, vou compartilhar algo que para mim pareceu um problema.

Na imagem abaixo coloquei como os times estavam trabalhando, onde o time de sustentação é completamente separado do time de desenvolvimento.

Consegue enxergar o mesmo problema que eu?

Na imagem é possível observar que o time de sustentação é "responsável" por todas as aplicações de todos os times. Ou seja, quem está na sustentação precisa ter sempre uma atualização de tudo o que pode ter de mudanças nas aplicações, pois isso afeta diretamente sua análise diante de um problema em produção. E bom, não é algo fácil manter essa sincronia entre os times.

O principal problema que consigo enxergar com este modelo é a sobrecarga que o time de sustentação tem, com essa grande responsabilidade de olhar para todas as aplicações para identificar um problema real em produção. Além de todo o conhecimento técnico que precisa ter é necessário ainda entender muito bem do negócio.

Agora veja como sustentação está hoje:

Hoje sustentação encontra-se dentro do time de desenvolvimento, o que (posso estar enganado) melhora e muito a resolução de problemas, principalmente os críticos, pois o time está sempre de olho nas aplicações pelas quais são responsáveis e agora também olhando com olhos de sustentação.

Isso, do meu ponto de vista, melhora e muito a atuação na resolução de problemas, pois imagine a seguinte situação: Hoje subiu para produção um novo fluxo de vendas e foi observado via monitoramento que existem clientes sendo impactados. Quem você acha que seria a melhor pessoa para analisar este problema e encontrar de forma quase imediata a causa raiz? Bom, não sei sua resposta, mas a minha é "o desenvolvedor que desenvolveu o fluxo". Faz sentido pra você?

Bom, era isso que queria compartilhar, pois nunca encontro conteúdos sobre sustentação com experiências reais, dai achei que seria uma boa.

E você, já trabalhou com sustentação?

If you're working with lists in Java, you've probably come across ArrayList and LinkedList. Both implement the List interface, both store ordered collections of objects, but under the hood, they work very differently. Choosing the right one can make a big difference in performance and memory usage.

Let’s break it down in a simple and practical way so you can decide which one fits your needs best.

How They Work Internally

ArrayList

• Implementation: Uses a dynamically resizable array.
• Access Speed: Super fast! Retrieving an element by index is O(1) because it directly accesses memory.
• Insertion/Deletion: Can be slow (O(n)) if done in the middle or beginning because shifting elements is required.
• Memory Usage: More memory-efficient compared to LinkedList since it only stores data.

📌 Best Use Case: When you need quick access to elements by index, like in a UI list or search feature.

Example: An e-commerce platform where products are mostly read, sorted, and displayed but rarely modified.

LinkedList

• Implementation: Built as a doubly linked list (each node points to the previous and next node).
• Access Speed: Slow for random access (O(n)) since you have to traverse the list from the start.
• Insertion/Deletion: Super fast O(1) when adding/removing elements anywhere in the list.
• Additional Capabilities: Implements the Deque interface, making it useful for stacks and queues.

📌 Best Use Case: When frequent insertions and deletions are needed, especially at the start or middle of the list.

Example: A messaging system where new messages arrive frequently, and old ones are removed dynamically.

When to Use Each One

Use ArrayList When:

✅ You need fast random access (e.g., displaying items in a UI list).
✅ The list is mostly read-heavy, with few insertions or deletions.
✅ Memory efficiency is a concern.

Use LinkedList When:

✅ Frequent insertions and deletions happen, especially at different positions.
✅ You need queue-like behavior (FIFO, LIFO operations).
✅ Sequential access is the primary use case.

When to Avoid Them

🚫 Avoid ArrayList if: Your use case involves frequent insertions/deletions in the middle of the list. The shifting of elements can become a performance bottleneck.

🚫 Avoid LinkedList if: You need fast random access to elements. Since it requires traversing from the start, performance can degrade significantly for large lists.

Conclusion

Choosing between ArrayList and LinkedList boils down to your application’s access and modification patterns:

✔ Use ArrayList for fast lookups and when you mostly read from the list.
✔ Use LinkedList for frequent insertions/deletions, especially in the middle or beginning of the list.

Understanding these differences will help you optimize your Java applications for speed and efficiency.

Happy coding! 🚀

I want to start this blog by introducing myself.

My name's Clebert (Clebert da Silva Figueiredo). I'm a software engineer from Brazil, and I love working with technology—especially Java development.

In addition to programming, I enjoy reading and playing the guitar.

On this blog, I'll be sharing insights, tutorials, and my experiences in the world of software development.

That's it for today!