Um dia de trabalho comum como Programador

Quer saber como é o dia a dia de um programador? Quais ferramentas usamos? Como são os projetos? Acompanhe este artigo e descubra isso e muito mais!

Trabalho como programador .NET em uma empresa pequena que fabrica um sistema de eLearning para empresas e, apesar de não trabalhar com games diretamente, o dia de um programador não muda muito. Em ambos os trabalhos haverão conquistas, frustrações, clientes, projetos e isso não muda muito.

Conheça mais do meu dia como programadora abaixo!

Meu dia como programador

Meu dia não começa sem uma boa xícara de café. Apesar de não ser uma regra, boa parte dos programadores são movidos a café e eu não sou uma exceção!

Após meu café diário, ligo minha máquina mentira, ela fica sempre ligada e olho na minha lista de atividades o que tem pra hoje. A lista de atividades é definida através de um processo chamado Scrum. Você pode saber mais sobre o processo aqui: Artigo: SCRUM como Metodologia Ágil na Produção de Jogos Digitais.

Após verificar minhas atividades, temos uma pequena reunião diária onde toda a equipe responde o que fez no dia anterior, o que vai fazer hoje e se há algo te impedindo. Após isto é que a programação de fato começa.

Programando

Programar em um dia pode ser uma tarefa extremamente empolgante num momento, mas extremamente entediante em outros. Existem diferentes tipos de atividades que um programador pode fazer, como por exemplo: manutenção de código existente, criação de ferramentas novas, criação de formulários, etc. O que eu mais gosto é a criação de ferramentas, pois me faz aprender coisas novas e manutenção de código existente, pois tenho que investigar, otimizar código e corrigir problemas. Por sinal, se você tiver a oportunidade de escolher por onde começar, a manutenção de código é uma boa pedida, pois você aprende com o código dos outros e já vai vendo que tipo de problemas esperar.

E claro, sempre temos aquele momento de raiva porque você passou as últimas três horas sem saber o porquê que o código não funciona e aí percebe que tinha que ter usado uma letra maiúscula ao invés de minúscula. JavaScript, estou falando de você!

Levantamento de Requisitos

Outra atividade do meu dia é levantar quais os requisitos da funcionalidade que eu estou escrevendo. Geralmente os requisitos estão definidos nos PBIs (Product Backlog Items), mas quase sempre ao desenvolver a atividade, são identificados alguns cenários que não foram considerados durante o desenvolvimento do PBI. Neste caso temos duas opções: alterar o PBI e desenvolver a mudança ou, caso seja algo muito grande, criar um novo PBI que será desenvolvido no próximo sprint.

Apresentando a funcionalidade para a equipe

Antes de enviar a funcionalidade para a etapa de testes, nós fazemos uma apresentação prévia entre os desenvolvedores onde explicamos como a funcionalidade foi feita e se alguém tem alguma sugestão. Essa etapa possui discussões calorosas e aqui é que a sua habilidade de trabalho em equipe é posta à prova. Você tem que saber negociar e aceitar quando a decisão da equipe é diferente da sua.

Tudo lindo!

As mudanças foram feitas! Tudo o que eu tenho que fazer é disponibilizar o meu código para a equipe de teste. Para isso usamos o Visual Studio Online, em que estão todas as versões do código. Eu como desenvolvedor preciso executar o comando Check In para que o meu código seja subido para o servidor e os outros membros do time tenham acesso a ele. Pode ocorrer alguns conflitos de versão, caso alguém tenha feito alguma mudança no mesmo arquivo que você. Nesse caso, você tem que comparar as duas versões e ir marcando qual é a linha do código correta. É mais fácil do que parece, e muitas vezes o próprio Visual Studio consegue identificar qual é a informação correta automaticamente.

Erro!

Ah os erros! Depois de tudo isso, sua aplicação perfeita vai para a fase de testes e deixa de ser tão perfeita. A dica aqui é não se apegar ao código, por que vão achar problemas e falhas na sua lógica. É normal e faz parte do processo! Para minimizar os erros nós fazemos os chamados Testes Unitários que testam cada função do sistema independentemente. Toda vez que fazemos check in de um código, todos os testes rodam e se alguma coisa quebrou você tem que consertar.

Fim do dia

Fim do dia, tudo lindo, aplicação funcionando, testes realizados, atividade marcada como completa! Tudo o que eu quero é um bom banho e uma boa noite de sono! Aí você tá lá no banho e pá! Vem aquela inspiração para resolver algum problema ou você pensou numa situação que pode quebrar o sistema! Lá se vai a noite de sono já que você vai ficar preocupado por alguém conseguir achar o problema antes de você. 🙂

Podem rir, mas isso acontece com mais frequência do que vocês imaginam.

 

Mas é isso, pessoal! Uma versão resumida do meu dia em geral! Se vocês gostaram, comentem aí! Quem sabe escrevo um relato sobre o Sprint todo!

Abraços e até mais!