Como compreender um software legado?

[iannsp]

Eu quero sugerir uma, que é "como compreender/estudar um software legado quando você se torna membro de uma equipe de desenvolvimento?"
Essa compreensão é importante pq define o quanto você vai dominar do conhecimento contido no software e como vai interagir.

[netojoaobatista]

Eu gosto dessa linha, principalmente porque antes do software existe um negócio, um problema, que ele resolve.

A compreensão do problema que o software resolve é fundamental para a compreensão do software em si. Não é possível estudar o funcionamento do software, independentemente de ser legado ou não, se não houver uma compreensão plena sobre o domínio do problema.

Neste caso, como vocês procederiam? Não são todos os legados que possuem uma boa documentação, tanto da regra de negócio quando do próprio codebase. Fora que as vezes não há sequer um analista responsável pelo projeto e tentar entender as regras de negócio pelo código-fonte e quase ler a bíblia.

Eu uso algumas técnicas de engenharia reversa para ajudar a chegar na ideia primordial do projeto.

[jackmakiyama]

Eu penso que podem explorar também os seguintes cenários dentro desse tema como um legado:

• Bom com testes
• Bom com testes quebrando
• Ruim com testes quebrando
• Bom sem testes
• Ruim sem testes

[iannsp]

O problema de compreender o software legado parte de algo que vem inclusive antes do teste(uma ferramenta importante para compreensão se os desenvolvedores utilizarem também com esse propósito).

Entender um software legado é uma escolha baseada no seu mindset. Como seu cérebro de desenvolvedor funciona? Você é um programador que se envolve com o domínio de negócio do software ou é focado no framework técnico?

É possivel entender um software e afetar posivitamente seu funcionamento corrigindo bugs simples se você for um desenvolvedor com experiencia no domínio de negócios e também um desenvolvedor com experiencia no framework técnico. Esse inclusive é o problema, esse cara, com essa bagagem ai de experiencia, é raro.

Se você é um especialista em um framework técnico(e o software que você precisa conhecer utiliza esse framework) isso será uma vantagem para entender como as mensagens são trocadas, enfim, como é o workflow do software, mas ainda terá dificultade com o domínio(e por isso tantos profissionais experientes falam do processo de isolamento do CORE da aplicação, das regras de negócio, daquela parte do software que justifica sua escrita, seu objetivo/Dominio principal).

Se você entende do domínio ou tem o mindset de entender domínios, não tera problemas em extrair as regras e entender o objetivo do software, mas terá dificultades em entender o workflow técnico, principalmente quando ele não tem um nível de isolamente/desacoplamento ideal.

Isso é um inicio de discussão. A partir dessa ideia de mindset creio ser possível entender a abordagem necessária para finalmente entender o software legado.

[alganet]

Eu gosto da idéia de focar no mindset. Queria compartilhar a minha visão sobre isso, e ela é chata.

Só existe um puzzle. Esse puzzle é a combinação de conhecimento do negócio e ferramentaria. Entender um aspecto sem o outro é trabalho incompleto.

A cada leitura, edição ou teste de código existe uma oportunidade pra aprender incrementalmente sobre a ferramenta e o negócio. Eu acredito que essa oportunidade deve ser abraçada.

Não há como prever o que esse aprendizado pode trazer. Negócio é algo variável por natureza e cada empresa tem um e suas peculiaridades dentro do seu ramo. Ferramentaria varia drasticamente entre infra, arquitetura, código, testes, etecetera.

Pra complicar, as peças não são isoladas. Se houver a sorte de entender a arquitetura primeiro, há uma grande chance de compreender "de tabela" uma grande parte do sistema. Já trabalhei em projetos nos quais entender um aspecto central do negócio também esclareceu grande parte do "puzzle".

Sem medo de ser repetitivo: um desenvolvedor não deve desligar o faro para regras de negócio quando for manter ou compreender uma parte técnica e vice-versa.

Não é só disciplina pessoal. Se o trabalho de entender um legado envolve um time, é importante organizar o time pra trabalhar em conjunto e não desperdiçar trabalho. Imagina o quão chato seria entender todos os módulos (um por pessoa) de algo só pra no final compreender (em grupo) que a arquitetura define que todos funcionam da mesma forma?

