O que Star Wars, o grupo Tatu e a combinação Ctrl-Alt-Del têm a ver com o código legado? O que fazer quando você chega a um grande projeto e encontra um abismo de código antigo incompreensível? E como é mais eficiente transmitir às autoridades que os custos trabalhistas para eliminar a dívida técnica estão pagando?
Os relatórios de
Dylan Beatty não são isentos de piadas, mas acompanham discussões bastante sérias sobre os principais problemas de desenvolvimento. Isso é adequado para o final da conferência: quando o público já ouviu muito hardcore e não consegue mais perceber slides de código, é hora de perguntas mais gerais e uma apresentação brilhante. E quando nossa conferência DotNext 2018 Moscow .NET foi concluída pelo discurso de Dylan sobre o código Legacy, o público gostou mais.
Portanto, agora para Habr, fizemos uma versão em texto traduzido deste discurso: para doadores e para todos os outros. Além do texto, abaixo do corte há uma gravação de vídeo original em inglês.
Olá, meu nome é Dylan Beatty. O tópico da conversa está muito próximo de mim e, na minha opinião, é extremamente importante para todos os envolvidos no desenvolvimento de software: falaremos sobre código legado.
Primeiro, direi algumas palavras sobre mim. Comecei a desenvolver sites em 1992, pelos padrões de nossa indústria, nos tempos pré-históricos. Agora sou CTO da empresa londrina SkillsMatter. Comecei a trabalhar lá este ano, herdando a base de códigos: 75 mil linhas de código não escritas por mim se tornaram minha responsabilidade. Parte do meu relatório é baseada nessa experiência. Além disso, sou o Microsoft MVP e o chefe do grupo de usuários London .NET.
O que Doctor Who, o moderno Guerra nas Estrelas, Sherlock e Paddington têm em comum? Ao trabalhar neles, um código legado foi usado. Eu sei disso porque, durante 15 anos, trabalhei no Spotlight. Esta é uma empresa sediada em Londres que fornece uma ferramenta on-line para atores profissionais que atuam em filmes e na televisão. O software, escrito por mim e minha equipe, foi usado no trabalho em todos os projetos mencionados e em muitos outros.
Na nova Guerra nas Estrelas, alguns não gostaram dos atores, outros não gostaram da trama. Mas ninguém saiu do cinema com as palavras "Não gosto que o ASP clássico tenha sido usado na criação!"
Porque isso não importa. Essa base de código está em produção há muito tempo e, sim, existe um ASP clássico - código mais antigo que o .NET inteiro - que ainda é usado hoje na transmissão de filmes e programas de TV. É necessário enfatizar corretamente: são esses filmes e programas de TV que são importantes, e o código existe apenas para resolver problemas. Até você executá-lo, o código em si não significa nada. O valor surge apenas quando você o inicia e faz algo com ele. É para isso que as pessoas pagam - Netflix ou DVD. O problema é que é muito fácil esquecê-lo.
Em geral, hoje eu quero, entre outras coisas, compartilhar com você minha experiência com a mesma base de código por muitos anos. Eu assisti como ele evoluiu e como outras pessoas o conheceram e aprenderam a usá-lo. E o outro lado dessa equação é o meu novo trabalho, que me permitiu ver o mesmo processo do outro lado, quando eu mesmo tive que me familiarizar com o código de outra pessoa.
Mas primeiro, vamos falar sobre a rapidez com que as coisas estão mudando em TI.
Dê uma olhada no primeiro iPhone - hoje ele parece completamente antigo e volumoso. E este modelo tem apenas 11 anos, apareceu em 2007 e custou US $ 800. Se você comprou uma máquina de lavar roupa, violão ou bicicleta em 2007, hoje ainda poderá usá-los. Mas o primeiro iPhone não funciona mais - mesmo que você consiga encontrar uma cópia com uma bateria e um carregador, tudo o que fez do smartphone um dispositivo tão incrível não funcionará nele.
Você não poderá abrir o mapa porque os servidores de mapa não existem mais. Você não poderá acessar o Twitter porque as versões mais recentes do aplicativo do Twitter exigem uma versão do iOS que não pode ser instalada no iPhone 1. O cliente do Twitter simplesmente responderá a você: "ponto final não encontrado". Em essência, você terá um fóssil em suas mãos. E a única coisa que funcionará é a função de um telefone comum, você ainda pode ligar para ele. Porque nesta área, diferentemente da TI, os padrões de 11 anos não mudaram.
Vamos fazer uma pequena viagem no tempo. Lembra dessa?
Você se lembra em que ano foi? Tatu se apresentou no Eurovision Song Contest em 2003. E em 2003, escrevi o código ASP, que ainda é usado na produção.
Parece-nos que isso foi há muito tempo, mas esse código ainda funciona. Os fabricantes de telefones celulares conseguiram convencer as pessoas a comprar um telefone novo a cada dois anos, para que possam se livrar de desenvolvimentos antigos, desativar APIs, terminais e serviços. Mas muitas empresas não têm essa oportunidade e, portanto, continuam a apoiar o código escrito quando Tatu se apresentou no Eurovision. Esse código é importante porque ainda desempenha funções importantes, gera receita - ou seja, é um código legado.
E embora todos concordemos que o Legacy existe, a pergunta permanece: o que exatamente é isso? Aqui está um código de exemplo:
Olha, pense: é legado ou não? O que você acha?
Eu inventei o dispositivo, eu quero vender no próximo ano. Você o insere na porta USB, seleciona um código e o dispositivo informa se é legado ou não!
O código que você acabou de ver não é legado. Foi escrito por
Andrey Akinshin (
DreamWalker ) há quatro dias. Isso
é obtido no BenchmarkDotNet.
O fato é que é impossível determinar se o código é Legado simplesmente olhando para ele. Além disso, o próprio código não tem nada a ver com isso. O importante é o que acontece ao seu redor: pessoas, cultura, processos, testes e assim por diante.
Se você abrir o artigo "Código legado" na Wikipedia em inglês, poderá ler o seguinte: "Este é o código-fonte relacionado ao sistema operacional ou a qualquer outra tecnologia de computador, cujo suporte ou produção foi descontinuado". Nós somos como: "tudo bem". E então está escrito: "Este termo foi usado pela primeira vez por George Olivetti em relação a um código suportado por um administrador que ele próprio não escreveu esse código".
No final desta frase, há um link para o blog de um certo Samuel Mullen. Pensamos: "Interessante, veremos". Mas se abrirmos o
post , veremos que este Mullen, por sua vez, se refere à Wikipedia!
E, ao que parece, ninguém mais sabe quem era esse George Olivetti. Portanto, parece que devemos procurar uma melhor definição.
Uma das definições mais populares do setor foi dada por Michael Faethers: "Legado é simplesmente código sem testes". E Michael escreveu um
livro inteiro sobre esse assunto, então ele definitivamente sabe do que está falando. Mas, ainda assim, não concordo completamente com sua definição.
Portanto, uso minha definição há vários anos: "Código herdado é um código assustador demais para atualizar, mas rentável demais para excluir".
Mais tarde, descobriu-se que uma definição muito semelhante já foi
dada independentemente de mim: "um código muito lucrativo que temos medo de mudar". Eu me pergunto de onde vem esse medo. O que há nos testes que transformam código sem eles em legado?
Uma das ferramentas de negócios mais antigas do mundo é um sistema de contabilidade de entrada dupla. Ele tem centenas de anos e cada transação de um banco ou empresa é contada duas vezes: em uma coluna, escrevo quanto dinheiro paguei e, na outra - o valor que recebi por eles. Além disso, as somas de ambas as colunas devem ser iguais; se houver discrepância, um erro será cometido em algum lugar.
Parece-me que a idéia fundamental dessa abordagem parece muito importante: todas as decisões que tomamos têm efeito duas vezes e, se você mudar uma coisa, em outro lugar, você definitivamente também terá mudanças que precisam ser monitoradas. Essa abordagem dupla pode ser aplicada ao código e testes, ou ao código e a um sistema de monitoramento, ou ao código e documentação.
Muitos sistemas que consideramos herdados também existem em duas versões, mas são versões "no código e na cabeça de alguém". E aqui, na minha opinião, reside uma das nossas principais dificuldades.
Lembro-me da
história em quadrinhos de uma página "É por isso que você não deve interromper um programador". O desenvolvedor analisa uma linha simples de código e imediatamente começa a pensar no que precisa ser reescrito no menu de navegação agora, como isso afetará o depurador, que precisará ser alterado no código. Alguém chega até ele e pergunta: “você recebeu minha carta?”, E então toda essa complexa árvore de edições sai da minha cabeça.
Quando trabalhamos, entramos em um estado alterado de consciência, nosso cérebro constrói modelos complexos que explicam como o código funciona. Quando o código é escrito por uma pessoa (por exemplo, em um projeto de inicialização ou de código aberto), geralmente, além do modelo na cabeça e do modelo no código, não há nada. Isso permite que você trabalhe muito rapidamente - basta traduzir o que você tem em sua cabeça em código. O modelo que está na cabeça está correto; portanto, se algo estiver errado no código, basta olhar para ele, comparar com o que está na cabeça e o erro será imediatamente visível. E quando você encontra um bug, geralmente isso mostra que você ainda não pensou em nenhum aspecto e atualiza o modelo primeiro e depois o código.
Há um
post maravilhoso
de Jessica Kerr , onde ela, entre outras coisas, diz que a invenção é como descer uma montanha, e a análise é como subir uma montanha. Gostamos de escrever código, é interessante e fácil: você começa do zero e inventa algo novo, resolve problemas, escreve algoritmos, métodos e classes. Mas ler o código é difícil - na sua frente, desde o início, há uma enorme variedade de códigos de outras pessoas, e esse é um personagem completamente diferente.
Portanto, em muitas organizações você pode observar um fenômeno que Alberto Brandolini chamou de “mestre das masmorras”: essa é a pessoa que escreveu a primeira versão do sistema. Eu era essa pessoa no Spotlight - escrevi uma parte significativa da primeira versão sozinha e em um ASP clássico, sem documentação e sem testes de unidade. Eles começaram a fazer filmes com essa ferramenta, fizeram Guerra nas Estrelas, ganhamos dinheiro e tudo foi ótimo. Mas então começamos a contratar novos funcionários que, a princípio, não conseguiam descobrir como tudo funcionava, e por dois a três meses eles tiveram que se familiarizar com o sistema.
Logo, começaram as discussões sobre a portabilidade do sistema para o .NET, porque o ASP clássico não é confiável o suficiente e não é rápido o suficiente. Tais conversas sempre serão - não importa o código que você escreva, alguém insistirá que ele precisa ser reescrito. Isso acontece porque essa pessoa não entende seu código, e escrever um novo código é mais interessante do que investigar o antigo. Programar é um trabalho que traz prazer, realmente gostamos. Portanto, é bastante natural que, sendo apresentada uma escolha, nos apóiemos na opção que é mais fascinante.
O dono da masmorra é uma pessoa que conhece todas as armadilhas do código. Ele sabe sobre o botão que não pode ser pressionado, caso contrário, o aplicativo falhará; aquele em que TODO de 2014 está pendurado, ao qual ninguém chegou às mãos. Em nossa indústria, aprendemos a não criar mais esses sistemas. É por isso que eu amo eventos como DotNext, grupo de usuários, comunidade e StackOverflow: quando você inicia um novo projeto, você será informado definitivamente de que precisa escrever testes, fazer especificação por exemplo, integração, monitoramento. Portanto, nosso futuro são microsserviços sem servidor em F # com cem por cento de cobertura do código com testes.
Mas o problema não é o software que temos que escrever: nosso mundo já está cheio de software. E, se você imaginar esse software na forma de uma pirâmide, o F # sem servidor ocupará apenas o topo. Um pouco mais será o ASP.NET, de alguma forma coberto em testes. Ainda mais - Visual Basic no Windows XP. Mas a plataforma de desenvolvimento de produtos comerciais mais popular da história são as planilhas do Excel.
Estou pronto para apostar que toda vez que você compra uma passagem de avião ou fica em um hotel, de uma forma ou de outra, seu nome aparece em algum tipo de planilha do Excel. O desenvolvimento através de testes não leva em consideração essa enorme bagagem de código já escrito.
Mas por que insistir em reescrever código antigo? No começo, as pessoas não gostam do ASP clássico e desejam reescrever tudo no .NET. Acontece que você precisa reescrever tudo na versão 4.5, 4.6 e, em seguida, .NET Core. O JQuery não é bom; portanto, você deve definitivamente mudar para Angular, após o qual a linha React, depois Vue, chegará.
Suspeito que pelo menos uma das razões aqui esteja na busca da moda. Todos nos comunicamos, e uma parte significativa do trabalho da mais alta qualidade em nossa indústria foi realizada porque os autores queriam obter reconhecimento e respeito pelas pessoas de sua profissão. Parece-me que em nossa indústria existe um vício excessivo em tudo que é novo e brilhante, e as linguagens de programação estão sujeitas às tendências da moda. Afinal, aqueles em que a moda passa, por si só, não mudaram de forma alguma, todas as suas vantagens permaneceram as mesmas.
Imagine que existem dois currículos à sua frente:
Não há dúvida de qual deles será melhor para eu trabalhar em problemas realmente importantes. Mas se você conversar com pessoas de RH ou com pessoas que acabaram de concluir um curso de programação, verá que elas podem ganhar muito dinheiro com as habilidades do primeiro programador e consideram obsoletas as habilidades do segundo. Mas eles não estão desatualizados - ainda existem muitos problemas nos quais essa pessoa pode trabalhar.
Eu acho que uma das razões para essa atitude é que as pessoas estão assustadas. Alguns de meus colegas deixaram nossa equipe porque queriam trabalhar no Angular ou no NodeJS. Quando perguntei a eles por que eles precisavam, eles responderam que, se continuarem trabalhando apenas no .NET, depois de dois anos não conseguirão encontrar trabalho. Eu respondo a eles: pessoal, nós com o nosso .NET ajudamos a fazer Star Wars! E eles dizem: sim, mas ainda não é angular.
Não me interpretem mal, eu respeito a sua decisão. Não se pode falar de corrupção, apenas as pessoas se preocupam com o futuro e o futuro da família, se precisam procurar trabalho. E em nosso setor, esse problema de segurança é geralmente interpretado no sentido de que você precisa aprender tudo do zero todos os anos e meio, caso contrário, perderá a competitividade. Frequentemente, estamos muito mais interessados em tecnologia do que em nossa capacidade de resolver problemas.
Além do medo de ficar para trás e se tornar obsoleto aqui, na minha opinião, o medo desempenha um papel importante na mudança de um sistema que você não entende. Eles fornecem um código do qual você não conhece nada, mas se algo quebrar, será de sua responsabilidade e, se cair no meio da noite, eles o acordarão. Daí o medo surgir.
Como sabemos pela mesma Guerra nas Estrelas, o medo leva à raiva, a raiva leva ao ódio, o ódio leva ao sofrimento, o sofrimento leva ao JavaScript. Como trabalhamos com nosso medo e o medo de nossos colegas? Na minha opinião, existem três aspectos principais:
compreensão ,
confiança e
controle .
A confiança é a mais simples e a mais difícil das três. Confio neste laptop porque ele nunca caiu durante uma apresentação. Assim que isso acontecer, minha confiança nele desaparecerá. No idioma inglês, há um ditado: "a confiança é conquistada gota a gota, mas perdida por baldes". Depois de um mês trabalhando com uma pessoa, você estará pronto para admitir que ele pode ser bem versado nos negócios dele; em dois, você dirá que ele é bem versado; em três, você concordará que ele conhece muito bem os negócios dele. E depois de três meses e um dia, a vulnerabilidade às injeções de SQL será revelada em seu código, e você dirá: "Ah, eu sempre disse que ele não tinha utilidade".
Confiar em outras pessoas é sempre difícil, porque sempre significa abrir mão de algum grau de controle. A confiança no código também é um tópico importante. Depois de trabalhar com o sistema por um certo tempo, você quer acreditar que ele funcionará de acordo com suas expectativas. Seus sistemas operacionais são estáveis e confiáveis, e você espera que eles não caiam. Você confia nos bancos de dados de suas informações e espera que eles não os percam. Você espera que os provedores de nuvem garantam a operação contínua do seu site e não venda as informações de seus clientes no mercado negro.
Não existe uma maneira rápida de ganhar confiança. É verdade que a confiança é transitiva: se eu confio em você e você confia em outra pessoa, provavelmente também posso confiar nessa pessoa. Se eu ouvir a sua opinião e você achar que pode confiar na Amazon, AWS, Azure ou Google App Engine, eu estarei pronto para acreditar que esses são bons serviços. Mas não há maneira rápida de ganhar confiança.
Vamos para o
entendimento . Na universidade, estudei ciência da computação por três anos. Se os engenheiros civis seguissem o princípio subjacente à nossa educação, no primeiro ano eles construiriam galpões de madeira, no segundo - metal e no terceiro - vidro avançado.
No primeiro ano, escrevemos pequenos programas no Lisp, no segundo - pequenos programas em Java, no terceiro - pequenos programas em Scheme e Prolog. Não escrevemos grandes programas e, mais importante, não tentamos descobrir.
Mas os engenheiros civis não são ensinados pelo exemplo de galpões, são forçados a entender arranha-céus, pontes, sociedades filarmônicas e edifícios como o que estamos agora. Esses alunos aprendem com os projetos maiores e mais impressionantes do setor. E se eles estudassem de acordo com o mesmo princípio que ensinam ciência da computação, o aluno, diante de uma ordem real de arranha-céu, não pensaria em outra coisa senão colocar galpões em cima um do outro até que as torres Petronas aparecessem.
É nessa situação que um aluno que conclui um curso de ciência da computação se encontra e recebe a tarefa de escrever um sistema de compras comerciais distribuído. Uma parte significativa do software existente foi escrita aproximadamente da mesma maneira. As pessoas que o escreveram não eram irresponsáveis, mas simplesmente inexperientes. Eles fizeram muito bem tudo o que fizeram na universidade, e isso criou uma falsa autoconfiança. Era exatamente o que eu era ao mesmo tempo e, tenho certeza, muitos de vocês eram iguais ao mesmo tempo. Agimos assim: escreva uma página da web, faça um link para outra página e depois outra, copie o código e todos ficarão felizes - nossos clientes têm um produto, nossa empresa tem dinheiro, temos um bônus. Cinco anos depois, você olha para esse pesadelo e pensa: como isso poderia ser escrito?
Parte do problema é a capacidade de aprender software. Engenheiros civis são bons em estudar edifícios, engenheiros de aeronaves são bons em aprender sobre aviões. Pegue a literatura: em Guerra e paz, pode haver 45 mil falas (dependendo da publicação). Este é um dos maiores livros do mundo, requer um estudo muito sério de pessoas envolvidas em críticas literárias. Em outras palavras, estudar um objeto tão grande é um trabalho. O tamanho da peça mais longa de Shakespeare, Hamlet, é de 6 mil linhas. Agora pense: o kernel Linux é três vezes maior que Guerra e Paz. E estamos falando de um código muito compacto, bem organizado, com extensa documentação e uma grande comunidade. No entanto, entender isso é semelhante a ter que entender “Guerra e Paz” três vezes.
Veja este gráfico, que mostra o número de linhas nos livros Hamlet, Moby Dick, The Brothers Karamazov, O Senhor dos Anéis, Atlas Shrugged e War and Peace, bem como os kernels Linux e Mono .
Essa proporção parece realista para você? Por favor, perdoe-me por enganá-lo. Este gráfico é realmente exponencial.
Um gráfico de linhas no próximo slide:
A idéia aqui é muito simples: o software é enorme, apenas sentar e ler é impossível. Pedir a alguém para se familiarizar com o kernel do Linux é semelhante a pedir para uma pessoa ler Guerra e Paz, Atlas Shrugged, O Senhor dos Anéis e todos os Harry Potters seguidos. Imagine que você veio para uma nova empresa e eles informam, desde o limiar, que você precisa estudar todos esses livros, e só então você terá permissão para o código. Claro que não.
A leitura do código pode ser muito útil - você pode entender como alguns padrões funcionam e aprender alguns exemplos. Mas você não pode descobrir um sistema grande se o ler da maneira que lê um livro. Talvez essa abordagem tenha algo nobre, mas não leva a nada, como me parece. Há muito código e está escrito pior do que esses livros.
Se apenas ler o código é ineficiente, como estudá-lo corretamente? Lembre-se de Richard Feynman, Prêmio Nobel de Física. Para ele, a questão do ensino de ciências era de grande importância. Ele acreditava que era necessário ensinar às pessoas não a ciência, mas como fazer ciência corretamente. Ele foi convidado para a Universidade de São Paulo no Brasil, porque no Brasil os alunos recebiam notas muito altas, mas ao mesmo tempo não era possível estabelecer uma produção de alta tecnologia. Feynman foi convidado a ajudar a descobrir qual era o problema.
Por vários anos, ele veio ao Brasil todos os anos por várias semanas e conversou com os alunos. Ele viu que os estudantes brasileiros sabiam perfeitamente bem, por exemplo, o nome do fenômeno que ocorre quando a pressão é aplicada a um corpo cristalino - triboluminescência. Mas nenhum deles sabia que, se você esmagar um pedaço de açúcar com um alicate em casa, em um quarto escuro, verá faíscas deslizarem - e isso é triboluminescência. Feynman explicou que os alunos eram treinados apenas em livros didáticos para passar nos exames, mas não fizeram nenhum experimento.
Na minha opinião, isso contém uma lição importante para a nossa indústria. , . , , , . , .
—
. , , , .
—
. , , . , , - .
. ,
.
.
, , .
, — , , . , , - , ? .
- , , - . .
- «I love LAMP», , , . — , , , . : , , , .
, , , . , . , DLL. , , . , — , . , , — .
— ? ? -, « - ». , , . , , . , , Wi-Fi. Wi-Fi , , , . : , , — ? E assim por diante
, , . , , , .
, . , , DLL api.payments.mycompany.com. DLL, , , , , DLL , .
: .
,
: , . . , : , .
. , , . , , . : , , , . , - , . .
Spotlight, ASP Amazon Web Services. , GitHub - « ». , , , , .
- , , . Windows 2016 , ASP, 2003 .
, , , «» , « » Windows 2016 , . ASP.NET MVC 2 , , 3, 4. DLL, , ASP.NET MVC 2, - - microsoft.com, , , Nuget , . Program Files. ASP.NET MVC 2, , .
, . , , - . , : , -?
: , , -?
, , , , . - — -, , . — . , !
, , , - — , .
, . 50 000 , . — 100 000, 200 000… , Int32. , , - id -. , - , , , int, .
, , , . — . , , , .
, , . , , 32 64, . , , . . , , , . , , . , , , .
, 80- 90-, -, , . , . , .
. , — , . , , , , . , .
, . , , . , , . , — « » . , , , . : «, - ?»
, - — , . , , . , ; , — , . . , , . , .
, . , , . , . , . , , , , — , 12 , , , 3 .
, , , . , . , , .
, — ? «definition of done»?
, , GitHub , , , .
, . , . Google Analytics , , . . - , . «», , . — , . , JavaScript, . , .
, , — , . — , 20 . — , .
: , . , . , . GitHub, . - , .
: , .
-. , , , , , , , COBOL. MUMPS? , . , 1960- , 26 . — . , , - .
- , « -» « ». .
:
(control), (alter) (delete) - .
.
, : DotNext 15-16 . .NET- ( -10 ), — , .NET Foundation. , — .