Breve relato de um dev sem experiência

Eu já li algumas experiências de usuários e gostaria de compartilhar minha experiência no mundo da programação com vocês e os perrengues que podem acontecer. Não chega aos pés do que muito desenvolvedor já sofreu para resolver. Tenho certeza disso. É somente uma história, dentre muitas outras.

Antes, um pouco da minha história. Me formei, tarde, aos 31 anos em Análise e Desenvolvimento de Sistemas. Aos 33 fui alçado a coordenador do setor de tecnologia da unidade onde trabalho, onde fiquei por 09 anos. Mas, já possuia dois anos de atuação no setor na área de suporte. A minha função de coordenador, e tão pouco de suporte, não era para desenvolver sistemas. Era uma função mais administrativa/técnica. E isso defasou meu conhecimento, pois, não acompanhei as novas tecnologias e sistemas que surgiram depois. Não é uma reclamação, é uma constatação.

Deixa eu lhe contar um pouco da minha trajetória como coordenador. Assumi um setor completamente sucateado. Sem as menores condições de funcionar como deveria. Qualquer um em meu lugar, poderia desistir. As condições eram péssimas: computadores e modelos de atuação defasados, rede lógica e elétrica precárias, cultura de uso que não condizem com as regras vigentes, entre tantas outras situações que deixariam qualquer um de cabelo em pé. 

Quando comecei a implementar as mudanças e adequar a unidade onde trabalho, houve reclamações diretas a mim e a minha chefia sobre o que eu estava fazendo. Minha chefia na época, depois que expliquei que era uma questão legal, que uma única multa que tomássemos podia chegar a módicos (sarcasmo) R$ 3.000.000,00 “comprou” a briga e disse a todos os meu colegas que era o que tinha que ser feito. Eram normas e todos tinham que seguir. Já fica uma dica: faça o que é certo. Por mais que desagrade muitos. Se é o certo a ser feito, se está escrito que tem que ser feito assim, que seja feito assim. E aguente as críticas, pois, é algo comportamental dos outros. Não é culpa sua. 

Acha que agora virou um mar de rosas? Não. Surgiu o primeiro problema a ser resolvido em termos de segurança de rede e de computadores. Como disse, anteriormente, a situação era precária, lembra?

Minha antiga função tem, em uma das suas diretrizes, assegurar a segurança da rede corporativa. O problema é que não tinha as mínimas condições de serem executadas. Com qual ferramenta? Não tinha. Não foi fornecida. E um dos problemas era simples e caótico ao mesmo tempo: O uso de dispositivos externos para transportar arquivos. Estamos falando de quase 10 anos atrás e sem os serviços de armazenamento em nuvem, tão difundidos hoje. Sem contar que o sistema operacional Windows não possuía as proteções de segurança que têm hoje (até hoje não tem muita). Enfim, era outra época.

O problema era que não podíamos restringir o uso desses dispositivos. Eram ferramentas de trabalho dos meus colegas, mas, por outro lado, tinha que proteger a rede, pois, dispositivos externos eram meios de transporte de todo tipo de vírus. Viram o drama?

Estava há mais de 02 anos formado, sem nenhuma experiência na área. Não tinha sequer feito o estágio em uma empresa. Meu estágio foi o trabalhado. Era técnico de suporte, lembra? Onde moro não há empresas consolidadas onde pudesse ter essa experiência. A possibilidade de trabalhar ou fazer estágio de forma remota, como hoje, era algo impensável. Me recordo de participar de um debate na faculdade sobre esse modelo de trabalho, em que fui escolhido para defender o modelo presencial, mas, no fim do debate, fui enfático em dizer, aos colegas, que adoraria trabalhar de forma remota.  

Minha primeira experiência em desenvolvimento de uma solução foi com esse problema. 

O que eu tinha como parque tecnológico? Grande parte dos computadores com sistema operacional Windows. Minhas pesquisas retornaram que o Windows tem uma aplicação que se chama Windows Management Instrument, ou WMI. Não vou entrar em detalhes sobre a aplicação. Fica a dica para pesquisa. São muitas as implementações possíveis com essa ferramenta. Me lembro de ter entregue um desafio de projeto sobre padrões em Java em que escolhi o “Observer”. Já tinha conhecimento desse evento no sistema operacional mencionado. 

O WMI possui uma implementação que consiste em ouvir eventos que acontecem em todo o sistema operacional. E depois de muita pesquisa e muitas falhas de implementação foi finalizado e implantado um serviço do Windows, que eu denominei de Eject.  

