Os 2 cenários problemáticos mais comuns no desenvolvimento de softwares. Será que você já passou por algum deles?

Não é incomum encontrar pessoas desenvolvedoras em fóruns contando sobre falhas em projetos que participaram — desde softwares sendo desenvolvidos sem considerar a experiência do usuário até equipes ignorando problemas óbvios apenas para entregar o produto mais rápido. Se você for uma pessoa desenvolvedora, é até provável que você já tenha lidado com um desses erros por aí.

Dentre esses cenários, tem dois que eu considero mais graves, exatamente pelo impacto que eles podem gerar futuramente. E o pior: no geral, esse impacto gera custos desnecessários, que poderiam ter sido evitados se outra postura tivesse sido adotada.

1º cenário: tratar o software como pastel

Muitas empresas ainda enxergam a área de desenvolvimento de software como uma pastelaria: basta pedir o que deseja e, então, estará tudo pronto em pouquíssimo tempo. Infelizmente, não é bem assim que tudo funciona.

Algo muito comum, é o uso do conhecido “Go-horse”, onde as coisas são feitas bem rápidas, apesar de ser efetivo no início, esse modelo traz diversos impactos no futuro, e para isso nós temos diversas metodologias, e padrões que podem nos ajudar a enfrentar menos dores de cabeça.

Conseguir escolher as melhores opções de arquitetura, e padrões quando estamos com a mentalidade de fazer às pressas é altamente improvável. No geral, quando se segue o estilo “pastelaria”, o resultado acaba sendo um projeto feito em uma arquitetura inadequada, que desconsidera as necessidades a longo prazo. Sem contar os problemas e bugs que costumam ir aparecendo conforme o software é usado, devido à falta de tempo que foi disponibilizada para revisões e testes.

Realmente, fazer softwares às pressas pode até parecer vantajoso e econômico à primeira vista, mas os problemas sempre surgem com o tempo. Será que realmente vale a pena? Eu sou do grupo que acredita que não.

Se usar mais tempo e ter mais cuidado no desenvolvimento irá trazer bons frutos a longo prazo, então, para mim, esse é o melhor caminho — mesmo que dê mais trabalho e exija mais dedicação.

2º cenário: criar um software extremamente rígido

Também já ouvi muitos desenvolvedores e desenvolvedoras afirmando que um bom software deve ser firme como um prédio. Ou seja: deve ter uma arquitetura rígida e robusta para ser realmente considerado de qualidade. No entanto, seguir esse caminho sem ponderar anteriormente, pode resultar em uma série de questões a longo prazo. Alguns exemplos são:

• precisar reescrever softwares anualmente, porque, devido à sua inflexibilidade e inextensibilidade, o software não consegue contemplar as novas necessidades do cliente;
• levar mais tempo para fazer mudanças geralmente simples, novamente devido à inflexibilidade do produto desenvolvido;
• maiores custos de manutenção devido à robustez do software;

Se clientes, realidades e necessidades mudam, não há sentido em insistir em uma arquitetura rígida para todos os softwares que você desenvolver. Em quase 100% dos casos é extremamente benéfico criar um produto flexível e extensível, mesmo que demande um pouco mais de dedicação.

Na minha opinião, a questão da rigidez pode ser especialmente resolvida com a aplicação de uma arquitetura de camadas, que também é chamada de triângulo invertido do front-end.

(Se você quiser saber como essa arquitetura funciona, eu e a Leticia Coelho falaremos mais sobre ela em nossa palestra na The Developer’s Conference, que acontecerá às 10:30, na quarta-feira (09/06). Você pode se inscrever aqui para acompanhar essa e outras palestras que acontecerão na trilha da ArcTouch ao longo desta semana).

E aí, você já cometeu algum dos erros que mencionados acima? Se sim, você precisou tomar alguma atitude para solucioná-los? Vamos trocar experiências aqui nos comentários!

* Esse artigo foi escrito em parceria com o Leticia Coelho, Engenheira de Software na ArcTouch.