A verdade é que muitas dificuldades poderiam ser evitadas se os profissionais adotassem padrões ou respeitassem os já existentes.
Quantas vezes você já precisou dar manutenção em algum programa e percebeu que o nome de uma variável não tinha nada a ver com o conteúdo para qual estava sendo utilizada?
Já aconteceu de precisar de uma função para algo específico? E então, pela descrição você tem a impressão de que encontrou o que precisava, mas quando olha o código percebe que a função serve pra outra coisa...
Pois é, são situações comuns que acontecem com frequência. Isso porquê o programa está apenas atendendo o objetivo proposto. Mas como fica a questão de organização e de planejamento??? E se precisarmos alterar o programa mais tarde??? E se houverem colaboradores novos que não sabem como foi feito???
O que quero dizer com Padrões de Nomenclaturas
Quando uso a palavra "Padrões" estou me referindo a algo que deve se repetir sempre, que devemos ter como prática habitual.
E quanto uso a palavra "Nomenclatura" estou me referindo a nomes em geral. Seja de variáveis ou de objetos declarados. Seja de programas, funções ou grupo de funções. Seja de uma classe, de uma
BAdI ou de um Enhancement. Seja de um domínio, de um elemento de dados, ou de uma tabela. Enfim, nome de qualquer declaração ou objeto que seja possível criar.Quando junto as duas palavras quero dizer que devemos ter um padrão para dar nomes. Parece frescura ou perfumaria, mas na minha opinião não é.
Exemplos de aplicação
- Com módulos de função
Dois ABAPs estão trabalhando no mesmo projeto para área de recebimento de mercadorias. Um precisa customizar a atribuição de documentos na MIGO, enquanto outro precisa alterar o cálculo de vencimento na MIRO. Os dois estão desenvolvendo funções. O primeiro cria sua função com o nome ZMF_ATRIBUICAO_DOCUMENTO. O segundo cria sua função com o nome ZFMMMIRO001.
Se analisarmos os dois casos individualmente, ambos parecerão corretos. O primeiro vai alegar que colocou MF por ser um módulo de função, e ATRIBUICAO_DOCUMENTO por ser exatamente o que ele está desenvolvendo. O segundo vai alegar que colocou F por ser uma função, MM pra identificar o módulo funcional, MIRO pra identificar a transação e 001 por ser primeira função usada dentro da MIRO. Ótimos argumentos, porém padrões completamente diferentes. Seria muito melhor se utilizassem o mesmo padrão.
- Com declaração de variáveis
Você precisa fazer uma melhoria num programa, aparentemente muito simples. Uma determinada soma deve deve ser exibida na tela junto com outras informações. E então vem a dúvida: onde, como e com que nome vou criar minha variável de soma.Você decide olhar outras variáveis já existentes e percebe que metade delas foram criadas como local dentro do FORM e a outra metade criadas como geral fora do FORM, mas que não existe identificação nominal entre elas. Algumas possuem o tipo no nome e outras não. Bom, já que não há padrão você decide, continuar sem ele e, declarar sua variável de qualquer forma.
Se houvesse um padrão para ser seguido não haveria dúvidas.
Como definir um padrão
Algumas empresas possuem um padrão pré-definido de como devem ser as nomenclaturas, e até um profissional de Quality Assurance que fica responsável por verificar se os padrões estão sendo seguidos. Se este não é o seu caso, tenho três sugestões.
A primeira, e também ideal, é sugerir ao seu gestor. Mostre a ele exemplos de como o código ficaria mais limpo e fácil de entender, e também os ganhos em relação a manutenção. O melhor dos casos é que seu gestor abrace a ideia e determine que os padrões deverão ser seguidos por todos.
A segunda é sugerir diretamente aos colegas de trabalho. Isso quer dizer que você não tentou a primeira sugestão, ou que seu gestor não tenha dado importância. Muitos preferem trabalhar de forma mais organizada, e por isso acredito que não seria difícil ter o consentimento da maioria. Mesmo não sendo algo oficial e determinado pelos gestores, informalmente é possível se organizar entre os ABAPs.
A terceira é desenvolver o próprio padrão. Se nem seu gestor, e nem seus colegas de trabalho acharam isso importante, não deixa que isso te impeça de fazer com que seus códigos fiquem mais organizados. Desenvolva seu padrão pessoal de nomenclaturas e comece a aplicá-los em seus projetos e manutenções. Só porque ninguém faz, você também deixará de fazer?
Exemplos de padrões
- Para declarações em códigos
- Se for criar uma variável local inicie sempre com "L_" e se for geral sempre com "G_".
Colocar também um "C_" caso a variável seja declarada com um elemento CHAR ou um "N_" caso seja declarada com um elemento numérico.
- Se for tabela interna iniciar sempre com "T". Pode-se ainda trabalhar com variações de "TL" para tabela local e "TG" para tabela global.
- Começar com "W" para work areas.
- Começar com "C" para constantes.
- Começar com "R" se for um range.
Enfim, poderia listar vários. Pense em informações que possam ajudar a mapear as declarações de forma instantânea, sem precisar chegar propriamente até a declaração.
- Para programas
Começar com "Z" e seguir com o módulo abreviado em duas letras (MM,SD,FI,WM,CO,etc). Depois uma descrição breve, ou então um numero sequencial. Tudo isso separado ou não por "_".
- Para funções
Pode-se seguir a mesma linha dos programas, mas iniciando com "ZF" ou com "ZMF".
- Para tabelas
Pode-se seguir a mesma linha dos programas, mas iniciando com "ZT" ou "ZTB", ou ainda "ZTAB".
Lembre-se que em cada lugar ou empresa os profissionais podem estar mais acostumados com um ou com outro padrão. Não tenho interesse em fazer com que alguém use os padrões citados aqui, mesmo porque citei poucas situações. E também, isso deve ser algo decidido em conjunto ou algo com que você se familiarize mais.
Quero deixar claro pra todos que nesta postagem não estou me baseando em nenhuma documentação oficial, muito menos em determinações da SAP ou de outras empresas. São apenas dicas de algo que funcionou muito bem pra mim e que, acredito, pode também ser útil para outros profissionais.
Um grande abraço e até a próxima!
Postar um comentário