Programação e escalada

Recentemente, para fugir um pouco da frente da tela dos computadores, fiz um pequeno curso introdutório de escalada em rocha. Apesar de ser uma atividade bastante física, requer também bastante concentração e conhecimento de diversas técnicas que permitem a realização da prática.

Algumas dessas técnicas e práticas acabaram me lembrando de conceitos e técnicas que utilizamos também no desenvolvimento de Software, e que eu vejo que se tornam cada vez mais importantes.

Double-check

Equipamentos

Antes de qualquer escalada, o passo mais importante é checar novamente todo seu equipamento. Por mais experiente que você seja, revisar todos os nós, peças e equipamentos é extremamente essencial, para evitar que no meio de uma escalada algum imprevisto aconteça.

No desenvolvimento de software precisamos ter o mesmo cuidado. Técnicas como code-review, testes automatizados e testes manuais são muito importantes antes da liberação de novas versões de um software.

Por mais experiente que você seja, vícios de desenvolvimento, ou mesmo interpretações diferentes de regras de negócio podem ser detectadas por outros desenvolvedores ao revisar o seu código, ou em fases de testes. Uma dupla checagem permite detectar falhas, antes que um imprevisto aconteça em ambiente de produção, por isso essas técnicas têm a sua importância no fluxo do desenvolvimento.

Diferentes rotas

Ao escalar uma montanha, é comum que existam diversas rotas diferentes. Pontos de apoio e lugares para se segurar podem estar em qualquer lugar de uma montanha, por isso, quando a dificuldade bate, diferentes caminhos devem ser tentados. Nem sempre o caminho mais rápido é o mais fácil, e nem sempre o mais fácil é o mais curto.

Ao programar chegamos às vezes na mesma situação. Para resolver um problema podem existir diversas formas. Nem sempre a mais fácil vai ser a mais rápida, e nem sempre a mais complexa vai ser a melhor. Ao desenvolver software precisamos sempre pensar no resultado, mas também no código que teremos para cuidar no futuro.

Ao criar um código precisamos procurar uma rota que traga um código limpo para o próximo desenvolvedor que irá olhá-lo, mas também que vai trazer um bom resultado para o usuário que irá utilizar o programa.

Redundância

Redundância

Ficar pendurado por uma corda em um penhasco pode parecer algo pouco seguro (e de certa forma é), por isso, na escalada a redundância de segurança é sempre importante.

Ao realizar uma escalada é essencial estarmos amarrado a mais de um ponto fixo, em alguns momentos ter mais de um nó fazendo a sua segurança e utilizar equipamentos que aguentem muito mais do que eles realmente serão forçados a aguentar. Falhas podem acontecer durante a escalada, e estando amarrado a mais um ponto fixo podem evitar uma tragédia, e garantir que você tenha tempo de se colocar em um ponto seguro novamente.

No desenvolvimento de software não é diferente. Mesmo com diferentes técnicas para evitar problemas, acidentes ainda podem ocorrer, por isso uma redundância de servidores, mais de um backup de seu banco e revisão extra de sua infraestrutura podem ajudar a evitar uma tragédia quando algum incidente acontecer.

Trabalho em equipe

Trabalho em equipe

Você pode até conseguir escalar sozinho, mas trabalhando em equipe você provavelmente conseguira ter mais sucesso.

Tanto na escalada quando na programação, um colega pode te ajudar a ter segurança no que você está fazendo, indicar caminhos diferentes para seus desafios e te impulsionar a chegar no resultado que você deseja.

Conclusão

Por mais que sejam áreas totalmente diferentes, conseguimos ver que podemos aprender algo sobre desenvolvimento de software praticando escalada, além de ser uma atividade física te dará mais disposição para voltar para o computador.

Importante lembrar que não sou nenhum especialista em escaladas, e as ideias que falei aqui foram apenas alguns pontos do conhecimento que adquiri após um pequeno curso introdutório. Para conhecer mais sobre escaladas, recomendo que você também faça uma prática. Tenho certeza que irá gostar.