Erros que fazem com que sua aplicação não rode “de primeira”.

Published in

devorando

8 min readMay 22, 2020

Assim como a reação da Nazaré (imagem acima), você já parou pra pensar o motivo da sua aplicação não funcionar no primeiro momento? “Poxa, mas eu programei tudo certinho, apliquei Clean Code, princípios SOLID, segui as guidelines e mesmo assim, quando fui executar a aplicação, tomei logo um erro!”.

Calma aí meu camarada, não precisa entrar em pânico e se justificar com tantas palavras bonitas, pois essa situação é super comum! O X da questão é: quantas vezes você vai ter que arrumar seu código para a aplicação ser executada corretamente?

Fala meu consagrado, bão? Meu nome é Lucas Villa Verde, sou desenvolvedor FullStack aqui no aiqfome e hoje vou te ajudar a identificar os 3 principais erros que podem fazer com que você quebre a cabeça vasculhando e arrumando seu código. Bora então?

Todos temos que seguir cronogramas e entregar projetos nos prazos que foram definidos, por isso buscamos aplicar nosso conhecimento pra fazer com que o produto seja o mais perfeito possível. Porém, muitas vezes acabamos fazendo mais que o necessário e deixando lixo no código. Sabe aquela funçãozinha pra “caso o usuário digitar” ou “é adaptável e pode ser reutilizada no futuro”… Cuidado! Um dos seus erros pode ser…

Over-engineering (Super-engenharia ou sobre-engenharia)

Ato de projetar um produto para ser mais robusto ou ter mais recursos do que o necessário para o uso pretendido ou para que um processo seja desnecessariamente complexo ou ineficiente.

https://holyhash.com/691/over-engineering/

Sempre que estiver com dúvida se deve ou não criar uma funcionalidade adicional, se pergunte: É realmente necessário?

Vejamos um exemplo de forma bem simples:

A função AdicionarTaxaPreco receberá um valor que sempre retornaremos convertido para float. Sendo assim, poderíamos ter o seguinte código:

A função ConverterParaFloat foi criada para CASO o valor já for numérico ele retornará o próprio valor, assim, economizando processamento da máquina e aumentando o rendimento da aplicação.

Essa funcionalidade é um exemplo de overengineering, uma funcionalidade implantada além do necessário e que terá um baixíssimo impacto final em relação ao desempenho.

Então, sempre que alguém te perguntar o motivo de ter criado uma funcionalidade, pense bem antes de utilizar as palavras CASO ou PODE SER QUE para justificar uma funcionalidade. Se você precisa justificar, é provável que essa funcionalidade será desnecessária ou pouco utilizada.

Algumas dicas para prevenir over-engineering:

Comece sempre pensando em fazer o MVP da tarefa apresentada, uma coisa de cada vez, até a funcionalidade principal cumprir o que foi planejado, o famoso: “testar o fluxo perfeito”.
Não é possível saber tudo e nem imaginar tudo, então pergunte ao seu time ou ao responsável pela criação da tarefa as possíveis variações de fluxos que poderão ocorrer e tente aplicar a solução de forma objetiva no código;
Rendimento e maleabilidade da funcionalidade são coisas relativas. Saiba analisar o ambiente, situação e escala que será implantada sua aplicação.
Aqui no aiqfome, utilizamos o code review, onde cada desenvolvedor analisa o código da demanda que será implementada e pode apontar possíveis correções a serem feitas (o pessoal não deixa passar nada em branco).

Falando um pouco de personalidade…

ser dev. é meio solitário às vezes, não é, minha filha?

Várias vezes nos vemos sozinhos, com várias tarefas a serem realizadas, descrições complexas, algoritmos que irão impactar diretamente o futuro da empresa… É nessa hora que se respira fundo, bota o foninho e #partiucodar. Porém, devemos tomar cuidado com todo este “poder” que temos em nossas mãos para não abusar na hora de escrever o código.

Programar de forma individualista, achando que tudo irá funcionar como o esperado e que todos irão gostar só porque é você que está realizando a demanda e porque acha que sabe como funciona todo o fluxo apresentado pode contribuir (e muito) para uma coisa que eu carinhosamente defino como…

Freedomcoding

Programar de forma livre e individual, não compartilhando o conhecimento com a equipe, aplicando apenas os seus padrões e deixando, assim, um código mais desconexo e cheio de peculiaridades que só você vai entender.

O freedomcoding pode te iludir com a impressão de que tudo está fluindo de forma correta, mas ele implica em diversas más práticas:

Não padronização do código;
Ausência de comentários;
Ausência de logs;
Funcionalidades que fogem do princípio de responsabilidade única;
Hard code, o famoso “por as coisas na mão”. Números, variáveis, constantes e estruturas condicionais surgindo do meio do nada (o famoso código mestre dos magos).

É claro que com tantas más práticas a aplicação não funcionará ou não terá o comportamento esperado.

Segue então algumas dicas de como evitar entrar no ambiente de freedomcoding:

