Síndrome do encanamento: regras de código legado para testes

Muitos se depararam com um recém-chegado que veio ao projeto e afirmou que "tudo precisa ser refeito com urgência". E alguns disseram ou pensaram. Isso é “síndrome do encanamento”: comportamento caracterizado por um desejo de fazer tudo do seu jeito, “certo”, ao trabalhar em um novo projeto ou ao mudar para um novo emprego. Portanto, o código, tecnologias ou ferramentas existentes precisam ser reescritos, de preferência "por si mesmos". O tópico seria comum se não fosse repetido com tanta frequência de projeto para projeto, a cada novo recrutamento.

Quanto mais um projeto "vive", mais ele acumula um código herdado "histórico" e maiores são as chances de encontrar os olhos ardentes de um encanador afetado pela "síndrome". Neste post, gostaria de dizer a quais princípios a Parallels adota (imediatamente, o spoiler é o princípio de "não faça mal") e o que fazemos se decidirmos "refazer tudo", afinal. Embora em geral acreditemos que essa síndrome deva ser tratada e que o uso do legado às vezes seja útil, pois permite liberar o produto no prazo e não perder tempo desenvolvendo suas tecnologias.

Quando você trabalha com "programas de longa duração", uma porcentagem grande o suficiente é o código legado. Por exemplo, o Parallels Desktop está em desenvolvimento há mais de 15 anos. Todos os anos, a equipe se expande, novas pessoas vêm, olham o que está escrito e declaram: "Tudo está torto, vamos arrancar as mãos do programador e reescrever tudo". Uma situação familiar?

Antes de começar a dizer se o código legado é bom ou ruim, gostaria de decidir sobre os conceitos de quem entende isso e o que. Duas definições são geralmente usadas: a primeira é um código que não é coberto por testes. Do ponto de vista do teste automático, todo o código não é coberto por testes. O segundo código herdado é o código que você herdou. Quando você precisa entender como isso funciona, mas ninguém a perguntar. E você precisa se preocupar com isso.

Sabedoria Potencializada

I. O melhor é o inimigo do bem. Se o código ou sistema legado executar toda a funcionalidade necessária com qualidade aceitável, você não precisará melhorá-lo, é melhor direcionar sua energia fervente para algo mais útil.

II Do importante e do novo, escolha o importante, do igual escolha o novo. Se o código legado contiver funcionalidade importante e não for coberto por testes, você deverá prestar a máxima atenção a ele, tanto em termos de processamento do código quanto em termos de cobertura com testes. Se o código legado e os novos recursos forem iguais em importância, você deve se concentrar em novos recursos (desenvolvimento e testes).

III Se o antigo não for passível de aprimoramento, construa um novo por perto e descarte o antigo. Se o código legado for necessário, mas impossível mudar, use o código antigo até escrever e depurar o novo. Quando o novo código funciona, o antigo pode ser jogado fora.

O que fazer

Etapa 1. Olhamos quem disse
1. Freelancer . Na maioria das vezes, as pessoas que não têm experiência em ingressar em um grande projeto pelo lado refazem completamente o código. Por exemplo, eu próprio trabalhei como freelancer, escrevi projetos do zero e, como muitos desenvolvedores similares, desenvolvi um hábito bastante estável - fazer exatamente da maneira que me sinto confortável.

2. Inexperiente . Às vezes, essas afirmações indicam uma falta de qualificação da própria pessoa na área de assunto: ele não conhece a história do projeto e, por exemplo, que essa construção “terrível” (em sua opinião) foi o resultado de pessoas tropeçando em erros externos no processo de desenvolvimento sistemas e começou a contorná-los. Como resultado, havia um tipo de espaguete de patches e muletas interconectados para esses bugs. Esse conhecimento de todas as armadilhas existentes nos seres humanos a partir do exterior não pode ser em princípio.

3. D'Artagnan . Na maioria das vezes, isso acontece com engenheiros que não têm experiência com produtos e experiência em grandes projetos que não entendem o preço que recebem. Um homem bate no peito com o calcanhar e diz que o fará de maneira brilhante, fresca e em apenas uma semana, mas ele pode estar profundamente enganado sobre suas habilidades e porque sente falta de pontos como testes e integração no sistema maior existente.

