Muitos projetos com os quais trabalhei, grandes projetos, viraram legado, desvendando barbas, e com isso o desenvolvimento ficou extremamente difícil. Houve casos em que projetos simplesmente morreram devido à dificuldade infernal de fazer mudanças. Hoje contarei a vocês minha experiência com projetos e por que estou escrevendo tudo isso para vocês. Tudo é muito subjetivo, é claro.
Então, trabalhei e tentei, como um marinheiro que quer tirar água e evitar que o navio afundasse, mas a qualidade do projeto diminuía constantemente, e havia vários motivos.
Você os reconhecerá facilmente, eles são pacientes regulares, só vou lembrá-los sobre eles:
- A arquitetura é coxa, é difícil implementar uma nova solução
- Erros de codificação
- Não há teste automático
Como resultado, de acordo com os resultados do desenvolvimento do projeto durante os primeiros 1-2 anos, uma mistura de legado, código de merda, túneis emaranhados com passagens secretas e pinturas rupestres "funciona assim, porque eu não sei" é obtida.
Eu não insisto muito nisso, este é o tópico nº 1 em refatoração, então direto para as conclusões que tirei.
O produto desenvolvido é uma experiência coletiva
Se a equipe tem 1 megodesenvolvedor, realmente bombado, funciona bem, então ele não vai limpar sozinho, porque a equipe sempre comete erros e invariavelmente atrasa o projeto.
Você pode, é claro, tentar dar à equipe atual uma tarefa de refatoração, e então aqueles que a soldaram refazerão seu próprio resultado de trabalho e darão a mesma coisa, bem, talvez um pouco melhor do que da primeira vez.
Portanto, você não deve esperar um upgrade de qualidade radical sem um upgrade de equipe.
Este é um círculo vicioso número 1 - a experiência da equipe não é suficiente, mas começa a refatoração e, atenção, os mesmos posons que a escreveram fazem.
Alternativamente, você pode colocar um bom lead que conduzirá uma revisão e limpará esses erros (embora ele tente fazer isso), mas no final vai acabar com uma dor de cabeça para aqueles que trabalham mal, e então a substituição dos desenvolvedores, ou eles próprios irão embora e, novamente irá substituir os desenvolvedores.
Será uma espécie de seleção natural no projeto.
As pessoas têm medo de mudar o código
Bem-vindo, esta é uma sessão de psicologia para programadores.
Os programadores têm muito medo de alterar o código e podem ser compreendidos:
- Testes insuficientes ou não
- Como o código funciona não está claro
- As datas são em
- Sem recursos
- A gerência não vai entender (normal, mas se a gerência estiver pegando fogo, tudo ficará bem)
Como resultado, o código legado antigo e confuso que atrasa o projeto é percebido como "é melhor não tocar" e, como resultado, esse "não toque" dura para sempre e, pior ainda, força você a escrever código de uma determinada maneira, causando outros problemas técnicos que em seguida, eles também puxam o projeto para baixo.
Pegamos um projeto, código de merda, medos da equipe, multiplicamos pelo tempo, e ficamos com uma dívida técnica enorme, que fica em pé e não permite que a equipe ande normalmente e desenvolva o projeto rapidamente.
O projeto começa a desmoronar, os prazos são interrompidos, os novos recursos ficam muito mais caros para o projeto, os desenvolvedores começam a ficar nervosos, alguns vão embora, os novos são mais difíceis de encontrar, você entendeu ...
Então, acho que este é o problema nº 1, medo de código e riscos.
Por experiência, percebeu-se que, se você deixar dívida técnica, isso é uma bomba em potencial, ou pelo menos um ancinho. Deixe-os 100, 1000, e você terá um campo minado, no qual não apenas vá (desenvolva o projeto), você não poderá rastejar.
Portanto, a única maneira de economizar a velocidade média de desenvolvimento do projeto e não diminuir a qualidade é, graças ao limite, prestar atenção à qualidade, refatorar.
Conselho de fogo, todos sabem sobre isso, mas na verdade a lista acima não foi a lugar nenhum, então você não pode simplesmente pegá-la e refatorá-la, porque você tem um projeto que está desmoronando, e por quê?
Como não há testes, como o código funciona não está claro e, como resultado, em vez de alterar os desenhos e a montagem do carro, Vasya e Petya pegaram uma trituradora, serraram Solaris e colocaram de volta em Tavria, mas não funciona. Por quê? - oh, mas como não sabíamos sobre essa influência / comportamento / tarefas
Sim, você pode refatorar sem testes e então estabilizar, mas muitos scripts de usuário ou scripts de execução de código necessários podem ser perdidos, ou a estabilização pode demorar muito.
Portanto, mais um círculo vicioso - você não pode deixar o código sozinho, mas também não pode refatorá-lo, por assim dizer, porque existem riscos enormes.
Acontece que não precisamos do Legacy, mas livrar-se dele é assustador e perigoso, então as equipes geralmente deixam o Legacy como a "opção menos perigosa" para obter uma solução ainda mais perigosa para o projeto posteriormente.
Os testes são a chave
Acontece que, para desbloquear a refatoração e torná-la segura, primeiro você precisa cobrir todos os casos com testes e, em seguida, quando cortarmos nosso Solaris e montá-lo em Tavria, a soldagem irá parar e dizer "Olá, precisamos de um Solaris, você estragou tudo aqui."
Os testes permitem que você evite erros durante a refatoração, ou seja, torná-lo seguro, e então você pode cortar o projeto como você deseja e precisa, sem o próprio medo de que os riscos funcionem e que haja problemas.
Portanto, temos uma cadeia:
Testes -> Refatoração -> Adeus barba e legado
Parece simples, bonito, mas na prática são poucos os testes. Ou simplesmente não acontece, e há vários motivos para isso, como de costume:
- Os desenvolvedores consideram os testes um tópico separado e não investem em avaliações, eles escrevem separadamente do desenvolvimento. Fica ainda mais difícil se a gerência de projetos pensa assim e quer cortar testes para cumprir os prazos.
- Os testes são tempo, e o projeto precisa ser entregue agora, não há tempo para escrever testes para nós (isso é, em teoria, o mesmo que o ponto número 1)
- O projeto / componente é simples, por que existem testes, tudo é extremamente simples e funciona lá?
- Primeiro, escreveremos o código, depois o cobriremos com testes. Mas não, minhas mãos não alcançaram, o projeto não parou, não deu tempo. Portanto, essa tarefa fica na caixa preta para sempre.
Na verdade, existem um milhão de razões, mas o fato é que isso bloqueia a refatoração e, como resultado, impede que a qualidade cresça.
Portanto, os testes são uma tarefa crítica e, sem eles, o desenvolvimento da qualidade do projeto a longo prazo será significativamente difícil, senão impossível.
O que fazer, Houston?
Estou escrevendo este artigo apenas porque nem todo mundo entende isso, e há pelo menos alguém que vai ler e querer escrever testes, refatorar, então escrevi este artigo por um motivo.
Portanto, todos têm seu dever de casa - pegue um módulo, componente ou algo mal escrito, encontre lá que você gostaria de refatorar, escreva testes para este módulo ou componente e refatorar.
Como resultado, você entenderá que os testes são:
- Uma maneira de aprender código. Pode até ser muito mais eficiente do que apenas lê-lo.
- Estabilidade
- O código antigo pode realmente ser refatorado e a qualidade do projeto pode ser melhorada
Escrevi tudo de uma vez, muito subjetivamente, e talvez eu esteja errado, essa é apenas minha experiência. Talvez eu acabe de encontrar projetos assim, não sei, mas a informação ainda é útil, e se você ficou pensando depois de ler, isso também é bom.
Desejo a todos um bom código, testes e movimento de qualidade - é por isso que fomos contratados, vamos trabalhar bem.
PS Se desejar, escreva sua experiência de refatoração nos comentários, todos ficarão interessados.