Siga um padrão em seus projetos. Seja o que o time estabeleceu ou um padrão próprio, se for um projeto pessoal. Isso acelera o processo de interpretação, correção e elaboração do código, já que nosso cérebro segue padrões no dia a dia e desenvolver faz parte do nosso dia (e manhã, noite, madrugada…);
Compartilhe seu conhecimento e esteja aberto para informações de outras pessoas. Sendo mais solidário e tendo a mente aberta, você terá mais experiência para reconhecer se uma funcionalidade, padrão, arquitetura do software é viável ou não;
Lembre-se que você está desenvolvendo um produto para alguém, então você não está sozinho nessa! Pense se o cliente irá receber um produto de qualidade, afinal, é a sua personalidade e reputação que estão sendo aplicadas nele;
No aiqfome, realizamos reuniões diárias de alinhamento. Assim, todos ficam informados sobre mudança de padrões, problemas, novas funcionalidades, novidades nas tecnologias, prazos estipulados… Tendo uma visão geral do andamento do projeto;

Você pode ser livre, mas programe consciente!

Ah… E quando por um deslize, você esquecia um ponto e vírgula e passava horas e horas tentando achar onde estava o erro?

Hoje em dia, o ponto e vírgula já não é mais um problema tão comum (grande abraço para Javascript e Python), mas com certeza uma sintaxe mal elaborada pode acarretar em sérios problemas para sua aplicação. Além de a aplicação não rodar, você pode estar executando funcionalidades de maneira totalmente diferente do esperado porque inverteu variáveis, passou parâmetros errados, realizou má indentação, dentre outros problemas. É por isso que devemos sempre estar atentos aos…

Detalhes

Atenção aos detalhes, sejam eles de lógica, indentação, sintaxe, regras de negócio, arquitetura da aplicação, versionamento…

Vamos a algumas dicas que podem fazer com que você preste mais atenção nos detalhes do seu código e consiga rodar tudo “de primeira”!

Sempre que possível, aplique TDD.

Imagine um cenário em que você poderia saber exatamente onde está o erro de seu código/funcionalidade? Isso é realidade faz tempo.

Com a inserção de testes, é possível mapear exatamente o comportamento de sua aplicação. Sempre que uma funcionalidade nova for implementada, os testes fazem todo o trabalho de simular o fluxo e funcionamento da aplicação, para que assim, você se sinta mais seguro antes de realizar qualquer deploy.

Dentre os testes mais comuns, estão:

Teste unitário: é referente a menor parte testável do seu código, ou seja, uma única função/funcionalidade;
Teste de integração: onde são combinados vários módulos de funcionalidades para mapear o fluxo até chegar em um resultado esperado;
Teste de sistema: como o próprio nome já indica, é responsável por abranger a aplicação como um todo, todas as integrações devem ser testadas de forma mais fiel possível como se estivesse em um ambiente de produção.

O nosso amigo Pedro Matias de Araújo escreveu um artigo super interessante sobre testes! Se quiser dar uma olhada, segue o link: Good test vs. bad test, como identificar?

Faça um bom versionamento do código

É importante dividir bem a criação de cada funcionalidade para uma melhor organização do código.

Algumas plataformas que podem te ajudar com isso são o Github e BitBucket.

Quando for realizar o versionamento do código, procure seguir os seguintes princípios:

Realize pequenos commits de implementações objetivas;
Nunca descreva um Pull Request de forma genérica, seja preciso na funcionalidade criada;
Verifique se você está up to date em relação a sua aplicação, pode ser que alguém tenha feito alterações e você ainda não sincronizou com o repositório.

Tenha certeza de que está usando a melhor IDE

Imagine que a construção do código é como uma corrida. Para vencê-la, não basta apenas ser rápido, você tem que manter uma boa precisão nas curvas, boa estabilidade e evitar ao máximo parar para manutenções.

Visto isso, você precisa de um carro que atenda todos estes requisitos e que não te deixe na mão. Tudo bem correr com um Fiat 147 (sem nenhum preconceito), você pode até conseguir finalizar a corrida, mas pode ter certeza que vai ter que parar várias vezes no meio do caminho.

Sua IDE é o seu carro! Tenha sempre em mente que utilizar o melhor carro é garantir uma corrida de sucesso. Leve em consideração: desempenho, preenchimento automático de código, design/layout (sim, isso influencia na hora de utilizar uma IDE), integrações/plugins disponíveis e popularidade na comunidade (quanto mais gente usa, mais confiável é.).

Segue alguns links pra te ajudar na escolha da melhor IDE de acordo com o que você precisa:

Sempre utilize um linter

Um linter ou lint é uma ferramenta de análise estática de código. Um linter ou lint se refere a ferramentas que analisam código-fonte para acusar erros de programação, bugs, erros estilísticos, e construções suspeitas.

Segue uma lista de linters das principais linguagens:

Javascript: ESLint;
Python: Black (indicado pelo ilustríssimo Pedro Matias de Araújo, vulgo “Python Matias”);
C#: Lint do VSCode e do Visual Studio são mais que suficientes;
PHP: PHP-CS (indicado pelo ilustríssimo Gianluca Bine, vulgo “mago do PHP”);

Caramba! É tanta coisa que temos que nos preocupar, como lembrar de tudo isso?

Na realidade, tudo faz parte da rotina e de como você aplica os melhores conceitos. Aos poucos, você vai percebendo que está evoluindo e utilizando os melhores métodos de forma natural.

E aí, será que você vai conseguir fazer com que seu código rode “de primeira”? Depois de tudo isso, tenho certeza que sim!