Herberth Amaral

Parabéns! Você trabalhou de uma forma tão impressionantemente dura durante os últimos sete meses e meio neste projeto. Você atendeu à todas demandas do cliente que vieram. Você completou o projeto no prazo e dentro do orçamento de $30,000, economizando $2000. O cliente está muito satisfeito por isso. Você pode dizer isso pelos sinais de dólar nos olhos dele. O cliente também está satisfeito pois ele foi capaz de colocar o Website no ar para o mundo para crescer e conquista-lo, o website já tem alguns usuários vindos dos convites beta que você mandou no início da semana. Você ainda mantém contato com o cliente quase todo dia. Ele diz que o site está indo muito bem.

Mas.

Há um usuário que está reportando uma falha com uma funcionalidade que você implementou há três meses. O cliente configurou seu email para receber relatórios de bugs. Você os recebeu pouco tempo depois que o usuário mandou. Uma páginas está mostrando “Desculpe-nos mas algumas coisa deu errada”.

Uh oh.

Você entra no website e checa você mesmo. Certo o suficiente que a página está dando erro 500. Mas por quê? Essa funcionalidade foi concluída três meses atrás e funcionou bem, não foi? Você testou na sua máquina local e viu que talvez fosse algo simples. Talvez uma variável digitada incorretamente no controller. Ou talvez não. Talvez isso vai levar mais de dois segundos seus para identificar o problema. Talvez leve uma hora, um dia.

Uma semana.

Então como esse erro pode existir? Você escreveu testes, né?

Oh, eu entendo.

Por causa da deadline iminente você estava pressionado pelo tempo e não se incomodou em aprender nenhum dos frameworks de testes. Você quis aprender. Muitas pessoas falam sobre testes com uma atitude positiva… foi só você que não teve tempo. Quando você fala sobre o assunto, seu chefe diz “o cliente não está pagando para você escrever testes, ele está pagando para você escrever funcionalidades”. Mesmo seu conhecimento sobre Rails cresceu três ou quatro vezes, comparado com o que era antes, durante a vida deste projeto, você ainda não sabe merda nenhuma sobre testes. Talvez seja hora de aprender, você pensa. Ah, mas O Chefe não quer que você gaste seu tempo em coisas que não produzem funcionalidades. “Testes são um desperdício do dinheiro do cliente”, ele diz. Você suspira. “Eu irei fazer melhor no próximo projeto. Eu irei fazer com que ele veja a luz. Eu irei fazer testes de verdade…”, você diz na sua cabeça. Ok, então você não escreveu os testes.

Então aqui vão os fatos:

Há um bug.
Você trabalhou nele no passado.
Você precisa conserta-lo. Agora.
Então como você debuga este bug para garantir que ele não aconteça denovo? Bem, você o conserta e sabe que ele não irá acontecer denovo, certo? Você deixará um comentário decente (na verdade, você irá pensar em deixar um comentário decente) depois que estiver consertado, para que ninguem passe pelo mesmo erro. Certo?

Errado.

Tudo bem, então você sabe que está em algum lugar do passado. Você pode ver a lista de branches e talvez algum dispare um gatilho na sua memória, e você tem certeza que tem branches com nomes memoráveis?

Ah sim, branching no SVN é um pé no saco. Eu concordo. Se você pudesse ao menos convencer seu chefe a usar Git também. Branching no Git é muito mais legal. Talvez você fará que ele “veja a luz” sobre isso no próximo projeto também. Então todas as modificações são no trunk, e navegar regressivamente sobre ele vai, claro, levar bastante tempo. Boa sorte com isso.

Então vamos assumir que você passa pelo trunk. Você se lembra da revisão e conserta o bug. Feito. Morto. Destruído. Vencido. Manda para as profundezas do inferno com um oitavo da sua sanidade. Isso foi um pouco duro. Você escreve um teste de regressão para ter certeza que não irá acontecer denovo, certo?

Oh, eu entendo.