4. Especialista altamente qualificado. O único tipo de "candidato" que você deve ouvir, apesar de se apressar em refazer o conselho dele, ainda não vale a pena até que a Etapa 2. seja concluída. É possível que tenhamos um profissional de classe ultra alta e ele possa realmente provar que não então, e pode fazer melhor. Mas o fato é que eu não conheci uma única pessoa de nível sênior com essas declarações. Quando uma pessoa cresce a esse nível, ela já pode imaginar o projeto como um todo e entende todas as deficiências do método "revolucionário".

Etapa 2. Argumentando
A primeira coisa que uma pessoa precisa parar e analisar seus argumentos. Este teste deve ser iniciado pelo líder da equipe. Com a ressalva de que a "síndrome do encanamento" não começou a sofrer uma pessoa que veio a liderar a equipe. Então a análise do vôo é o trabalho do gerente de projeto, embora, francamente, um líder de equipe maduro nunca inicie uma alteração completa sem argumentação séria.

Quais argumentos falharão:
"Vamos escrever os nossos, com xadrez e poetas"
Na maioria das vezes, se um produto está no mercado há muito tempo, ele já funciona de alguma forma. Ele já mostrou que, apesar da natureza terrível do que está escondido, ele está funcionando. Por exemplo, temos o Parallels Desktop (uma solução para executar o Windows e outros sistemas operacionais em um Mac sem reinicializar) e, às vezes, você pode ouvir de iniciantes: “de alguma forma você é muito complicado aqui, vamos escrever minha máquina virtual”. E como essas coisas, em princípio, não podem ser feitas imediatamente, quando uma pessoa diz isso, ela está fora de tópico ou não por conta própria. É necessário dar a ele a primeira experiência no projeto e entender por que ele foi implementado desde o início.

"É feio."
O problema é que muitas vezes uma pessoa não tem outros argumentos. “Não tecnologicamente avançado”, “feito com lixo”, “por que está escrito em C, agora está na moda escrever em Go”. Estes não são argumentos para refazer o sistema. Porque quando você vai além do seu único pedaço de código, começa a perceber que seu retrabalho pode ser pior do que era antes. Pode parecer mais bonito por dentro e trabalhar mais lentamente, o que é inaceitável para o produto. Eu não vi isso na Parallels, mas na empresa anterior tivemos que experimentar todas as conseqüências dessa etapa. Decidimos que uma família de drivers para determinados equipamentos era implementada feia e precisávamos de um design mais elegante e estendido que fosse mais fácil de manter e adicionar novos recursos a ele. Eles escreveram novo e bonito por um ano e meio, mas no final acabou tão horrível e não deu nenhuma vantagem. E o custo dos recursos acabou sendo muito grande: dois desenvolvedores consumiram uma empresa e meio ano de trabalho.

Por que é melhor não tocar no código de longo prazo de um grande projeto

Você pode até matar seu projeto
Onde está a garantia de que você escreverá algo novamente e funcionará corretamente? Afinal, isso ainda não é. Do ponto de vista comercial, você precisa viver nos dias atuais e garantir a continuidade da renda.

Você pode quebrar muletas
Em qualquer projeto, existe algo como kludge (mais conhecido como “muleta”) e muitas coisas não documentadas. Sim, existe uma metodologia de desenvolvimento, quando a documentação é escrita pela primeira vez e, em seguida, o desenvolvimento é estritamente seguido por ela, mas ela ainda se mostrou nos anos 90 como inercial demais para tarefas de negócios. Talvez, dessa maneira, você possa fazer um foguete, isto é, em processos em que o desenvolvimento está em andamento há várias décadas, isso se justifica, pois há grandes riscos de desvios. E mesmo lá você tem que fazer algumas mudanças em movimento.

E do ponto de vista do desenvolvimento comercial de software, não há muito tempo para primeiro levar tudo em consideração na documentação e depois fazê-lo. E acontece que todos os produtos têm uma grande quantidade de dados não ditos. Deparou-se com algum tipo de problema ambiental, por exemplo, um pouco de ferro trabalhado para contornar a especificação, deu um jeito para isso. Em muitos casos, se foi uma alteração relativamente pequena, geralmente é esquecida e não é refletida na documentação. Ele está inserido no código e, na maioria das vezes, com algum tipo de comentário sensato, infelizmente.

E começa: vamos jogar todas essas muletas fora, já que não está claro que isso estraga o código. E eles não pensam no que isso levará. Por exemplo, quando fizemos um de nossos patches para o kernel do Linux, em um local como uma muleta bateu: era muito feio e, ao mesmo tempo, mal descrito. E então, na discussão, eles aprenderam: certos equipamentos sem esse armazém não funcionam. Sim, ele não é mais produzido, mas os usuários ainda o possuem e funciona. E a perda de suporte para esse hardware contraria a filosofia da comunidade Linux. Eu tive que reescrever nosso código para que essa solução alternativa fosse preservada individualmente e depois que todos estivessem satisfeitos.

Você pode desperdiçar recursos
Um exemplo desse desperdício de recursos é dado acima. Deve-se entender que qualquer revolução leva a uma guerra civil, a um certo período com uma deterioração do estado das coisas, em que nada funcionará.

Você pode perder o iniciador e o projeto
A síndrome do encanamento afeta principalmente novos funcionários. Vale lembrar que essas pessoas estão em risco porque podem deixar a empresa durante o período do teste (não é à toa que dizem que o período do teste não é apenas para a pessoa, mas também para a empresa). O homem recebeu carta branca, começou a refazê-lo e depois declarou que não gostava de café na empresa e foi embora. Esta é uma situação muito perigosa. Acontece que não há nada novo, mas o antigo já está quebrado. Então alguém (e de forma alguma um entusiasta) terá que trazê-lo para a forma de trabalho.

O que fazer quando a decisão de não refazê-la é óbvia e a pessoa está "queimando com uma idéia"?

Dê tempo para esfriar e pensar
Você só precisa dedicar tempo à pessoa que veio a um grande projeto existente para se conhecer melhor. Pois quando uma idéia vem de uma pessoa que trabalha há muito tempo em uma empresa e especificamente com este produto, suas iniciativas serão levadas muito mais a sério e serão analisadas por seus argumentos. Você precisa explicar a ele que não deve jogar em uma área com a qual ainda não esteja suficientemente familiarizado e que não conheça a situação atual. É duvidoso que uma pessoa que acabou de chegar, tendo examinado o código, possa explicar com razoabilidade por que tudo está errado e por que ele precisa ser alterado.

Se uma pessoa recusar tal recusa ou oferecer muito, essa é uma ocasião para anotar que, talvez, esse desenvolvedor não esteja pronto para trabalhar em equipe e que possam surgir dificuldades de comunicação com ele (e esse é um fator muito importante para nós). Desde então, o líder da equipe terá que trabalhar separadamente, no "modo manual". Talvez essa pessoa deva reconsiderar seus pontos de vista sobre sua carreira e trabalhar como freelancer, onde você pode fazer tudo "conforme necessário".

Dirija sua energia em uma direção diferente
A maioria dos grandes produtos sempre apresenta alguns gargalos e problemas que surgem regularmente, pois tudo muda do lado de fora. Embora, na minha opinião, ainda seja muito perigoso permitir que uma nova pessoa acesse o código até que ele trabalhe por alguns meses com a depuração de pequenos bugs, se familiarize com o código existente e comprove seu nível de habilidade.
É possível dar a ele uma tarefa de alguns projetos paralelos, para que ele coloque suas coisas novas lá e veja o que acontece. Desde que haja esses slots nos recursos, uma vez que há um número limitado de tarefas, aqui, como em uma empresa de risco, investi em 100 empresas e recebi retornos em uma.

Quando você ainda precisa refazer

