A forma como você programa faz toda a diferença!

25

Quando aprendemos a programar, toda nossa energia está focada em simplesmente fazer as coisas funcionarem.  Queremos entender como a máquina funciona, como a linguagem se comporta e como controlar o fluxo de execução do software.

É nessa fase que a gente aprende a lidar com o elemento mais frequente na programação: o erro! Pode ser um erro de digitação, uma lógica errada, uma contagem que escapa por 1, um arquivo que você esqueceu de adicionar…  As formas para algo dar errado são infinitas!

O processo de tentativa e erro é da natureza do aprendizado! 

Cada erro nos ajuda a aprender um pouco mais. Com a prática, os erros simples vão ficando menos frequentes, dando espaço para questões mais sofisticadas.

Por isso, quando desenvolvemos software profissionalmente é muito importante ter a consciência que erros sempre acontecerão. O nosso grande desafio como programadores é administrar o risco e o impacto destes erros.

Na realidade, a interação entre o programador e um código é um erro em potencial. Quando só você usa o software, o erro tem baixo impacto. Mas quando se trata de um software em produção que serve vários usuários, o impacto pode ser catastrófico.

ansiedade frente ao erro. Post: A forma como você programa faz toda a diferença

 

Mas como minimizar os riscos e aprimorar a minha forma de desenvolver software?

Para que você possa ter muito mais confiança na solução que entrega eu recomendo o TDD. O Desenvolvimento Guiado por Testes  ou Test Driven Development (TDD) é a técnica que eu mais uso e que mais me ajuda a programar sem perder de vista o que eu preciso entregar.

TDD  é uma técnica de design de código que te ajuda a administrar e reduzir os riscos do processo de programação. Ao escrever os testes primeiro e evoluir o código teste por teste você evita que o processo de desenvolvimento vire um caos. Assim você se mantém sempre confiante em evoluir o código, sem medo de mexer aqui e quebrar lá do outro lado.

O processo de TDD se baseia em você definir o input e output do seu código antes de se preocupar com o processamento que levará de um estado ao outro. Desta forma, eu começo do mais simples ao mais complicado, aumentando gradualmente a capacidade do meu software realizar a tarefa.

Quando eu escrevo os testes primeiro, eu expresso um código que diz: Rode o processamento X com o input Y e o resultado será o output Z. Se não for, tá errado!

O detalhe é que fazemos isso antes mesmo de criar o processamento X, seja ele uma função, um método de uma classe, ou qualquer outra construção. Eu defino concretamente a expectativa e a interface do que eu ainda vou implementar.

Se você nunca viu isso acontecendo na prática, no vídeo abaixo eu demonstro a construção de um programa utilizando esta técnica. Eu gravei esse vídeo como um exercício pedagógico quando eu estava pesquisando as melhores abordagens para projetar o Welcome to the Django.

 

 

Eu sempre falo sobre estes assuntos em palestras, hacktalks, vídeos curtos no #PapoRápido, nas redes sociais e principalmente, no curso Welcome to the Django. Então, se você tiver alguma sugestão, ficou com alguma dúvida ou discorda completamente do que eu disse, é só chamar ai nos comentários e vamos batendo um papo.

O risco é não interagir!

Abração, HB!


As matrículas para o Welcome to the Django estão oficialmente abertas!!! Junte-se aos milhares de profissionais que estão conquistando seus espaços no mercado de TI!

Garanta a sua vaga: ⤵️

Matriculas Abertas para o welcome to the django

 