Você comentou no item a fazer do Basecamp dizendo que foi consertado. Eu acho que é um nome procurável, certo? Somente no caso de acontecer denovo. É chamado de “alguma coisa deu errdo” ou “A página está quebrada”?

Uh oh.

Então você vai pra casa, satisfeito que você deu um pé na bunda de um bug que esteve na sua mente por dias. Você venceu.

Parabéns.

Você acorda no dia seguinte, pega seu café/leite/suco de laranja e checa seus emails. Há três do facebook, uns dois de algumas listas de email que você está inscrito e catorze do seu cliente. Esses emails não são catorze cartas de amor. Você vê que o primeiro foi enviado para você 20 minutos depois que você foi pra cama. Se você pelo menos ficasse ficado até tarde…

Você lê o primeiro. É um relatório de erro. O próximo também. E o próximo depois desse também. E adivinha? O próximo também.

Todos os catorze emails que seu cliente enviou a você tarde da noite não foram “Obrigado por seu trabalho fabuloso no site”, eles tinham o linguajar parecido com “Por que essa merda está dando pau?”. Ele acha pagou uma boa grana nisso. Você está feliz sendo pago o quanto que você ganha. De qualquer forma, não faz muito tempo que você está fazendo isso e você tinha que iniciar de algum lugar. As pessoas cometem erros, né?

Parabéns.

Agora você tem alguns relatórios de bugs para lidar quando você chegar no trabalho pela manhã. Oito horas por dia, sendo que cada bug leva uns 30 minutos para consertar. Fácil, com tempo de sobra. “Pfft. Faço até o fim do dia”, você pensa. Você percebe que um dos relatórios de bug que foi enviado foi um bug que você consertou outro dia. Outro desenvolvedor trabalhando no seu projeto teve um conflito com o arquivo e acidentalmente colocou o código quebrado ao invés do código que estava funcionando. Ok, tudo bem. Você conserta denovo. Talvez você não tenha escrito aquele comentário e você irá inseri-lo aogra. Beleza, isso irá fazer com que eles parem de introduzir o bug denovo.

Há uma reunião de duas horas com outro cliente no início do dia, deixando você com apenas 6 horas para consertar aqueles bugs até o fim do dia. Você gasta meia hora a mais no almoço. Cinco horas e meia. Mas até o almoço você “matou” quatro deles. Você estava um pouco grogue nesta manhã e você achou que aquele almoço iria curar aquele sentimento. Você irá conquistar os outros dez nesta tarde.

Você não conquista.

Você terminou quatro, talvez cinco deles e deixou oito, talvez nove bugs consertados. O cliente não está satisfeito. Você fez apenas parte do trabalho. TODOS os bugs eram críticos. Sua empresa é pequena e você é o único com conhecimento do projeto, e, os outros desenvolvedores estão ocupados em seus próprios projetos. O cliente espera… DEMANDA… respostas 7 dias por semana, 24 horas por dia.

Por que você é a puta dele.

Tudo bem. Então seu chefe o envia um grande email de desculpas dizendo que você irá trabalhar duro no futuro para atender todas as demandas porque você não quer perder este cliente. Ele investiu $30,000 nesta empresa e com a versão 2 do site “pronta pra ir ao forno” ele irá investir bem mais.

Então você volta a corrigir aqueles bugs que faltam. Durante a noite mais três chegaram. O número de bugs agora é oito. Oito horas no dia, oito bugs na lista. Feitos até o fim do dia. Você completa cinco durante seu expediente e dois quando chega em casa, depois do jantar. Você está exausto. Eles levaram o dia todo para serem debugados. Você envia um email para o cliente dizendo que você consertou sete dos oito bugs. Ele te envia um email de volta, vinte minutos depois de você ter ido dormir, naturalmente, dizendo que o último bug “deixa o site inutilizável”. Seu chefe vem até você pela manhã e diz que seu trabalho não é bom o bastante. Você não aprecia muito a sugestão dele. Você reclama e diz que consertou treze dos catorze bugs que o cliente enviou no início da semana. Você sente que foi colocado num ritmo de trabalho excepcionalmente duro essa semana. Hoje você completou o décimo quarto, você está muito confiante sobre isso. Ele naturalmente pergunta o porquê de ter catorze bugs. Você não tem uma resposta imediata, embora você pensa em mencionar os testes. Ele continua com seu discurso retórico sobre aquilo que você deveria estar testando o código toda vez que você o coloca em produção. O seu chefe continua com a encheção de saco por uma hora. Você tenta contra argumentar os argumentos dele mas sua visão parece algo de um “ser superior” e pela sua falta de experiência você não pode colocar a culpa nele. Ele é o chefe no fim das contas. Ele chegou aqui de alguma forma. Ele tem que estar certo sobre tudo?

