Uberlândia - MG
+55 (34) 3016-0600

Você realmente sabe o que é Inovar no mercado de software?

Você realmente sabe o que é Inovar no mercado de software?

Seja sincero, você realmente sabe o que é Inovar no mercado de software?

O fato é que caminhei em muitas empresas, diversos clientes, clientes de clientes, estudos de caso, milhares de horas de leitura e aplicação de conceitos na prática, enfim.

Esse é um compilado de 8 tópicos do que seria realmente Inovar na minha opinião de profissional detentor de 10 certificações e Microsoft Certified Trainer desde 2016 comexperiência de mais de 10 anos com desenvolvimento e arquitetura de software.

1 – É preciso pensar (e muito) antes de Inovar.

Se você pensa que inovar é simplesmente implementar um sistema com frameworks de ponta na última versão, ou até mesmo programar naquela plataforma que está no “top of mind” de 20xx, acredito realmente que esteja enganado e eu explico adiante.

2 – Cliente “nem sempre” tem a razão.

Empresas realmente não conseguem viver sem seus clientes e isso é fato, mas acatar toda e qualquer “ordem” de cliente para estar no projeto costuma ser um tiro no pé.

O desafio principal (e que muitos não conseguem) é ser capaz de mostrar para o seu cliente o porquê que ele está “errado” (mesmo que ele não goste disso), ou arriscará o projeto implementando com um conjunto de exigências tecnicamente duvidosas para o escopo.

E talvez sim o seu cliente tenha razão, toda e qualquer sugestão ou “ordem” deve ser avaliada para todo e qualquer projeto.

3 – Não existe um bom software sem arquitetura (e bem definida).

Foi-se o tempo em que software de alto padrão sobrevivia sem uma sólida arquitetura, muitos julgam arquitetura como “perda de tempo“, talvez não saibam os benefícios de programar orientado a um fluxo ativo de implementação em vez de um “go horse“(que é um padrão que sempre existiu e sempre vai existir em software).

Software que não é de “alto padrão” também exige arquitetura, mesmo que não tão trabalhada, ou você ficará a copiar código e em algum momento, exigirá um trabalho adicional tanto pra implementar quanto pra efetuar manutenções.

4 – Inovar não é arriscar.

Você que desenvolve e coloca aplicações em produção utilizando versões beta ou até alpha de componentes ou até mesmo frameworks completos (por incrível que pareça, já presenciei esse tipo de situação), você está arriscando o seu projeto.

É conhecido que versões instáveis não tem suporte garantido, além de mudar uma hora pra outra (você realmente quer viver de refatorar código?), talvez tenha uma lógica envolvida nisso, se chama “o mercado de Inovar“.

A palavra Inovar exige realmente muito mais que a “daily build” de uma versão de um framework sendo aplicada frequentemente, exige um estudo de caso detalhado para determinar a viabilidade de tal tecnologia (o que na minoria das vezes é feito).

5 – Você “não inova” sem as tendências do mercado (será mesmo?).

Já ouvi bastante esse tipo de conversa, talvez para pessoas reféns das tendências de mercado…

Inovar é possível em tecnologias de 1, 5, 10 anos ou até mais, basta você saber onde está (você sabia que um framework é implementado por programadores? faça seu próprio framework se ele não existir [e sim, somente caso for necessário!]).

6 – Refatorar é preciso (será mesmo?)².

Alguns casos já me chamaram muito a atenção em relação ao índice de “code refactoring” nos projetos de alto padrão.. Será um erro?

Bom, levando em consideração que um software está sempre em evolução, novos requisitos de arquitetura e a própria evolução da mesma realmente pode existir, porém, há um limite.

Se seu dia a dia é efetuar replace em todos os arquivos, algo me aparenta estar errado, pois um refactor deve ser evitado ao máximo e ser feito apenas em casos evolutivos (porém sabemos que o mundo não é perfeito, mesmo assim tente evitar isso).

7 – Um sistema deve estar preparado para evoluções.

Sim, isso é verdade! Quantas vezes implementações julgadas como “fúteis” em alguma fase do projeto ajudaram (e muito)?

Toda estrutura realmente tem que ser planejada, desde que esteja no escopo do projeto, afinal, não é possível prever o futuro certo? ERRADO!

Implementações realmente simples que deveriam ser feitas no início são deixadas para depois e no final, oneram o custo do projeto (pois todos os desenvolvedores seguem um padrão só e dependendo do volume implementado, o refactor é gigantesco).

Sou a favor de ter uma balança para decidir entre o “fútil” e o necessário, se irá levar 5 minutos e poderá poupar 5 horas no futuro, porque não?

8 – Certificação não é tudo.

E realmente não é tudo, porém infelizmente hoje em dia nos cenários de mercado atuais, ser certificado é um diferencial tremendo.

Ter certificação de longe não significa que a pessoa é o “rei da plataforma“, somente indica que houve um interesse em aplicar um estudo teórico da tecnologia, a prática é diferente (e muito) da teoria, porém um não vive sem o outro.

Não existe uma boa prática sem uma boa teoria (acredite, você não pode somente copiar e colar código do StackOverflow, deve-se entender, aprender e desvendar o segredo das dificuldades).

Espero ter aberto a mente de pessoas que guiam os processos de software mundo a fora, pois as citações abordadas nesse artigo não são uma realidade exclusivamente do Brasil, e sim do mundo em relação a software de forma generalizada.

“Somos eternos aprendizes”

Conteúdo 100% autoral, baseado em experiências e fatos reais.

Escrito por Michel Oliveira em 30 de maio de 2019.