Testes e o Filtro Solar

Notícias, idéias, tutoriais, dicas, etc...
CristianMadrid
Membro
Membro
Mensagens: 1
Registrado em: 03 Nov 2017, 22:15
Fale sobre voce: Engenheiro de Software da Globo.com, gosto de várias coisas inúteis :)
Brazil

Testes e o Filtro Solar

Mensagempor CristianMadrid » 03 Nov 2017, 22:21

Todo código escrito sem testes é um código legado.

Imagem

Essa frase pareceu extremista para mim quando a li no livro: Working efectivaly with legacy code.
Bastou um parágrafo para Michael C. Feathers me convencer que esta frase, além de verdadeira, não tem nada de extremista.
Para entender o que Feathers queria dizer, vamos estabelecer algumas premissas:
    Pessoas esquecem as coisas.
    Pessoas nem sempre sabem tudo sobre algo.
    Pessoas confiam demais em seu código.
    Pessoas se alteram emocionalmente.
    Pessoas ficam doentes.
    Pessoas trocam de projeto.
    Pessoas trocam de empresa.
    Pessoas morrem.
A princípio, pelo menos a última opção "ainda" é verdadeira para todas as pessoas do nosso planeta. Se tratando de programadores, quase todas as situações são verdadeiras.

A premissa de que um software é mutável é verdadeira, negar isso é imaturo. Pense comigo, quantos trechos de código você escreveu e permaneceram imutáveis? Mudanças acontecem a todo momento e de todos os lados.
A funcionalidade pode mudar, os requisitos, a arquitetura e as pessoas do time também.
Tanto para correção de algum bug ou melhoria do produto, o ideal é que o desenvolvedor entenda as regras de negócio, os pontos de mudança do sistema e o que aquela alteração representa de risco para quebrar algo no sistema.
Essas informações não são adquiridas em pouco tempo em um projeto, é necessário uma maior convivência com o sistema e as pessoas que detém esse conhecimento.

Como conciliar isso com as constantes mudanças em um projeto? Como garantir que algo que já estava funcionando, continue funcionando?
Testar o sistema a cada alteração para verificar se algo parou de funcionar é muito custoso e com certeza não é o mais seguro, pois as pessoas erram.

A maioria dos projetos que trabalhei não possuíam testes. O que eu fazia? Nada, continuava nesse ciclo. A importância dos testes não era algo novo para mim.
Todo programador em algum momento de sua carreira terá algum contato com esse assunto(inclusive, esse texto pode ser o primeiro pra alguém, vai saber).

Meu primeiro contato aconteceu no meu primeiro emprego de desenvolvedor. Um colega vendeu a ideia de que teste é essencial para o desenvolvimento de um produto, o curioso é que ele não aplicava.
Por que ele não aplicava? Por que muitos desenvolvedores não aplicavam?
Gato escaldado tem medo de água fria.
Qual o sentido dessa frase pra esse assunto? Não importa o quão lindo e convincente testes podem ser, se você não se ferrou com a falta deles, a chance de você não dar valor é muito grande, comigo não foi diferente.

Quando comecei a aplicar testes, eu aplicava somente quando tinha tempo suficiente para isso, ou seja, quase nunca. Quando descobri que precisava manter os testes em conformidade com as regras de negócios, eu vi o quão trabalhoso e chato era aquilo.
Eu só passei a defender testes quando meu contato com essa cultura aumentou. Como consequência, comecei a perceber um padrão: As melhores equipes ou melhores empresas aplicavam testes. Chegou um momento em que somente o setor que eu trabalhava não aplicava testes. Isso alinhado a grande quantidade de bugs que eram gerados me fez investir mais tempo em testes.

A primeira mudança foi tentar aplicar testes em todas as minhas tarefas. Isso era relativamente fácil, não gerava qualquer atrito com o time. E o prazo? Eu evitava atrito com o time da seguinte forma: Evitava comunicar o time que estava dedicando uma parte do tempo da tarefa para aplicar testes, simplesmente aplicava.

- Mas Cristian, você era o herói do time?
Não, nem um pouco. Quando tive uma conversa com o líder da equipe sobre a importância de testes, ele falou assim:
Tente convencer o time
Eu simplesmente não consegui. O motivo? A maioria dos programadores que conheci, não gostam de aplicar testes em seu código, provavelmente os que você conhece também.
Muitos dos que gostam, não gostam tanto a ponto de defender isso para seu time. Muitos dos que defendem para seu time, não tem argumentos convincentes (Esse era eu).
Meu discurso(que na maioria das vezes ficava somente na minha cabeça) desconsiderava o contexto do projeto, era simplesmente: Aplique testes em tudo.
- Mas Cristian, quando não temos apoio para aplicar testes o que fazemos?
Não tinha resposta pra isso, portanto a conversa parava por ali.
Comecei a ver que não tinha como convencer.
Teve um momento que trabalhei num projeto quase sozinho. Foi nesse projeto que consegui pela primeira vez aplicar uma quantidade razoável de testes. Foi muito bom, pois consegui ter noção do quão difícil é se manter fazendo testes. Senti na pele a ideia de que testes não é uma bala de prata que resolve tudo.
Os bugs diminuíram consideravelmente, porém ainda existiam. Os testes me ajudaram também no design da solução, track de bugs e outras coisas.