Sua empresa pagou todos estes débitos técnicos que você não tinha orçamento para tal. Todo o processo extra custou um mês a mais e o cliente estourou seu orçamento em $2000. $2000 que ele nunca quis gastar. Ao invés de economizar $2000, ele agora gastou $2000 extra da sua própria conta pessoal para fazer com que o projeto andasse. Ele está falando de deixar sua empresa e ir para uma que pode fazer um trabalho melhor. Este é provavelmente o caso. Seu chefe te chama no canto e te diz como está o projeto. O cliente está saindo. No próximo dia ele demite você.

Parabéns, Freebird. Você está sem emprego e com muito, muito pouco dinheiro. Uns $2000 é tudo o que você ainda tem. Hora de ir à caça denovo.

Então como você pode prevenir que algo assim aconteça?

Você eventualmente pega um novo emprego com uma nova empresa. Você se senta com o cliente e faz as coisas direito. Você cria specs das histórias de usuário usando algo parecido com o Pivotal Tracker. Você é ensinado a escrever testes religiosamente para cada história usando o Cucumber. Não há história sem um teste. Isso reduz o débito técnico a longo prazo Você não tem tantos bugs como você tinha quando não testava com as aplicações anteriores. Embora você ainda tenha alguns bugs, você não irá gastar todas aquelas longas noites os consertando porque você tem testes cobrindo todos eles. Os testes irão mostrar onde alguma coisa deu errado, pois, geralmente, uma parte defeituosa do site significa um teste que não está passando. Viu um bug que não foi coberto por uma história ou teste? Isso acontece algumas vezes, mas você agora tem esse framework fantástico que te dá certeza que não o mesmo erro não irá acontecer denovo: teste de regressão. Escreva o teste. Ele não passa. Conserte o bug. Ele agora passa. Se você ou seu time segue a regra Green is Good, então eles NUNCA MAIS irão reintroduzir este bug. Em teoria. Pessoas cometem erros.

Então você inicia uma história simples como “Login de usuário” e você escreve uma funcionalidade para o cucumber para ela com dois cenários. Um para login e outra para logout. Você escreveu todos os passos para ela mas alguns deles não estão implementados, outros estão quebrados. Isso é devido ao fato que você ainda não escreveu nenhum código para a funcionalidade ainda. Parece meio retrógrado e improdutivo à princípio. Isso é chamado de Desenvolvimento Orientado à Comportamento (Behaviour Driven Development – BDD). Você está aprendendo BDD e você irá fazer certo de agora pra frente. Você está se tornando um Jedi de BDD. Você implementa cada passo por vez e eventualmente sua funcionalidade está toda verde.

Pra que você faz isso?

Para que no futuro, daqui uns três meses, você não veja essa funcionalidade dando pau e não precise trabalhar numa máquina do tempo para voltar e dar um pé na sua bunda.

Você ainda ganha alguns pontos extra se você estiver usando um servidor de Integração Contínua para garantir que esta funcionalidade e seus eventuais irmãos de testes fiquem verde. Um build falho significa uma aplicação falha e seu único objetivo se aquele build está quebrado é fazer com que ele seja consertado.

Parabéns.

