Analogia ao desenvolvimento gradual de software

Olá, leitores! O objetivo do artigo de hoje é discutir um assunto que a maioria dos desenvolvedores já conhece: o desenvolvimento gradual de software. A ideia é apresentar uma analogia que pode nos fazer refletir sobre o crescimento de um software com o passar do tempo, bem como os cuidados que devemos tomar para que este crescimento não fuja do nosso controle.
Talvez esse artigo seja interessante para quem está ingressando na área de desenvolvimento.

Introdução

Quem já me conhece, sabe que sou do interior de São Paulo mas atualmente moro em Florianópolis. A cidade em si, as praias, os restaurantes, os pubs e as avenidas são bem bonitos, porém, Florianópolis infelizmente apresenta um grande problema: a mobilidade. O trânsito aqui é bastante intenso, principalmente em altas temporadas. Alguns estudos até afirmaram que a cidade tem a pior mobilidade urbana do Brasil. Em alguns dias, já demorei quase 3 horas para atravessar a Avenida Beira Mar e chegar ao continente.

Certa vez, eu estava na Rodovia Admar Gonzaga – uma avenida de mão dupla que liga alguns bairros da cidade – e o trânsito estava bem lento. Cansado de esperar na fila, pensei: “Já que é uma avenida de vários acessos, por que já não a fizeram com várias pistas quando a construíram? Hoje o trânsito estaria bem melhor”. Mas, meu pensamento estava equivocado. Na época em que construíram a avenida, os engenheiros nunca imaginavam a proporção que a cidade tomaria. Não faria sentido construir uma avenida larga para os poucos habitantes que moravam na cidade. Fazendo uma analogia da analogia, é como se comprássemos um ônibus para viajar somente em 4 pessoas.

A propósito, já identificou a analogia? Ao desenvolver um software, em alguns casos, acontece a mesma coisa. O crescimento do número de clientes e usuários é imprevisível, e isso significa que é praticamente improvável que um software seja construído, logo de primeira, em uma dimensão que será sempre adequada para o cliente. É por isso que softwares estão em constante evolução, e também é por esse motivo que desenvolvedores geralmente são contratados para trabalhar na manutenção e expansão de sistemas de informação.

Mas, e no caso da avenida? Não basta apenas fazer uma reforma e aumentá-la para desafogar o trânsito? Sim, mas lembre-se de que há prédios, casas e estabelecimentos ao redor dessa avenida. Uma simples reforma afetaria uma parte da arquitetura da cidade.

Arquitetura?

Sim. Softwares também são construídos com base em arquiteturas, que representam a forma como as classes, interfaces, componentes e módulos estão organizados. E as reformas? O que acha de compará-las com as modificações que realizamos no software? Afinal, quando aplicamos uma refatoração, por exemplo, buscamos aprimorar a nossa arquitetura, visando um melhor desempenho, flexibilidade ou simplesmente facilitando a manutenção.

Do mesmo modo, assim como os prédios e as casas, devemos nos atentar às dependências ao redor da nossa arquitetura, como as classes e módulos dependentes. Uma refatoração, quando não feita apropriadamente, pode afetar outros pontos do software. Para evitar que isso ocorra, existem os testes unitários!

Aqui deixo uma observação. No desenvolvimento de software há dois tipos de “reformas”: a expansão e a refatoração. Muitas vezes, elas caminham de mãos dadas, ou ao menos deveriam. Quando expandimos o nosso software, acrescentando novas funcionalidades, estamos aumentando a nossa avenida, enquanto a refatoração seria como “recapeá-las”. Observe que a adição de novas funcionalidades é uma necessidade advinda do cliente (ou da população), isto é, algo que deve ser feito para que o negócio do cliente continue funcional, ou, no caso da avenida, para que a mobilidade continue acessível.

No interior de São Paulo, onde nasci, recentemente duplicaram uma das principais rodovias. Além da adição da nova pista, também recapearam a rodovia antiga, ou seja, aproveitaram a reforma e melhoraram algo que já existia antes. É isso que também devemos fazer! À medida que o software cresce, é nosso dever refatorar o que for possível para manter o código “conservado”. Se isso não for feito, em pouco tempo surgirá código repetido em várias classes, ou buracos nas ruas.

Robert Martin, autor do livro Clean Code, menciona que, toda vez que realizamos alguma modificação no software, devemos deixar o código cada vez mais limpo, criando uma espécie de hábito. Se você encontrou uma classe que pode ser desacoplada, um método passível de ser refatorado, ou simplesmente uma variável que pode ser renomeada, então faça-o! Não deixe para depois, ou cairá no esquecimento.

Mas, atenção: nunca faça como a operação “tapa buraco” que ocorre em algumas cidades. Ao meu ver, essa é apenas uma forma de empurrar o problema para a frente. Talvez, devido aos prazos de entrega, surja uma tendência em praticar algo dessa natureza, embora não seja nada recomendável. Se estamos tapando buracos ao invés de resolvermos os problemas, então algo está errado! No cenário de desenvolvimento de software, “improvisar” é um verbo que não deve existir.

Aqui em Florianópolis, há ainda mais um agravante. Só no meu bairro estão construindo mais 5 prédios novos, porém, a estrutura do sistema de esgoto público não está preparada para atender todos estes prédios. Há vazamentos de água em várias ruas em função dessa insuficiência. Será que eles não previram estes impactos no projeto de construção?

Projeto?

Sim e, que coincidência, também existem os projetos de software! Antes da fase de desenvolvimento, os requisitos passam por uma fase de planejamento para que os custos, prazos e a qualidade do software sejam alcançados em conformidade. Para isso, há estimativas de recursos, administração de contratos, controle de qualidade e gerenciamento de riscos. No caso de um novo módulo em um software que já existente, também é realizada uma análise de impacto, propriamente direcionada para não causar consequências colaterais no que já está funcionando. Talvez seja isso que faltou nos projetos de construção dos novos prédios. Muitas vezes, pensam demais nos resultados finais e esquecem de possíveis consequências.

Fico por aqui, leitores!
Sei que a analogia não é das melhores, mas a ideia foi transmitida! 🙂
Abraço!