Olá, pessoal! Recentemente acompanhei uma discussão no LinkedIn que trazia o seguinte enunciado: “Como sabemos se uma empresa é escalável e sustentável?”. Apesar de interessante, poucas respostas foram postadas e os membros não chegaram a um consenso unânime. Diante dessa dúvida, decidi elaborar um artigo com a minha perspectiva sobre o assunto e, talvez, contribuir com a base de conhecimento de profissionais ágeis. Acompanhe-me!
Introdução
Para compreender melhor o contexto do artigo, vale esclarecer as definições dos termos “sustentável” e “escalável”, e os motivos que os fazem importantes em uma empresa de desenvolvimento.
Sustentabilidade, assim como utilizado na área de meio ambiente, refere-se à capacidade de manter um software com uma arquitetura bem definida, com componentes reutilizáveis e códigos-fonte de fácil manutenção para não comprometer o ciclo de vida futuro do projeto. Ao contrário do que alguns inferem, sustentabilidade não significa construir um software com uma taxa inexistente de erros. Atividades de correção sempre serão necessárias, naturalmente. No entanto, a diferença é que um projeto sustentável facilita a correção de erros com um mínimo (ou nenhum) impacto paralelo. Quando um novo incidente é encontrado no software, tanto o rastreamento quanto a correção devem ser factíveis, utilizando o menor tempo possível e o menor número de pessoas envolvidas.
Escalabilidade, por sua vez, está relacionada com o nível de maturidade e coordenação de uma empresa durante a evolução do projeto. É uma questão técnica e administrativa. Assim como a arquitetura do software deve estar sempre disponível para “receber” novas funcionalidades, as equipes e a gerência também devem estar “preparadas” para desenvolvê-las. Em outras palavras, à medida que o software cresce, em dimensão e em número de usuários, a empresa deve oportunizar o recrutamento e integração de novos programadores, como também manter o projeto ampliável.
Pois bem, leitores, alcançar níveis satisfatórios de sustentabilidade e escalabilidade, como sabemos, não é algo trivial. Todavia, há algumas orientações que podem colaborar para a busca dessas características.
Sustentabilidade
No quesito sustentabilidade, continuo batendo na mesma tecla: Engenharia de Software. Um projeto só se torna sustentável quando apresenta práticas dessa disciplina, como os princípios SOLID, criação de bibliotecas de código reaproveitáveis e muita, muita Orientação a Objetos, em conjunto, claro, com as diretrizes de Clean Code. Código sustentável é sinônimo de código de fácil manutenção.
É muita coisa? Calma! Utilizar todas essas práticas de uma só vez nos levará à frustração. O segredo é empregá-las gradativamente, como uma forma de melhoria contínua. Esse é um ponto importante mencionado no Lean Thinking, lembram-se?
A arquitetura do código só pode ser mantida por desenvolvedores com uma boa bagagem de conhecimento em Engenharia de Software, cada vez mais capacitados para aplicar princípios técnicos, buscar a alta coesão e empregar Design Patterns. Se esse conhecimento ainda não existe, forneça-o por meio de cursos, treinamentos, Kata e Kaizen e Coding Dojos.
Se o objetivo é atingir um nível adequado de sustentabilidade, talvez o ponto de partida seja uma evidente transformação na cultura da empresa. Em seguida, iniciar aprimoramentos arquiteturais, como a padronização de código, criação e divisão de classes, limpeza de código e aplicação de padrões de projeto, sempre priorizando a melhoria contínua. Alguns recursos também são bastante úteis para essa finalidade, como revisores de código, métricas e profilers. Por experiência própria, eu garanto um resultado positivo desse processo.
Escalabilidade
Por sua vez, a escalabilidade, como disse anteriormente, é dividida em questões técnicas e administrativas. O aspecto técnico é relacionado primariamente com a possibilidade de evoluir o software sem impactos consideráveis no código já existente e funcional. A arquitetura deve disponibilizar APIs, bibliotecas e classes-base para extensão do software, como uma ramificação de funcionalidades. Isso nos faz lembrar do princípio Open/Closed do SOLID! 🙂
Sobre a questão administrativa, me refiro, em especial, ao gerenciamento de equipes em empresas que utilizam metodologias ágeis. Diga-se passagem, são muitas! Embora o Scrum forneça um framework eficiente para a gestão de equipes, essa metodologia, por si só, infelizmente não é escalável. Por exemplo, é nitidamente inviável conduzir reuniões de planejamento, reuniões diárias e retrospectivas em uma equipe de 100 desenvolvedores, sem falar no controle do Task Board e definição de papéis.
Como solução, podemos dividir os desenvolvedores em várias equipes ágeis distintas, certo? Legal, isso já é um indício de escalabilidade. No entanto, antes mesmo de “escalarmos” as equipes, é importante mencionar que já existe um framework exclusivo para esse propósito, chamado Scaled Agile Framework (SAFe), elaborado por Dean Leffingwell.
O SAFe aborda a maioria das questões de escalabilidade um uma empresa de grande porte, desde os objetivos de negócio até o desenvolvimento de funcionalidades por múltiplas equipes ágeis. Com este framework (e outros semelhantes, como o Large-Scale Scrum), a escalabilidade vai de encontro com o Desenvolvimento Ágil, produzindo células de trabalho de alta performance.
Até a próxima!
Ótimo artigo André!
Na sua opinião, quais seriam os primeiros passos para tornar o código Delphi de um ERP de 7 anos sustentável? Considerando um cenário atual sem testes unitários, sem padrões de projeto, fracamente orientado a objetos, com uma equipe SCRUM extremamente enxuta.
São tantas as técnicas e soluções possíveis que fica até difícil dar o primeiro passo.
Olá, Daniel, tudo certo?
Ótima pergunta! Diga-se de passagem: esse é um cenário relativamente comum em algumas empresas de software. O projeto cresce sem uma arquitetura definida e a sustentabilidade infelizmente acaba sendo negligenciada.
Pois bem, Daniel, como você mesmo mencionou, a iniciativa é a parte mais difícil. No entanto, já me deparei com uma situação semelhante e talvez eu possa orientá-lo com base na sequência de procedimentos que executamos.
Em primeiro momento, padronizamos o código em geral. Utilizamos Notação Húngara em nome de variáveis, ajustamos os nomes de métodos (de “Consultar” para “ConsultarPedidosPorPeriodo”, por exemplo), declaramos constantes para letras e números (como “NUMERO_ITENS = 30”) e empregamos tipos enumerados. Em seguida, começamos a refatorar alguns métodos, iniciando pela aplicação do princípio SRP do SOLID. Pensamos que, com métodos pequenos, ficaria mais fácil modelar novas classes e estendê-las. Além disso, durante a refatoração, identificamos muita duplicação de código, principalmente de funções básicas, e buscamos centralizar as regras de negócio de acordo com seus respectivos conceitos.
Quando atingimos esse estágio, já era possível partir para a criação e divisão de algumas classes e, com isso, trabalhar também com heranças.
Daniel, embora tenha funcionado, devo dizer que levou um bom tempo. Portanto, nada impede que você, assim como outras empresas, inicie de uma forma diferente. O que importa é movimentar-se em direção à sustentabilidade do código!
Abraço!