Agora você pode marcar como a história como “terminada” no Pivotal. Então você pode implanta-la num staging server e marca-la como “entregue”. Daí o cliente pode logar no no Pivotal e ver que a história está marcada como “entregue” e logar no staging server, testar a feature e apertar aquele amado santo-graal botão “Aceitar”. Você quer ver histórias verdes na sua lista do Pivotal. Verde é a cor que você quer ver em todo canto.

Verde é bom.

Então a próxima funcionalidade vem aí e envolve uma lógica de controller um pouco mais complexa que retorna um hash JSON. Você pode escrever isso em Cucumber, o você pode escrever um teste para seu controller com o RSpec. Este é o tipo de coisa que é realmente legal para discussões com o time. Você sugere o Jeito A de fazer isso, e talvez outra pessoa do do time irá concordar ou sugerir o Jeito B, e essa adorável dinâmica de discussão de idéias produz um resultado melhor. De qualquer forma, você irá escrever o teste primeiro e então o código. Behaviour Driven Development. Então o teste passa. Então você pode refatorar o código se ele ainda não estiver bom o bastante e ele ainda irá passar. Com certeza você irá se sentir mais devagar no início, mas o motivo disso é que você ainda está aprendendo como fazer. Não lute contra isso. Este tipo de coisa irá te poupar muito tempo no futuro, onde é mais importante. Foque-se mais nos ganhos a longo prazo do que a curto prazo.

Eventualmente depois dos sete meses e meio você terá todas aquelas histórias do Pivotal Tracker em verde na seção de “Concluída” e talvez um ou dois no “Backlog” que o cliente quer pronto apenas para a próxima entrega. Você irá rodar todas as specs no seu sistema. Todas elas estão verdes. Você irá rodar todas as funcionalidades. Elas estarão todas verdes. Você irá implantar no server de staging pela última vez nesta release. O cliente adora isso. Você implanta no server de produção e envia os convites. Todo mundo adora isso.

Mas.

Há um bug. Entretanto, desta vez você instalou algo tipo o Hoptoad para o erro ir para sua caixa de entrada na mesma hora que ele ocorre. Você é o time de suporte para esta aplicação, NÃO o cliente. Depois de tudo, você ainda está trabalhando numa empresa pequena. O relatório de erros contem uma stacktrace e você pode ver onde deu errado imediatamente. Você escreve um teste/funcionalidade para garantir que este bug jamais aconteça denovo. O teste falha, pois você ainda não consertou o bug. O erro é o mesmo reportado no email do Hoptoad. Você conserta o bug.

Parabéns. Você escreveu um teste de regressão para o bug com sucesso. Este bug jamais irá ocorrer pelo resto da vida do projeto.

O cliente está feliz. Seu chefe pergunta se o cliente pode bater um papo com você. Você está fazendo um trabalho excelente. Os outros caras tinham um salário maior que o seu porque você foi contratado como um desenvolvedor Junior. Não mais. Você percorreu um caminho surpreendentemente grande. Agora você é igual. O cliente quer que mais coisas sejam feitas na aplicação. O cliente está querendo que seu chefe vá até o escritório dele na próxima semana. Ele requisitou especificamente que você vá junto também, pois você parece estar “ligado”. Você se encontra com o cliente e discute os termos da próxima iteração, uma bem grande. O acordo avança e sua empresa precisa crescer. Massivamente. A aplicação explode, no sentido positivo. Você tem problemas com escalabilidade. Você contrata outros dez caras no próximo ano só para trabalhar nesta aplicação. Você e uns dois do time original os ensina tudo sobre sua aplicação e o processo que vocês desenvolveram. Então eles irão ensinar outras vinte pessoas que você irá contratar nos próximos seis meses.

Parabéns. Agora você está fazendo certo.

UPDATE

Este post é uma tradução do excelente post do Ryan Bigg. Thank you Ryan!

Notem que eu não coloquei nenhum link no texto. Como é um texto mais “educativo”, eu espero que as pessoas que o lerem tenham a iniciativa de pesquisar os termos desconhecidos por conta própria. Links são muito cômodos e não incentivam a pesquisa

Sem posts relacionados.