Ir para o conteúdo

diagnóstico do sistema

Auditoria de código legado: mapa do sistema, riscos ordenados e plano com preço

Acesso de leitura ao repositório, algumas horas com quem ainda conhece aquilo e a nossa plataforma sobre a base inteira, seja lá em que linguagem ela esteja escrita: COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#. Voltam um mapa de módulos, uma lista medida de código morto, um registro de riscos ordenado e um plano em fases com preços. De três a cinco dias, e o documento fica com você reescrevendo alguma coisa ou não.

Pedir orçamentoCinco campos, sem telefone obrigatório. O que você recebe é escopo, preço e data.

3–5 dias do acesso ao relatório pronto


Tudo à direita é um documento que fica com você, inclusive a versão em que a recomendação é deixar o sistema em paz.

Desconhecido

Uma árvore de fontes de tamanho desconhecido, jobs que ninguém documentou, nenhum teste.

  • source treeunknown size
  • nobody left who wrote itrisk
  • undocumented jobscron · JCL
  • no testscoverage 0

Mapeado

Mapa de módulos, código morto medido, riscos ordenados, um plano com fases e preços.

  • module mapgraph
  • dead code listmeasured
  • risk registerranked
  • migration planphased · costed

3–5 dias do acesso ao relatório pronto

Tudo à direita é um documento que fica com você, inclusive a versão em que a recomendação é deixar o sistema em paz.

Como o trabalho anda

Duas passadas sobre o mesmo sistema, uma de máquina e uma de gente, e depois uma sessão em que se discute com os achados.
  1. 01dia 1

    Acesso e entrevistas

    Acesso de leitura aos repositórios, instruções de build, agendamento de jobs e duas ou três horas com cada pessoa que mantém aquilo. Acesso travado no jurídico é o motivo mais comum de isso atrasar.

  2. 02dias 1–3

    Passada de máquina

    A plataforma faz o parsing de tudo: grafo de chamadas, fronteiras de módulo, interfaces externas, uso de banco, alcançabilidade. Tamanho raramente é o problema. O módulo escrito num dialeto que ninguém suporta é.

  3. 03dias 3–4

    Passada humana

    Um engenheiro trabalha o que a máquina marcou e o que ela não conseguiu ler, e depois confere os achados contra o que a sua equipe disse. Esses dois relatos raramente concordam na primeira passada.

  4. 04dias 4–5

    Achados e plano

    Um relatório escrito e uma sessão de trabalho: o que está morto, o que é perigoso, quanto custa uma reescrita em fases e o que faríamos primeiro se o sistema fosse nosso.

O que a plataforma faz e o que uma pessoa faz

A máquina lê cada linha e perde o contexto. As entrevistas trazem o contexto e perdem metade do código. O relatório é o que sai quando as duas passadas terminaram.
O relatório é escrito para os seus engenheiros lerem primeiro. Se ele só funciona como documento para o conselho, ele falhou.
O que a plataforma faz e o que uma pessoa fazQuem fazNotas
Fazer parsing da base e montar os grafosPlataformaTodas as linguagens da árvore, incluindo as duas que você esqueceu que estavam ali.
Medir código mortoPlataformaAlcançabilidade estática, mais traces ou logs de produção quando você consegue nos dar um período deles.
EntrevistasEngenheiroO que nunca foi escrito existe só em conversa, e vai embora com as pessoas que o carregam.
Ordenar os riscosOs doisA plataforma acha as pontas afiadas. Ordená-las exige saber que sistema custa dinheiro a você numa sexta-feira.
Estimar as fasesEngenheiroA partir de tamanhos de módulo medidos e acoplamento, em faixas, com as premissas escritas ao lado.
A recomendaçãoEngenheiroIncluindo "deixe isso em paz e conserte o seu processo de release" quando é isso que a evidência diz.

Quem lê o seu código

Engenheiros com mais de dez anos em sistemas legados e dezenas de migrações nas costas, mais uma plataforma que faz o parsing de COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#, Fortran, ABAP e um punhado de dialetos que só existem dentro de uma empresa. Entre os dois, quase nada em uma árvore de fontes chega como surpresa.


A auditoria é trabalho delimitado com preço fechado, e o documento fica com você de qualquer jeito. Descobrir nos últimos dias de uma reescrita aquilo que uma auditoria de cinco dias teria contado é a versão cara disso.

Perguntas que engenheiros fazem

Precisamos contratar vocês depois?
Não, e o plano é escrito para que a sua equipe ou outro fornecedor consiga executá-lo. As fases são descritas em módulos e interfaces em vez do nosso ferramental, que também é a única forma de você comparar propostas.
De quanto acesso vocês precisam de fato?
Acesso de leitura aos repositórios e instruções para compilar a coisa. Se você conseguir somar o agendamento de jobs e um período de logs de produção, código morto deixa de ser estimativa e vira medição.
E as partes das quais não temos fonte?
Elas entram na lista exatamente assim: um binário sem fonte, suas interfaces e o que reproduzir ou substituir aquilo custaria. Deixar isso de fora do mapa é como migrações estouram o orçamento nos últimos dias.
Quanto tempo para um sistema grande?
De três a cinco dias cobre a maior parte do que vemos. Acima de uns dois milhões de linhas, ou com mais de um punhado de linguagens na árvore, dividimos o trabalho e precificamos a primeira parte separadamente.
Vocês assinam NDA antes de mandarmos qualquer coisa?
Sim, antes do acesso, como procedimento normal. A maior parte do nosso trabalho começa sob um.

Peça o mapa do seu sistema

Conte o que é o sistema, mais ou menos o tamanho e o que levantou a questão agora. Respondemos com o escopo para um sistema desse porte, uma duração e um preço.

Pedir orçamento

Um engenheiro responde, e a primeira mensagem costuma trazer três perguntas sobre acesso.