Eu sou desenvolvedor mobile. Em mobile, colocar algo em produção não é tão rápido quanto na web.
Na web, os usuários geralmente acessam um sistema que está em um determinado endereço Http/Https.
Portanto, quando uma funcionalidade é criada, no momento em que o usuário dá um refresh na página, ele já tem acesso ao novo. Em sistemas com cache, usuários até podem acessar algo antigo, porém até isso pode ser contornado forçando a atualização do que está em cache. No mobile é bem diferente.
Imaginem um aplicativo bancário, onde foi encontrado um bug em produção. Após a correção, é submetido para AppleStore(iOS) ou GooglePlay(Android) a nova versão com a correção. Essa versão tem que ser aprovada pela Apple ou Google para entrar em produção e isso pode levar dias, isso mesmo DIAS(Já tive experiências onde levou mais de uma semana). Além de demorar dias, nada garante que o usuário atualizará o aplicativo, portanto ele pode ficar com a versão bugada para sempre.
Tudo isso deveria transformar os desenvolvedores mobile em evangelizadores de testes, mas o que vejo é o contrário: A maioria não dá a mínima para isso.

Tem certas situações que eu até entendo: Muitas vezes, o desenvolvedor não aplica testes pois realmente não tem escolha, por diversos motivos: Seja por ser um membro novo na equipe e não ter adquirido confiança do time, ou porque o teste não foi incluso nas horas de desenvolvimento,
ou trabalha em startup com síndrome do MVP(fazer rápido por causa do Time to market e nunca pensar em refazer depois que o MVP se provou), ou até mesmo quando o atraso na entrega tem algum impacto grande, como multas e outros problemas.

Uma outra coisa que ao meu ver contribui muito para não haver testes são times pequenos. Time pequeno consegue ter um melhor controle da base de código, pois geralmente tem um tech lead no time que acaba por guiar o desenvolvimento e muitas vezes todo código que entra em produção, passa pela análise dele, esses fatos dão uma falsa ideia de segurança. Já em um time grande, esse controle é mais custoso, pois a quantidade de pessoas trabalhando no código é muito maior.

Código funcionando tem muitos por aí e é relativamente fácil de desenvolver e entregar valor. Porém, até quando essa solução vai continuar trazendo valor e não prejudicar o negócio por causa dos bugs?
Como garantir que um bug não vire uma hidra e fique se multiplicando a cada bug resolvido?
Eu tenho alguns questionamentos que aplico constantemente:
Quero ficar até tarde nas sextas feiras arrumando bugs?
Estou inseguro de deixar outro desenvolvedor mudar minha implementação e causar bugs?
Se você responder Sim para qualquer uma das duas, está na hora de mudar.
Se por acaso for impossível aplicar testes no projeto que você está trabalhando, tome uma postura de alertar os riscos e custos que ocasionará em curto/médio/longo prazo. Deixe isto registrado por email, pois isso vai prevenir algumas dores de cabeça no futuro.
Ah, mais uma coisa:
Quando houver oportunidade de aplicar testes, aplique em tudo. Com o tempo e experiência, você vai saber o que é melhor de se testar ou não.
Ah, e como dizia Pedro Bial: Use filtro solar.


Avatar do usuário
Xevious
Administrador
Administrador
Mensagens: 9580
Registrado em: 28 Abr 2009, 01:12
Fale sobre voce: Sou feito de atomos
Gender:
Brazil

Re: Testes e o Filtro Solar

Mensagempor Xevious » 04 Nov 2017, 01:56

Os códigos mais complicados tem que ter comentários explicando mesmo.

Mas já trabalhei em lugar onde o chefe mandava tirar todos os comentários.
A galera tinha que se virar pelo CVS e sistema de chamados..

Mas não é a mesma coisa..

Sobre testes, é uma ótima pratica.
Tinha que ser automática, nestas IDEs mais porradas como as da M$, Eclipse, NetBeans, AndroidStudio, etc
Conheça o site Tele-Tudo e compre o que precisar, por tele-entrega

  • Tópicos Semelhantes
    Respostas
    Exibições
    Última mensagem

Voltar para “Programação”

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante