6 regras para ser um desenvolvedor de software melhor!

0
236

Vou ser brutalmente honesto com você, há uns quadro ou cinco anos… Eu me considerava um desenvolvedor médio, na melhor das hipóteses. Não me interprete mal…

Eu ainda poderia codificar, corrigir bugs surgidos, implementar novas características, mas à medida que o tempo passava, os bugs antigos continuavam reaparecendo.

A Refatoração regular tornou-se irritante e demorado, assim, os custos do projeto só aumentava.

Eu sabia que tinha que mudar algo sobre minha estrutura de trabalho e meus hábitos diários de trabalho.

Admitindo que há um problema!

A primeira regra da solução de problemas é conhecer o problema que você precisa resolver …

Levei um tempo para colocar meu ego de lado, admitir o problema e a partir daí foi apenas uma questão de tempo até que eu tenha visto RESULTADOS REAIS!
Se você tem passado por isso, então este artigo é feito para VOCÊ!

1 – Diagnóstico antes da solução

Isto deve ser auto-explicativo, mas eu mesmo o ignorei por um tempo.

Acho muito valioso a importância de investir tempo para entender o problema/bug antes de codificar.

Certifique-se de passar um tempo em:

  • Compreender o problema.
  • Reproduzir o bug, e saber sob quais condições este bug é reproduzível e quando não é.
  • Construa um fluxograma de sua possível solução.
  • Discuta-o com um(s) colega(s) relatável(eis), se possível, isso pode economizar muito tempo na fase de revisão do código.

2 – Facilite a manutenção

Honestamente falando, eu peguei este mau hábito de ignorar a capacidade de manutenção durante meu tempo de estudante.

Como estudante, sempre trabalhei em projetos de fase curta, onde você tem um problema e entrega uma solução. BINGO, você já passou neste curso! Em outras palavras, meu objetivo era apenas provar que posso resolver um problema!

Leia também:  Google coloca sensores de qualidade do ar em seus carros do Street View

Com o passar do tempo percebi que não funciona assim na indústria tecnológica.
O trabalho não termina com o simples lançamento de um produto, a Manutenção de Longo Prazo está esperando por você!

Você tem que pensar :

  • Sua implementação depende do tempo? (Adicionar mais código pode mudar o tempo, então vá para a implementação orientada por eventos)
  • Sua implementação está tendo alguma dependência de Classe/Função? (sua implementação pode não funcionar como esperado se alguma dependência for alterada)
  • Esta Classe ou Funcionalidade será expandida em um ponto? Quão difícil será expandi-la?

3 – Priorizar a legibilidade / Codificação limpa

Vivemos em um mundo onde quase todos são substituíveis, facilite a leitura de seu código para seus futuros novos colegas e entenda bem rápido!

Basta seguir as diretrizes do código de sua empresa, se ele existir. Não conheço um único desenvolvedor que tenha lido o Código Limpo e não o tenha recomendado publicamente!

4 – Continue aprendendo

Ok, trabalhamos na indústria de tecnologia e a cada ano surge uma nova tecnologia/distribuição. Não aprenda para sua tarefa de curto prazo, aprenda para sua carreira!

5 – Documentação

Seguindo o ponto de legibilidade mencionado anteriormente, a Documentação é uma parte essencial de seu trabalho diário!

A documentação pode ser dividida em 3 categorias principais:

  • Protocolos de documentação, métodos de encriptação/descriptação … etc.
  • Documentação de casos de usuários (de preferência utilizando fluxogramas)
  • Documentação Para desenvolvedores (por exemplo, Diagramas de Classe usando o Gerador de Documentos de Código Fonte)

6 – TDD (Desenvolvimento Orientado a Testes)

Você não pode fornecer um código de software de qualidade sem garantir que ele seja bem testado. Apesar de muitas empresas ainda não utilizarem técnicas de teste de software para o desenvolvimento dos seus produtos, alegando o atraso, o tempo ou o custo para esta tarefa, as pesquisas indicam que os testes ajudam na garantia de qualidade do software.

Leia também:  Como construir Super Mario Bros com JavaScript e Kaboom.js

Vamos a outra realidade, imagine você adquirindo um carro, que foi projetado, montado, mas sem ser testado, pois os testes sairiam muito caro, e de repente você está andando e nota que na curva o carro não é eficiente. Você ficaria contente com esta situação? O mesmo acontece com o cliente de um software ao adquirir um produto que não funciona adequadamente.

LEAVE A REPLY

Please enter your comment!
Please enter your name here