O produto morre nas condições existentes
O argumento para refazer - se o ambiente externo mudou tanto que o produto existente parou de funcionar. Por exemplo, quando eles lançaram um novo sistema operacional, para o qual os usuários começaram a mudar em grandes quantidades, mas nesse sistema operacional algo foi alterado para que seu produto, que funcionava normalmente em versões anteriores, deixasse de funcionar ou se tornasse completamente inconveniente para o usuário. Ou quando a plataforma morre - por exemplo, de uma antiga, você pode citar o BeOS, sob o qual eles trabalhavam bastante com produtos multimídia, por exemplo, música composta. O sistema morreu e, como era bastante distinto, os códigos praticamente não foram transferidos para outros sistemas. O mesmo aconteceu com o próprio OS BeOS: havia computadores Atom que eles estavam alvejando e, em seguida, o fabricante parou de liberar esses processadores, e as pessoas que escreveram para esse computador praticamente ficaram sem nada. E eles foram forçados a se adaptar urgentemente à Intel, o que resultou mal para eles - o nicho foi ocupado e outro sistema operacional reinou lá. E para, pelo menos de alguma forma, prolongar sua vida, eles tiveram que refazê-la seriamente na direção de melhorar a portabilidade e assim por diante.

Síndrome do encanamento trabalhada: estágios de remodelação

É necessário fazer evolutivamente e em paralelo, sem quebrar o sistema. O processo e os estágios da alteração dependem de estarmos mudando o produto inteiro como um todo ou de uma parte significativa dele. Se todo o produto, então este é realmente o começo de um novo projeto do zero. Mas, na maioria dos casos, eles ainda mudam de parte, pois no primeiro caso, levará mais de um ano para que a nova base de código ganhe estabilidade e conformidade com as qualidades do consumidor, a fim de satisfazer pelo menos o nível que estava.

Se você substituir o componente, é recomendável fazê-lo: se a interface externa não exigir uma alteração, faremos a segunda implementação silenciosamente. É aconselhável encontrar imediatamente as linhas divisórias: aqui os restos antigos, mas aqui já é possível refazer, encontrar pontos de entrada. E assim, mantendo a interface, altere o preenchimento.

É como um carro, no qual eles decidiram substituir o motor a gasolina por um motor elétrico. Para o usuário, pouco mudou: o mesmo corpo, quatro rodas e volante permanecem. E sob o capô, tudo o mais pode ser.

Se você conseguir encontrar esse ponto de divisão, poderá refazer evolutivamente e qualquer pessoa que esteja nesse ponto de divisão poderá nem perceber as alterações (exceto, esperançosamente, uma melhoria na qualidade do trabalho). E, em seguida, no processo de teste interno, alterne e salve o produto. Infelizmente, isso está longe de ser sempre possível, e as alterações podem levar ao desastre.

Ou esta opção: a interface é fixa, a implementação é concluída e a interface começa a mudar iterativamente.

Faz sentido iniciar uma alteração séria nos galhos laterais e, até obter uma aparência final, ele não se integra ao produto principal. Mesmo com relação aos subsistemas, é pior se, com esse nome, começamos a fazer algo completamente novo e a equipe se separou, então não há nenhum produto.

Em vez de uma conclusão

Um menino nasceu com uma noz em vez de um umbigo. E ele periodicamente perguntou a seus pais por que ele tinha uma porca lá. Os pais prometeram contar a ele sobre isso no seu 14º aniversário. O cara fez 14 anos. E então ele foi novamente para o pai e a mãe e perguntou por que ele tinha uma noz em vez de um umbigo. Os pais prometeram contar a ele quando ele tiver 18 anos. Aos 18 anos, ele perguntou novamente, e então eles disseram a ele que havia uma ilha tropical na qual uma palmeira cresce e, embaixo dessa palmeira, um tronco está enterrado. Há respostas para todas as suas perguntas. O cara economizou dinheiro por um longo tempo e ainda se envenenou nesta ilha. Encontrei uma palmeira, abri um baú no qual havia uma chave inglesa. Sem hesitar, ele desapertou a porca com a chave encontrada e sua bunda caiu. Moral: às vezes você não precisa procurar aventuras no quinto ponto.