O Eject tem por objetivo ouvir eventos de inserção, em portas USB, e verificar se os mesmos têm a proteção de segurança, que consistia em blindar a raiz do dispositivo de possíveis ataques de vírus.

A partir do momento em que passamos a instalar o serviço nos computadores da unidade onde trabalho, o usuário não podia utilizar dispositivos externos, sem proteção, nos computadores da unidade, pois, o serviço Eject não permitia. Assim, o usuário tinha que ir no setor de TI e nós blindávamos o mesmo. Sabe quantos eventos de infecção, causados por dispositivo externo, eu tive nos computadores da unidade depois disso? 0. Por consequência, essa solução protegeu a nossa rede, nossos computadores, o computador pessoal de quem usava o dispositivo e o computador onde o dispositivo pudesse ser utilizado. Virou um ciclo de proteção. Gostou?

Então, vou lhe contar a minha segunda experiência com desenvolvimento. Em 2016 eu aceitei o pedido de um diretor, onde trabalho, para desenvolver uma aplicação que tinha por objetivo realizar o controle de fluxo de documentos entre a nossa unidade e outras unidades que estão sob a nossa jurisdição.  

Detalhe: Tinha que implantar tudo sozinho. Front-End, Back-End e Banco de Dados. Sem equipe para dividir essas tarefas e sem conhecimento aprimorado. Já tinha mais de 05 anos de formado, conhecimento parco em tudo. Só uma experiência bem sucedida, por assim dizer. Se você acha que faculdade vai lhe dar experiência, está enganado. Lhe dar as bases. E só. O resto é muita prática. Estudo. Erros. Por mais que sua análise e seu planejamento sejam ótimos. Vai ter erro. Pode ter certeza. Sem contar as evoluções tecnológicas que ocorrem de tempos em tempos.

Já que tinha aceitado o desafio, levantei os requisitos. 

A solução tinha que funcionar em rede. Assim, o banco de dados tinha que ser centralizado em um servidor. Você acha que tínhamos orçamento para pagar uma hospedagem profissional? Não tínhamos e não temos até hoje. 

Solução: Criar uma hospedagem para o servidor de bancos de dados, próprio, com os recursos necessários para funcionar. Agradeço ao meu amigo e companheiro de setor Júlio, fica aqui a minha homenagem e gratidão a ele, que com o seu conhecimento na área montou esse servidor para mim. 

Sem orçamento, surgiu outro problema: Se não vai ter dinheiro para nada, todas as ferramentas de desenvolvimento tem que ser grátis. Isso incluía IDE, SGDB e qualquer outra ferramenta necessária para que o programa pudesse funcionar.

Quais banco de dados são opensource e grátis: Na época eu vi que tinha que desenvolver com o FireBird. O Mysql tem algumas restrições de uso comerciais e onde trabalho não pode ter programa sem licença comercial (lembra os módicos R$ 3.000.000,00?).

A aplicação tinha que ser descentralizada. Tinha que estar disponível para uso em todos os computadores de nosso parque tecnológico. 

Meu erro, na época, foi não aproveitar a oportunidade e ter me reciclado. Deveria ter aproveitado e implantado a solução como uma aplicação WEB. Eu não tinha prazos, não tinha que cumprir cronogramas. Mas, queria tanto começar a aplicação que fiz o que: implantei de forma legada em VB.NET. Programação Orientada a Eventos. Pode rir. Eu mereço. Mas, era a linguagem e estrutura que eu dominava na época. Hoje está se transformando em soft skill pelo que leio sobre a linguagem e o paradigma. 

A aplicação funciona? Está funcionando até hoje.

Você acha que foi fácil o processo de implementação? Não. A pessoa que me pediu para desenvolver a aplicação não tinha regras claras e definitivas do que queria. Na fase de análise as regras mudavam a todo momento. O que tinha que ser hoje, amanhã já mudava.

Solução:

Convidamos alguns colegas que iriam trabalhar de forma constante com a aplicação, explicamos os motivos e solicitamos ideias e sugestões.

Criamos regras de negócios mais robustas. Não ficamos mudando ao sabor de ideias mirabolantes e, algumas, sem nexo funcional.

reanálise e readequação do projeto; 

Com isso ficou mais fácil as mudanças objetivas que surgiram.

Fica a dica para pesquisa de modelo de desenvolvimento de softwares. 

Quando começamos a utilizar a versão Beta do programa com alguns servidores fazendo o teste para analisarmos o desempenho começaram a surgir algumas situações não previstas na análise. A aplicação tinha como principal função controlar documentos, lembra? Para isso, a aplicação tem um controlador que gera um número automático e sequencial de identificação. Vou confessar que a primeira versão que eu desenhei, foi um fiasco. Deixou o sistema lento e cheio de possibilidades de gerar números repetidos. 

Solução:

Desenhar outra forma de gerar os números de forma sequencial. 

Mas, a outra forma que desenhei apresentou outro problema: A concorrência no banco de dados. 

Depois de algumas pesquisas, descobri que o Firebird tem uma função denominada de “with lock”. Ela bloqueia o acesso de leitura de outras requisições em uma tabela. Só libera depois que a transação que solicitou a leitura completa a requisição. 

Assim foi possível desenhar um novo controlador e o problema com os identificadores foi resolvido.

Deu certo. O aplicativo funcionou? Sim. Deu certo e o aplicativo estava funcionando “redondo”. 

Só que surgiu um novo problema: O sistema funcionava de forma unilateral. Só controlava o envio dos documentos da sede para as unidades. Não fazia o contrário. Qual o pedido? Controlar o fluxo inverso.

Infelizmente, isso não foi solicitado na época do levantamento de requisitos, mas, fica a dica de pesquisa para manutenção evolutiva do sistema.

Depois de um tempo de análise e implementação, finalmente a versão 3 da aplicação começou a funcionar. Você acha que eu respirei depois disso? Se enganou. Começou uma série de problemas, dessa vez com o usuário do sistema. Não tinha ninguém para dar o suporte. Mesmo que a aplicação tivesse sido, devidamente, documentada. Eu era o desenvolvedor, não suporte. Isso tinha que ser delegado a outra pessoa, mas, como eu sabia mais do sistema do que os outros acumulei a função de suporte, também.

Pronto, agora que resolveu os problemas você foi dormir em paz? Ainda não. A aplicação tem uma regra de negócio que se chama o “Fechamento do Malote”. A partir do momento em que um administrador (eu não mencionei antes, mas a aplicação tem três perfis de usuário) fechasse o malote, nenhum outro documento poderia ser entregue no protocolo. Não enquanto o protocolo não despachasse os documentos que estavam ali. Sabe o que acontecia: o administrador sempre esquecia de fechar o malote no dia e horário correto. 

Solução:

Criar uma forma de fazer com o que malote fechasse “sozinho”. Na versão 6 da aplicação foi implementado um serviço do Windows que, todo dia verifica se há uma data cadastrada para fechamento do malote. Caso ele verifique que a data cadastrada seja a atual, realiza o fechamento.

Terminou? Não. O administrador começou a esquecer de cadastrar, na aplicação, quais eram as datas e horários que o serviço deveria ler e realizar o fechamento do malote.

Solução:

Nenhuma. Não dá para fazer mágica. 

Isso que escrevi são as partes mais importantes do que passei para deixar essa aplicação funcionando da forma como ela está hoje. E isso me consumiu 05 anos entre desenvolver a aplicação e mantê-la. Claro que eu não fiquei 05 anos direto. Tinha as minhas atribuições de coordenação que eram prioritárias. E não eram poucas. 

E hoje, vendo o que o mercado tem de novo em termos de frameworks e formas de desenvolvimento, vou lhe falar uma coisa: Se eu tivesse que desenvolver a versão 7 desse sistema ela ia ficar muito melhor em termos de desempenho. A forma que eu desenvolvi o sistema foi muito nativa, na unha. Com as facilidades e recursos de hoje, ia ser muito mais fácil.

Se esse relato vai lhe inspirar ou não, eu não sei, mas, eu queria, com esse breve relato das minhas experiências, mostrar a você que, talvez, isso vai ser o seu caminho. Pode vir a ter momentos calmos, mas, podem ter momentos muito complicados. E nos cabe resiliência para resolver os problemas que podem vir a surgir. O que escrevi foi só as partes mais importantes do perrengue.  

Então, se você acha que ser desenvolvedor é para você, estude, pratique, se desafie com projetos, mesmo que pequenos, e evolua. A experiência é fantástica.

Senão… 

Eu estou me devendo fazer outros projetos. Mas, vou resolver.

Conte a sua história.