Você já teve a experiência de começar um projeto de software empolgado, com um time motivado e acabar se encontrando num projeto interminável, que gera uma tremenda dor de cabeça?
Vou listar uma série de sacadas ou princípios práticos para você conseguir concluir um projeto de software complexo, com base em minha experiência.
Mas lembre-se, você não precisa colocar todas em prática de uma vez, nem existe uma hierarquia de importância entre eles.
Escolha 3, pratique, melhore, depois avance.
Era para ser só mais um projeto de software
O projeto de software parecia viável e muito promissor no início (ou até simples), mas se tornou aquele do qual todos fogem; ou trabalham reclamando e se arrastando sobre o teclado.
Pedir pra mudar de projeto? Sair da empresa? Mudar de carreira? Ou aprender com os erros do passado e não cometê-los mais?
Todos devem entender bem o escopo do projeto de software
Quando um projeto de software é apresentado para uma equipe, nem sempre é explicado de maneira clara e objetiva que problema ele resolve, ou como ele irá resolver o problema.
“Aquilo que não é conhecido é temido“
Erra-se ao explicar o que o sistema vai fazer, mas sem dizer o porquê de fazer isso e como isso ajuda a resolver o problema no mundo real.
No projeto de software de um sistema, quanto mais estruturado e previsível for a informação melhor, porque é mais simples.
Mas no mundo real, os eventos e informações transitam de forma inesperada e não estruturada. Ou seja, trata-se de um ecossistema complexo.
Por isso é importante que a equipe entenda o que está sendo resolvido e como, para que possam criticar, sugerir e imaginar previamente os futuros gargalos os quais terão que enfrentar.
Isso evita montar, no início do projeto, estrutura de dados ou de relacionamento de classes que no meio do projeto precisará ser revisada, e que talvez se torne difícil.
Entretanto, se você não for o gerente do projeto e não contar com um líder que preze por essa comunicação clara no início, procure você mesmo questionar e pesquisar a documentação disponível para entender melhor o projeto de software.
Faça um MVP, depois melhore
Entregue primeiro um front-end navegável, com dados manipulados apenas no JavaScript do navegador.
Antes de seguir com estruturas de dados e classes, é preciso saber se, de fato, o que foi entendido é o que o cliente realmente queria ter comunicado.
Com um front-end navegável, o cliente poderá inclusive mudar de ideia no meio do processo.
Assim, muito esforço de desenvolvimento que poderia ter sido jogado fora foi poupado.
“O front-end é a linguagem universal de comunicação entre o fornecedor do sistema e o cliente, porque é simples, visível, palpável, é o exemplo mais próximo do mundo real”
Com um front-end feito, o cliente pode colocar o dedo na tela e dizer: “esse botão aqui eu queria desse outro lado, com essa outra cor, e com esse outro texto”.
Uma vez que o front-end foi validado, implemente no back-end.
Procure entregar uma versão executável do projeto de software, com as funcionalidades principais funcionando e regras de negócio mínimas para navegar.
Depois implemente as regras de negócio mais complexas e, por fim, as validações e regras de usabilidade.
Comece do todo para as partes
Quando for desenvolver um componente, seja uma classe ou uma funcionalidade, não tente implementar todas as boas práticas logo de início.
“Aprenda a fazer o “componente rascunho”, como se estivesse escrevendo uma ideia num guardanapo“
Parece um contrassenso, mas não é.
Primeiro faça uma classe geral, onde você consegue visualizar em um único lugar tudo o que aquele componente faz.
Assim, você consegue fazer um mapa de tópicos, saber como as peças se encaixam, categorizar essas peças e dar os devidos nomes a elas.
Depois consolide e melhore.
Distribua o código em classes menores, que representam etapas do processo, e em métodos, que representam os passos do processo.
Débito técnico ou sujeira embaixo do tapete
Rascunho não é igual a solução final pendente de revisão. Precisamos entender que um código com débito técnico alto não deve ser entregue.
Quero destacar dois grandes problemas com o débito técnico.
Comunicação ineficiente no projeto de software
Se uma classe, método ou função estiver mal escrita e mal comentada, é possível que até seu autor não consiga entender no futuro.
Ou se estiver muito grande e complexa, pode ficar impossível de fragmentá-la e torná-la mais simples.
Um projeto com o código não performático
Num rascunho, não tem problema fazer uma consulta a banco dentro de um laço ou repetição. Mas se isso for pra produção, pode demorar de ser detectado.
Se a baixa performance só acontecer em casos de registros com vários registros independentes e eles forem escassos, pode ser que os logs não deixem claro que a lentidão no sistema ocorreu por uma má implementação muito específica que foi feita às pressas.
Estabeleça prioridades
Alguns gerentes de projeto de software ou clientes costumam dizer que “tudo é prioridade“.
E ele pode estar certo. Mas nenhum ser humano faz tudo de uma vez ou ao mesmo tempo.
E existem passos que só podem ser entregues se passos anteriores forem concluídos.
Por isso, se você está num contexto em que o cliente ou gerente indicou mais de uma coisa como prioridade, faça a pergunta matadora:
“Se apenas uma única e última coisa pudesse ser feita agora, qual delas você escolheria?”
Não que as demais não serão feitas, mas existem momentos de pressão em que as pessoas não conseguem pensar de forma clara.
E você pode ajudá-las nesse momento.
Classes e métodos específicos e independentes
Às vezes, parece mais fácil escrever uma classe única que faça várias coisas, ou métodos genéricos com muitos parâmetros, autoajustável e “inteligente”.
Essa não é uma boa prática.
É melhor criar uma classe para cada coisa e um método para cada passo.
Prefira instanciar um objeto e chamar cinco métodos em sequência em vários lugares do que um único método, com passagem de vários argumentos.
Por exemplo, é melhor e mais simples chamar:
Às vezes, parece mais fácil escrever uma classe única que faça várias coisas, ou métodos genéricos com muitos parâmetros, autoajustável e “inteligente”.
Essa não é uma boa prática.
É melhor criar uma classe para cada coisa e um método para cada passo.
Prefira instanciar um objeto e chamar cinco métodos em sequência em vários lugares do que um único método, com passagem de vários argumentos.
Por exemplo, é melhor e mais simples chamar:
$carro = new Carro();
$carro->montarBaseCarro( ‘toyota’, ‘corolla’, ‘xei’ );
$carro->colocarBancos( ‘couro’ );
$carro->colocarPneus( ‘aro15’ );
$carro->colocarPortas( ‘com_friso’ );
$carro->pintar( ‘preto’ );
return $carro;
Do que usar a forma abaixo, mais complexa e obscura:
return new CarroCompleto( ‘toyota’, ‘corolla’, ‘xei’, ‘couro’, ‘aro15’, ‘com_friso’, ‘preto’ );
Primeiro faça funcionar, depois, se precisar, automatize
Ouvimos falar tanto no princípio DRY (Don´t Repeat Yourself), que achamos que tudo ou qualquer coisa pode ser componentizada ou automatizada.
Mas isso deve ser ponderado.
Quando um conjunto de chamadas acontece várias vezes, mas de forma muito variada ou com estruturas de inputs ou outputs muito variada, é melhor manter o bom e velho copiar e colar.
“Não adote acredite na universalidade de um princípio sem questionar o contexto específico onde ele será aplicado”
Pode ser muito custoso manter um processo automatizado, que somente um gênio da computação consiga dar manutenção, quando poderia ser resolvido de uma forma mais simples por qualquer programador iniciante.
Se realmente a automação ou componentização for estratégica para o negócio, deve ser feita por partes.
Primeiro automatizar as peças mais simples e previsíveis, testar e consolidar. Só depois, ir prosseguindo com evoluções incrementais.
A questão não é a tecnologia que você usa, mas como você usa a tecnologia
Às vezes surge uma tecnologia nova, com promessa de uma sintaxe mais enxuta, mais segura, mais performática ou mais elegante.
Então, a equipe cansada do feijão com arroz, decide que é hora de inovar.
Nova tecnologia é como andar do lado da porta do carro com vidro elétrico. Quando crianças, fazemos questão de sentar na janela. Mas quando amadurecemos, cedemos o lugar para as crianças.
Com o tempo, você percebe que não existe muita diferença entre as linguagens.
A lógica é a mesma, a semântica também, e os recursos são muito semelhantes. O que muda é a filosofia e a sintaxe.
Portanto, a melhor tecnologia a escolher é aquela que a equipe domina, que na hora da pressão, serão capazes de implementar a solução da forma correta.
Em vez de ficar investindo em conhecer novas e novas tecnologias, prefira evoluir!
Evolua! Você e sua equipe, em qualidade de código, melhorar a compreensão do negócio, melhorar a comunicação e aprender novos paradigmas na tecnologia que você já usa.
Aprenda a refatorar
Essa é a habilidade que considero mais importante.
Não gostamos de manter sistemas, muito menos criados por outras pessoas.
Às vezes, manter um código legado pode ser sinônimo de pesadelo.
Mas acredite, como programador, é isso que você fará a maior parte do tempo.
Pode parecer mais fácil criar um projeto do zero, um código novo.
Mas até quando você está criando um projeto do zero, você irá pressionar a tecla delete ou backspace várias vezes.
Então, sua capacidade de entregar resultados simples e rápido pode ser considerada diretamente proporcional à sua capacidade de refatoração.
“Quem refatora adquire experiência”
Quando você aprende a criar bifurcações nos códigos e caminhos paralelos que funcionam em harmonia, você consegue sair daqueles apertos que parecem intransponíveis ou que demandam muito tempo de um programador nível médio.
Pronto, seu projeto de software não vai ser o mesmo! E que bom 😀
No fim das contas, aprendemos que todo projeto de software, por mais simples que pareça, tem pelo menos um ou dois pontos de complexidade.
Por isso, aprender a resolver gargalos de maneira simples é o que diferencia o programador mediano do desenvolvedor profissional.
As sacadas acima podem não parecer grandes segredos à primeira vista. Mas com a prática e experiência, você verá uma grande diferença em seus resultados.
Espero ter te ajudado no seu crescimento profissional.
Você pode ver outras maneiras de como ser um bom programador e se desafiar em um novo emprego acessando a nossa página de vagas para programadores.
Até o próximo artigo.