você pode gostar também
25 comentários
  1. Evelin Laureane Diz

    Gostei muito desse post!

  2. Washington Junior Diz

    O Titulo Já Diz Tudo! Adorei o Artigo! Parabéns!!

    1. Henrique Bastos Diz

      Maneiro que vc curtiu, @disqus_5jx5z4thX8:disqus! 😉

  3. Silas Vasconcelos Diz

    Muito massa, parabéns Henrique.

    1. Henrique Bastos Diz

      Valeu mesmo @silasvasconcelos:disqus! 🙂

  4. Silas Vasconcelos Diz

    Muito massa, parabéns Henrique.

    1. Henrique Bastos Diz

      Valeu mesmo @silasvasconcelos:disqus! 🙂

  5. Gustavo Moreira da Fonseca Diz

    Muito bom artigo e excelente vídeo. Sua didática é muito boa.

    1. Henrique Bastos Diz

      Valeu @gustavomoreiradafonseca:disqus! Fico feliz que vc curtiu!

  6. Gustavo Moreira da Fonseca Diz

    Muito bom artigo e excelente vídeo. Sua didática é muito boa.

    1. Henrique Bastos Diz

      Valeu @gustavomoreiradafonseca:disqus! Fico feliz que vc curtiu!

  7. Gustavo Coelho Diz

    Baby steps e teste… Excelente dica!

    1. Henrique Bastos Diz

      Quando essas 2 técnicas são integradas… muda tudo. 😀

  8. Bruno Barbosa Diz

    Desenvolver software é uma atividade prazerosa e divertida para quem ama o que faz. Mas quando o software atinge um certo grau de maturidade e ele não possui testes as mudanças ficam cada vez mais difíceis e o trabalho começa a ficar “chato”…

    Já trabalhei em projetos enormes de grandes clientes onde havia passado por lá vários desenvolvedores e um dos maiores problemas que enfrentávamos era quando havia uma mudança em determinada parte do sistema que quebrava uma outra parte que aparentemente não tinha relação entre elas… Com certeza com testes automatizados esse tipo de problema seria bem menos frequente.

    Não utilizar TDD em software é como programar uma bomba relógio.. Em algum momento haverá mudanças, e sempre há, e quando você o fizer o software vai quebrar em algum lugar, isso é fato, faz parte do processo de desenvolvimento. Quando você tem testes, conseguimos identificar essas “quebras” antes do software ir para produção reduzindo conflitos que poderiam ser causados com a insatisfação do cliente com esses bugs.

    Eu amo programar, mas não sabia o que estava acontecendo pois de alguma forma estava perdendo o “tesão” pela arte… Então descobri no WTTD que meu problema era a não utilização de testes. A manutenção de software pode ser tão divertida quanto desenvolver novas funcionalidades, desde que aja testes para que você possa fazê-la com mais confiança e utilizar o tempo que seria gasto na resolução de bugs com outras atividades que gerem mais valor para o cliente. =)

    1. Henrique Bastos Diz

      Sensacional, Bruno! Foi exatamente essa sua fala que me inspirou a escrever esse artigo. 😀 Happy hacking!

  9. Bruno Barbosa Diz

    Desenvolver software é uma atividade prazerosa e divertida para quem ama o que faz. Mas quando o software atinge um certo grau de maturidade e ele não possui testes as mudanças ficam cada vez mais difíceis e o trabalho começa a ficar “chato”…

    Já trabalhei em projetos enormes de grandes clientes onde havia passado por lá vários desenvolvedores e um dos maiores problemas que enfrentávamos era quando havia uma mudança em determinada parte do sistema que quebrava uma outra parte que aparentemente não tinha relação entre elas… Com certeza com testes automatizados esse tipo de problema seria bem menos frequente.

    Não utilizar TDD em software é como programar uma bomba relógio.. Em algum momento haverá mudanças, e sempre há, e quando você o fizer o software vai quebrar em algum lugar, isso é fato, faz parte do processo de desenvolvimento. Quando você tem testes, conseguimos identificar essas “quebras” antes do software ir para produção reduzindo conflitos que poderiam ser causados com a insatisfação do cliente com esses bugs.

    Eu amo programar, mas não sabia o que estava acontecendo pois de alguma forma estava perdendo o “tesão” pela arte… Então descobri no WTTD que meu problema era a não utilização de testes. A manutenção de software pode ser tão divertida quanto desenvolver novas funcionalidades, desde que aja testes para que você possa fazê-la com mais confiança e utilizar o tempo que seria gasto na resolução de bugs com outras atividades que gerem mais valor para o cliente. =)

    1. Henrique Bastos Diz

      Sensacional, Bruno! Foi exatamente essa sua fala que me inspirou a escrever esse artigo. 😀 Happy hacking!

  10. Régis Silva Diz

    … e mais? Quem não vê acha que não precisa, mas se aparecer um bug o problema é de quem?

    1. Henrique Bastos Diz

      Tem isso. É daí que vem aumento de “demanda de falha” que invariavelmente inunda o projeto matando-o por dentro.

  11. Régis Silva Diz

    … e mais? Quem não vê acha que não precisa, mas se aparecer um bug o problema é de quem?

    1. Henrique Bastos Diz

      Tem isso. É daí que vem aumento de “demanda de falha” que invariavelmente inunda o projeto matando-o por dentro.

  12. Régis Silva Diz

    TDD é tão importante quanto a fundação de um prédio. Ninguém vê mas ela está lá.

    1. Henrique Bastos Diz

      🙂

  13. Régis Silva Diz

    TDD é tão importante quanto a fundação de um prédio. Ninguém vê mas ela está lá.

    1. Henrique Bastos Diz

      🙂

Deixe uma resposta

Seu endereço de email não será publicado.