A métrica nos ajuda a padronizar código. Quem nunca teve acesso a um código em que o desenvolvedor cria 10 construtores para uma classe, 10 ifs um dentro do outro, métodos com 20 parâmetros e outras práticas que só prejudicam a leitura do código? Pois então, com as métricas podemos definir quais os limites que a empresa utilizará, por exemplo: uma classe não poderá ter mais do que 4 construtores, poderá ter no máximo 400 linhas de código e os nomes dos métodos devem ser escritos conforme a convenção Pascal, que diz que o nome de um método deve ter a primeira letra maiúscula.

Cada métrica tem os seus limites e estes poderão ser customizados, conforme figura abaixo:

Após executar as métricas os resultados serão analisados através do gráfico de Kiviat, onde o circulo vermelho é o limite definido anteriormente e todos os pontos foram deste círculo mostram que parte do código está rompendo as métricas.

Cada classe poderá ser analisada separadamente. Desta forma, será mais fácil identificar as violações de métricas. Com a auditoria e métrica, o desenvolvedor poderá entregar um código e uma aplicação com mais qualidade tanto interna quanto externa. Tudo isso você pode executar no seu código em qualquer versão a partir do 2006.

Recomendo como leitura adicional outros dois posts:

• Auditanto seu código Delphi – http://www.andreanolanusse.com/pt/auditando-seu-codigo-delphi/
• Melhorando a qualidade do seu software Delphi através da UML – http://www.andreanolanusse.com/pt/melhorando-a-qualidade-do-seu-software-delphi-atraves-da-uml/

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

Quando falamos em qualidade, sempre nos preocupamos em apresentar ao cliente um software de alto desempenho. Muitos nos dizem que não importa como o software está escrito, mas sim que funcione e atenda às suas necessidades. Na verdade, quem pensa assim está cometendo um grande erro, que pode trazer impacto lá na frente. Se você não escreve um código estruturado e depois precisa crescer a aplicação, pode acontecer de você não conseguir, pois muitos remendos foram feitos e sua aplicação não cresceu de forma estruturada. O Delphi irá contribuir, através de auditoria e métricas, para encontrar erros na sua aplicação enquanto estiver em produção e ajudarão a disciplinar os desenvolvedores a escrever códigos padronizados.

Quantas vezes você já definiu um guia de melhores práticas de codificação que evitasse que sua equipe de programadores cometesse aquelas gafes de codificação que podem tornar o código tão ineficiente quanto incompreensível?

Suponhamos que sua equipe tenha um guia de melhores práticas, a segunda pergunta fatalmente seria: Como podemos garantir que o guia está sendo seguido?

A resposta novamente seria: revisão de código (code review) e, se encaixarmos tal prática no contexto de um projeto com milhares de linhas de código, sabemos que o resultado pode ser catastrófico no que diz respeito a tempo.

Através do recurso de auditoria de código (QA Audits) do Delphi você poderá finalmente definir um conjunto de boas práticas de codificação e garantir que estas práticas estão sendo seguidas em seus projetos. Traduzindo para o dia-a-dia, você irá detectar erros que podem ocorrer na aplicação antes de ela ser executada.

A auditoria verifica se o código está em conformidade com as regras e parâmetros estabelecidos pela organização. Os resultados apresentam apenas as violações detectadas e de forma categorizada, são elas:

• Arrays e Referências
• Código duplicado
• Conteúdo supérfluo
• Desempenho
• Desvios e laços
• Estilo de codificação
• Estilo de nomenclatura
• Expressões
• Falhas de projeto (design)
• Possíveis erros

Cada item da auditoria tem uma nota explicativa representando o modo correto e o incorreto para utilização da mesma, tornando mais fácil o entendimento por parte do desenvolvedor naquele item da auditoria. Cada um desses itens pode ter seu nível de severidade alterado entre: Info, Warning e Error. Ficando a critério do desenvolvedor definir a importância do item.

Loop Body is Never Executed (LBNE)

Em muitos casos, temos rotinas de execução que envolve vários loops e é necessário depurar para ter certeza que os loops serão executados. Com a auditoria LBNE, isso pode ser detectado. O código abaixo é um exemplo simples que podemos detectar. Exemplos complexos, com diversas condições, também são detectados facilmente.

var
   x: Boolean;
begin
  x := false;
  while s do
  begin
     ....
  end;

INDEX OUT OF BOUNDS (IOB)

Esta mensagem é comum quando se tenta acessar uma posição de array inexistente. Veja abaixo um exemplo de um código que irá gerar este aviso.

var
  nloops,
  i,
  j :integer;
  matriz : array of integer;
  somatorio : double;
begin
  for i := 0 to nloops do
  begin
      somatorio := 0;
      for j := 0 to High(matriz) do
          somatorio := somatorio + matriz[i];

  end;

A auditoria apontou o erro e informa que na linha 25 existe a tentativa de acesso a uma variável que não faz do 2º loop, vamos explicar melhor.
No for da variável J, estou tentando acesso a uma posição do array ARR, apontando para a posição I do loop anterior, sendo que no for da variável J é onde está sendo percorrido o array ARR.

São mais de 200 auditórias disponíveis no Delphi, que tal executar o processo de auditória no seu código, não se assuste com o resultado :), a idéia é lhe ajudar a melhorar a qualidade do seu produto final.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse

A qualidade que é sempre solicitada no produto final, é também requisito fundamental para o software, já que é através dele que as estratégias de crescimento da empresa são sustentadas. Se você entrega um software que não tem qualidade pode comprometer o sucesso do seu cliente.

Desde o Delphi 2006 podemos utilizar a UML com todos os seus diagramas e, além disso, a utilização do LiveSource, que permite sincronização entre diagrama de classe e código.

Cada diagrama na UML tem a sua representatividade, alguns representam modelos de negócios e, portanto, não faz sentido gerar código a partir dele. Outros a representação fiel do código, por exemplo, o diagrama de classe. Abaixo, alguns dos diagramas disponíveis e suas funcionalidades.

• Use Case – é uma forma de descrever a interação entre um sistema e o mundo real, sendo que os atores que podem ser pessoas ou sistemas, representam o mundo real.
• Class Diagram – representa as classes do sistema e seus relacionamentos.
• Collaboration – utilizado para modelagem de aspectos dinâmicos de um sistema ou subsistema.
• Activity – permite representar situações dinâmicas através de um fluxo, por meio dele será possível representar o fluxo entre objetos.
• Component – utilizada para modelagem de mais alto nível, onde existam estruturas complexas. Este diagrama ilustra pedaços de sistemas, controles embutidos etc.
• State – Especifica a seqüência de eventos de um determinado objeto.

Diagrama de caso de uso

Visualizar um diagrama de classes torna muito mais fácil o entendimento sobre as classes nele existentes do que utilizar código. Vejamos um exemplo do próprio Delphi: a unit Buttons.pas tem diversos componentes dentro dela como TBitBtn, TSpeedButton e outros. Imaginem entender 1946 linhas de código para saber quais componentes e relacionamento existem entre eles. Através da engenharia reversa, fica muito fácil de entender, veja a figura abaixo.

Diagrama de Classe

A engenharia reversa pode ser feita a qualquer momento a partir do código Delphi, desta forma vemos que este recurso do Delphi auxilia e muito na evolução e entendimento do código, seja atual ou legado.

Andreano Lanusse | Tecnologia e Desenvolvimento de Software Siga-me no Twitter: @andreanolanusse