Cada aspecto pode ser uma vantagem ou desvantagem. A documentação pode ser boa ou ruim, atualizada ou não. Os testes podem ser esclarecedores ou podem congelar a implementação. A arquitetura pode reduzir esforço ou gerar bloatware. E tudo isso pode variar dependendo do negócio, porque eles estão no mesmo ecopo de problema. Em outras palavras: uma arquitetura boa pra um negócio pode ser ruim para outro.

Arquitetura, infra, código, metodologias e praticamente tudo que rodeia ferramentaria parece sofrer do efeito da moda. Eu prefiro não confiar jamais que minha técnica resistirá ao tempo. Quando as coisas pararem de mudar, podemos começar a colocar regras. Até lá, prepare-se pra ver de tudo.

Em primeiro lugar, quero parabeniza-los pelo ótimo hangout de ontem, 11/02, em segundo lugar tenho um apontamento que senti falta sobre o assunto tema abordado. Pode ser que tenha compreendido errado, mas o hangout tomou como base um sistema legado que usa o paradigma orientado ao objeto, estou correto? Mas sistemas realmente antigos, ou melhor dizendo críticos, são realizados muitas vezes em linguagens que não possuem paradigma orientado a objeto e/ou funcional. Exemplo clipper, cobol etc.

Neste caso como fariam para compreender esse software? Usar o software e compreender o domínio do mesmo é suficiente? Mesmo que as vezes, existam regras específicas que fora implementado por um especialista a muitos anos atrás e o mesmo não encontra-se mais na empresa.

[alganet]

Olá @camilotx, eu vou tentar explicar o que eu sinto em relação a esse problema.

Em algum ponto do hangout houve a discussão sobre usar o software como o primeiro passo para entendê-lo. Abrir o software, ver como ele funciona, ver o que ele faz.

Existem sistemas que dão bastante liberdade para abrir e mexer. Alguns não tem nenhum tipo de ambiente de teste, ou seus ambientes de teste não refletem o que acontece quando o software é colocado em produção.

Vou assumir o pior cenário: não há como ter um ambiente local. Nesse cenário, todo o código tem sido desenvolvido diretamente via vim no servidor, e nunca ninguém rodou uma cópia do software em uma máquina isolada.

A primeira coisa nesse cenário seria ver o que é necessário para criar um ambiente de testes seguro para rodar esse software. Para abrir e usar, mas também poder quebrar e aprender sem medo.

Criar esse ambiente de testes em um software que não tem ou perdeu sua capacidade de isolamento requer aprendizado. Requer conhecer como o software persiste dados, como ele se comunica com o ambiente e com a rede e quais abstrações ele usa.

Esses aspectos são importantes para os testes e o aprendizado de um software desconhecido. Um software pode ter ambiente de testes isolados, mas os dados de teste podem não gerar os casos que fazem bugs aparecerem em produção.

Quando você conseguir rodar o software, se for pra web, você terá que entender como ele se comunica com o HTTP. Isso é uma grande vantagem. Se não fosse a web, você também teria que descobrir qual protocolo o software usa.

Em uma primeira avaliação, eu veria quais URLs são chamadas quando eu uso o sistema e para onde a requisição foi enviada no código. Veria o fluxo dos dados do HTTP para baixo, e se há um padrão entre as coisas que o sistema faz para o usuário e as coisas que ele faz por trás.

É nesse ponto que camadas e arquitetura se tornam relevantes. Nós expressamos domínio usando abstrações (que convertem as coisas em bits e eletricidade etc). Classes, objetos, funções e tudo mais são estruturas que fazemos para não ter que trabalhar com binário (somos bem ruins nisso). Algumas abstrações abrem muitas portas (saber que um sistema separa camadas, por exemplo, dá muitas informações sobre como ele funciona).

Se existem partes desconhecidas do domínio ou do software, existe um termo que se aplica aos dois casos: engenharia reversa. É o melhor termo que eu conheço para entender como mecanismos desconhecidos funcionam.

É esse tipo de explicação que eu senti falta no Hangout, @alganet. Apesar de ter sido explicado que o ideal é compreender as regras de negócio, achei que ficou um pouco implícito o assunto.

Na minha opinião, acho interessante explicar técnicas de reengenharia e engenharia reversa como PRE/OO ou FaPRE/OO (processo de reengenharia Orientada a Objeto) que visa justamente conduzir sistemas procedurais em orientados a objeto. Técnicas essas que não considero regras, mas sim propostas para uma melhor compreensão do legado.