Discussão no LinkedIn: Gerenciamento de qualidade de código ABAP

Se você não sabe, os grupos de SAP e ABAP no LinkedIn, além de conter diversas vagas disponíveis, também servem para ter ricas discussões com pessoas interessadas em evoluir profissionalmente depois que conseguiram o tão sonhado emprego em SAP.

Estou fazendo um esforço para participar mais do LinkedIn e achei uma discussão bem interessante sobre Gerenciamento de qualidade de código ABAP. Quer saber mais? Continue lendo.

Use o link abaixo para acessar a discussão dentro do grupo SAP Brazil. Você precisa participar do grupo para participar da discussão. Obviamente, o cadastro no LinkedIn também é obrigatório.

Confira um breve resumo:

…Este é um assunto interessante. Mas há de se atentar a alguns fatos que passam desapercebido quando um programa é avaliado:

Antes de mais Há duas maneiras de se avaliar a qualidade de um programa ABAP: tecnicamente e funcionalmente. Um programa é avaliado tecnicamente por algum profissional, geralmente mais experiente, que foca nas regras definidas pela empresa. Isso na prática corresponde a várias atividades, entre elas:
– Verificar nomenclatura de variáveis, programas, CTS, funções, classes etc
– Verificar que o acesso ao bando de dados é feito de forma eficiente
– Verificar que não há ocorrência de DUMPs: conversão de campos, tratamento de excesões, ABAP dinâmico etc.
– Verificar Code Inspector, verificador de programa extendido etc.
– Comentário no código
– Documentação Técnica
– Entre outros.

Estas atividades devem ser feitas *antes* das modificações serem transportadas. Isso deveria entrar na conta quando a estimativa do desenvolvimento é definida. Um profissional ABAP mais experiente não deveria fugir desta etapa pois geralmente o fato de ele ser experiente não quer dizer que ele comete menos erros de programação, mas sim que ele é capaz de os corrigí-los mais rápido. Quando algum programa existente é alterado esta etapa deveria ser realizada contemplando o programa como um todo, caso não tenha sido previamente analisado.

Funcionalmente na prática a análise é feita de forma simples. O profissional funcional ou o próprio usuário irá realizar o procedimento que precisa para ver se obtem o resultado desejado. A resposta nunca é “quase pronto”. Ou satisfaz a necessidade do usuário ou não.

Por isso há de se tomar cuidado quando se diz que um programa está com má qualidade. Um programa que se enquadra nas regras da empresa mas que pecou na especificação funcional pode não atender o usuário e consequentemente ser definido como de má qualidade. Daí a importância das metodologias ágeis, as quais aproximam todos os envolvidos num desenvolvimento para um esforço *coletivo*.

Tenha certeza que a maioria das reclamações sobre código Z seria evitada modificando o processo de desenvolvimento ao invés de modificar o profissional ABAP. Se vale exemplos de atividades que melhoram infinitamente a possibilidade de construir algo de qualidade, eis uma lista:

– Especificações e definições de projeot realizadas juntamente com o profissional técnico responsável por sua implementação
– Construção de protótipos/versões iniciais antes de terminar a especificação funcional
– Envolver o usuário e funcional como parte integrante do processo de desenvolvimento de início a fim
– Importância a criação de dados e cenário de teste envolvendo não somente o caso perfeito (e.g O que deveria acontecer caso o programa não retorne dados? Mandar uma mensagem para o usuário? Gravar um log? Extender o critério de busca?
– Envolver mais que um profissional ABAP na hora de codificar

Espero ter ajudado

Fábio Pagoti

Alguém tem tido boas experiências com gerenciamento da qualidade de código ABAP?

Aproveite e dê sua contribuição lá também. Você será muito mais bem visto nos grupos se oferecer seu conhecimento ao invés de só pedir por vagas em aberto.