Nenhuma inicialização começa com um testador.  Então, 2 anos depois, aquela startup não pode lançar um novo recurso para seu maior cliente de todos os tempos, a menos que reescreva tudo com um grande estrondo. É doloroso assistir isso repetidamente.  Existem coisas simples a fazer para manter a qualidade sanitária do nosso software, para que você não acabe nessa situação.  Primeiro, abrace seus medos. Os engenheiros são pessoas corajosas e não admitimos prontamente que temos preocupações. Mas nós temos, e quanto mais cedo admitirmos e compartilharmos essas preocupações, mais cedo nos prepararemos para enfrentá-las.  Como Construímos Software Hoje  Temos tanta pressa que sempre nos atrasamos. Não há tempo para testes. Não há tempo para testes de unidade. Não há tempo para refatoração.  Bem, nunca haverá tempo suficiente para fazer isso direito enquanto continuamos nos sabotando como equipes de engenharia.  Nos perguntam quanto tempo levará e continuamos excluindo testes de unidade, testes manuais e até mesmo testes de API e refatoração de nossas estimativas.  Então, construímos um software como este:  Rapido e sujo  Não rápido, ainda sujo  Caminho diagonal rápido e feliz testado  Todo o resto é considerado um caso extremo. (Não existe caso extremo.)  Poucos de nós são ainda mais corajosos para dizer não ao rápido ou sujo e construir software rápido e estável.  O que você deve cortar de suas estimativas é o escopo, não a qualidade.  O que você sabe sobre a qualidade do componente em que está trabalhando?  Você sabe que é frágil, mas não quer tocá-lo porque é muito frágil.  Você já fez isso há muito tempo, mal toca, deve funcionar.  Você não sabe que é frágil.  Não há testes e ninguém para testar e expor o quão frágil ele realmente é.   Você está feliz lidando todos os dias com este software sujo?  Você está feliz fazendo concessões com a qualidade do seu trabalho todos os dias, sabendo que está longe de ser bom? Lidar com "não temos tempo para limpar" e ainda estar atrasado porque está sujo e você não pode seguir em frente sem limpá-lo.    que você está em sua próxima entrevista de emprego. Do que você vai se gabar em seu trabalho atual? Que você pode trabalhar sob pressão e fazer correções tarde da noite? Eles vão te amar por isso, mas também vão te perguntar por que você não fez algo a respeito. Talvez não fosse o seu trabalho. Imagine  Havia líderes de equipe e gerentes de engenharia para tomar essas decisões. Se dependesse de você, você teria feito alguma coisa. Você disse a eles que o código precisa ser refatorado e que você precisa planejar o tempo para o departamento de tecnologia em cada retro, e ninguém ouviu.  Bem, adivinhe - você não precisa de permissão. A qualidade do seu trabalho depende apenas de você. Ninguém pode forçá-lo a escrever um código ruim. A pressão do tempo é uma desculpa de curto prazo.  Soluções rápidas e sujas atrasam todo o projeto e custam mais do que se você fizer certo da primeira vez.  Você nunca vai consertar isso depois  Você está disposto a fazer essa diferença?  Então, aqui está o que fazer: seja disciplinado. Sinto muito, mas não há outra maneira de contornar isso. E deve ser em todos os níveis.  Quais devem ser seus primeiros passos para criar código com maior qualidade?  Implementar registro e alerta  Existem inúmeras ferramentas para registro e alerta. Esta é a primeira coisa a fazer. Seu software está travando e você não está ciente disso.  Encontre uma solução que permita criar tickets facilmente a partir dos alertas de exceção e marcá-los como "conhecidos" ou agrupá-los assim que forem relatados.  Crie uma rotina de equipe para monitorar e relatar os alertas  Se você acha que é chato, deixe-me perguntar: você está concentrado durante todo o seu dia de trabalho? Depois de todas as reuniões e do pesado trabalho de programação, você precisa aliviar um pouco a concentração. Bem, navegar pelo canal de alertas é muito melhor do que navegar por qualquer outro canal.  Basta clicar no botão "Informar um ticket" ou no botão "Marcar como conhecido". E se você ficou intrigado, provavelmente consertaria um ou dois.  Aí vem o maior argumento - podemos consertar alguns, mas estamos escrevendo testes que alguém precisa confirmar, precisamos implantar, e isso gera mais trabalho não planejado para a equipe.  O PM vai gritar para nós que não estamos trabalhando nos itens de alta prioridade, mas em pequenos alertas.  A equipe com todas as funções "M" concorda com isso.  Publique uma regra prática - "Se parecer pequeno e de baixo risco, e não houver absolutamente nenhum outro trabalho em andamento, basta ir em frente e corrigi-lo. Podemos lidar com um ou dois pequenos alertas corrigidos "fora do escopo" por Sprint , junto com os planejados."  É isso, muito simples.  Comece a limpar os logs e alertas um por um  Além das correções ocasionais, planeje a limpeza adequadamente. Observe que, por planejamento, quero dizer alocar tempo diário/semanal para corrigi-los   . Você perderá mais tempo avaliando a prioridade deles do que corrigindo as 5 primeiras. Então, comece a corrigir. , independentemente de sua gravidade ou prioridade  Certifique-se de que haja um alerta para cada desenvolvedor ou, se estiver fazendo mobbing a maior parte do tempo, defina um intervalo de tempo diário para alertas. E eu faria logo pela manhã porque senão, você nunca vai fazer.  Novamente, não é um novo recurso e pode parecer que consome o tempo de suas prioridades críticas, mas suas prioridades críticas já estão atrasadas por causa desses problemas ocultos. Você já está atrasado!  Remova todas as instruções Try-Catch vazias e deixe-as travar!  Embora os alertas e o registro exponham muito, eles não poderão registrar o que você oculta. Então pare de varrer seus problemas para debaixo do tapete.  O que caiu há 2 anos, e você não sabia porque é completamente diferente hoje. Deixe-o travar e corrija-o. Provavelmente nem vai travar da mesma maneira, ou não está travando mesmo, então de uma forma ou de outra, seu código estará em uma forma melhor sem eles.  Comece a escrever testes de unidade agora mesmo  Quero dizer. Você está trabalhando em algum código agora. Então nada o impede de escrever um teste de unidade.  Oh, eu vejo! Não há infraestrutura pronta para testes de unidade, há? Vamos! Você vai atrasar esse aspirante a recurso de qualquer maneira.  Você não precisa de mais de um dia para configurar a estrutura de teste de unidade e seu CI para executar os testes. Apenas faça.  Inicie o TDD para correções de bugs  "Não sabemos qual é o problema e como vamos corrigi-lo. Não podemos escrever testes para códigos que ainda não existem."  Meu caro desenvolvedor, o objetivo do teste é verificar uma hipótese. Isso é válido para testes em geral, não apenas para testes de software. Portanto, o que você precisa para escrever um teste não é o código. Você precisa do comportamento e resultado esperados.  Agora, se as histórias do usuário são vagas e pouco claras e você não está pronto para começar a escrever testes contra as histórias do usuário, também tenho uma solução para isso, mas antes disso - comece a escrever código de teste primeiro para bugs.  Existe um componente da descrição do bug chamado "Resultado esperado" e as etapas para reproduzir são o seu caso de teste. Então você já tem o caso de teste à sua frente. Agora, codifique-o antes de começar a codificar a correção.  Test-Driven Development é escrever um teste que valida que você fez o trabalho certo, não que você o fez certo. Os testes de unidade verificam se você fez certo.  Desenhe um Roteiro de Cobertura  A automação de teste e a dívida de tecnologia têm destinos trágicos semelhantes - eles nunca são iniciados porque "nunca podemos cobrir tudo, nunca podemos limpar tudo, é uma sobrecarga demais. Não temos tempo para isso".   Ouça-me: você não precisa automatizar tudo!  Mas você definitivamente deve automatizar seus elementos de missão crítica - casos de uso de alta prioridade, infraestrutura crítica e funcionalidades principais. Chame do que quiser, mas a empresa depende de 20% de seu código e infraestrutura, e seus clientes estão usando 20% de seus recursos.  Você vê onde eu estou indo com isso.  Você nem precisa começar a escrever testes automatizados para esses recursos agora.  O que você precisa fazer primeiro é priorizá-los.  Reúna-se como uma equipe diante de seus diagramas de arquitetura de alto e baixo nível. Não há nenhum, não é? Ou as que existem são uma foto de um quadro branco tirada há 2,5 anos? Eu sei.  Sim, você precisa gastar meio dia e atualizá-los. A boa notícia é que existem ferramentas divertidas para ajudá-lo, então você não precisa fazer a manutenção manualmente. Pesquise.  Afinal, você é uma equipe de P&D, certo?!  Não aponte para cobertura total - aponte para baixo risco e alta confiança  Ao diagramar sua arquitetura e infraestrutura atualizadas, adicione notas ou círculos, ou negrito ou pinte de vermelho todos os lugares que são:  Missão crítica para o seu negócio e software  Precisa desesperadamente de refatoração, ou você continuará adiando esse outro recurso de missão crítica o tempo todo.  Constantemente quebrando e comendo seu tempo consertando-os é praticamente em vão porque eles vão quebrar novamente em alguns dias.  Quando os desenhos estiverem prontos, sente-se com sua equipe e faça um brainstorm sobre o que precisa ser testado para todos esses componentes circulados.  Não caia na armadilha de "isso é demais! Devemos parar todos os outros trabalhos para cobrir tudo isso!" Você não precisa cobrir tudo isso de uma vez. Mas você precisa de um plano. Agora, abra outro quadro e comece a escrever suas metas de teste. Exemplos:  Cubra todas as solicitações de API de busca de dados para sucesso e falha para que você saiba que não enviará solicitações incorretas e, se falhar, falhará por causa do fornecedor.  Descreva a jornada do usuário de missão crítica. Divida-o em unidades. Escreva os testes de unidade. Quando a pirâmide de teste foi inventada, uma unidade significava um componente, não um método, então abrangia funcionalidade, não métodos e classes.  Identifique os engarrafamentos e decida como vai resolvê-los.  Planeje fazer direito. Seu código rápido e sujo permanecerá sujo com testes sujos.  Usei intencionalmente um Mapa de cobertura e não a Pirâmide de teste porque... neste estágio, quando você não tem nenhum teste em vigor, manual ou automatizado, você não está pronto para a Pirâmide.  Muitas equipes têm a impressão errada de que primeiro precisam atingir 96% de cobertura de teste de unidade e depois passar para os testes de integração e assim por diante. O problema com a cobertura de teste de unidade moderna é que testamos Métodos e Classes, não funcionalidades.  Ainda mais equipes começam com a automação da interface do usuário, o que é igualmente errado.  Na verdade, essa é a pior coisa que você pode fazer e está fadada ao fracasso.  Portanto, não comece do topo ou da base da Pirâmide, mas construa um mapa de risco.  Alguns recursos podem precisar de testes de integração extensivos, outros recursos podem precisar de testes extensivos de interface do usuário e a próxima parte pode realmente ser um recurso principal do qual tudo depende (outra bandeira vermelha, no entanto), e você deve cobri-lo de cima a baixo totalmente.  Ou é um serviço de coleta de dados, e você precisa focar no desempenho das APIs, por exemplo.   Crie um mapa dos pontos de acesso de seu software que precisam de testes pesados.  Em seguida, pense em como você pode automatizar esse teste.  Você não pode progredir na areia movediça e só você pode sair de lá  Vamos encerrar - não há teste, o código está em mau estado e você não tem tempo. Você continua fazendo concessões porque "você não tem tempo". Você não está totalmente feliz, ou pelo menos é bastante ignorante - eles pagam, a decisão é deles e não é sua.  Se eles não estiverem satisfeitos, você passará para a próxima empresa.  Bem, as coisas mudaram muito no ano passado, não é mesmo?! Você precisa ser um excelente desenvolvedor para permanecer contratado. As empresas aprenderam que poderiam descartar pessoas independentemente de sua contribuição.  Ainda assim, há engenheiros que uma empresa fará de tudo para manter. Para ser um deles, você precisa impulsionar a mudança e provar constantemente que o negócio depende de pessoas como você.  Todo mundo pode escrever software ruim, mas os realmente bons não apenas escrevem software excelente com alegria, mas também inspiram outras pessoas e espalham a cultura de qualidade de código.  Você não pode progredir na areia movediça e só você pode sair dela.

Read My Stories

Say "Hi!"

Buy Me a Coffee

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Make resilience your competitive advantage

Você nunca vai consertar depois - como tirar sua equipe da areia movediça

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Telegram: a ponte da Crypto Island para o continente

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Telegram: a ponte da Crypto Island para o continente

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps