Qualidade, performance, SLAs e variáveis

Como nomear variáveis, objetos, funções e outros componentes [boas práticas]

Salve jovem padawan, foi uma semana corrida, tive que dar aquele gás para finalizar alguns bootcamps, que estavam próximos ao dead-end, precisava publicar alguns projetos e nesta maratona, acabei deixando os artigos em stand-by.

Vamos retomar por hoje, falando sobre um tema bem melindroso, que gera muita discussão e dor de cabeça nas equipes de desenvolvimento. Para isso vou explicar como era no passado, quando comecei a programar em Clipper, naquela época, não existia um padrão, líamos o código numa revista ou copiávamos trechos de um livro e por tentativa e erro, chegava há um resultado aceitável, bem diferente, ne?

Neste interim comecei minha formação a sério, como secundarista num colegial técnico em PD (Processamento de dados para os neófitos), nisso fui aprendendo um pouco sobre normalização e técnicas de programação “profissionais”, naquela época existia a distinção entre programador e micreiro, os cabeças brancas devem lembrar dessa época sem lei, onde era só sentar o dedo desalmadamente no teclado.

Tudo mudou quando entrei numa academia Jedi de Mainframe. Com codificação papel e caneta numa folha de programação, regras e mais regras para codificar, inúmeros formulários e workflow Uma janela foi aberta, e vislumbrei um mundo novo, organizado, cheio de normas e regras, sendo sincero, tirou um pouco do encanto em programar, era restrição demais, proibições que não faziam sentido e uma burocracia enorme. Somente com os anos e que entendi e percebi a realidade.

Em grandes ambientes com mais de 1000 devs, codificando e trabalhando, gerando e consumindo dados, recursos em memória, cpu e disco, se não houver uma regra no consumo de bens finitos o caos imperara. Imagine que para criar um script (JCL), era necessário criar um fluxograma detalhado, uma transação CICS (BMS) ou Mapa Natural Online tínhamos que desenhar o mapa e enviar para um comitê de telas para aprovar a navegação e as teclas de funções, um campo ou índice na tabela do Banco de Dados um formulário para o DBA etc. Tudo com seus rituais e workflows complexos. Saiba mais em

Normas e procedimentos

Pense nessa problemática, nem sempre o criador do programa irá trabalhar sempre com o mesmo código, cliente ou produto, acontecera que outros devs, necessitem consumir suas informações, através de uma chamada a função e processamento, talvez em casos extremos para solucionar um abend ou mesmo numa manutenção evolutiva.

Pense na escrita do código com variáveis com nomes nada explicativos, sem indentação, sem espaçamento e muita sujeira de código, deixado por um programador preguiçoso e nada inspirado?

Com isso em mente, grandes instalações criam diversas normas e procedimentos para garantir a codificação limpa e produzir software com Qualidade dentro dos SLAs.

Qualidade em Software

O que é um bom código? De forma resumida é um código de fácil leitura, com espaçamento entre áreas importantes, indentado, com comentários claros e explicativos, variáveis logicas e criadas no local correto.

Um programa que consuma a memória de forma espartana, sua escrita seja otimizada e que não exista trechos de código inúteis deixados como rabicho, performático pensando que um ciclo a mais de CPU multiplicado por milhões de acesso, minam a lucrativa da empresa.

Visando estas melhorias, existem departamentos de Qualidade de Software, que usam ferramentas para verificar código entregue, acompanhar e monitorar performance em CPU, Memória, acesso a HD, trafego de REDE e etc. Visando encontrar gargalhos e buracos negros de processamento.

Documentação

Hoje em dia com metodologias ágeis e processos dinâmicos, a documentação acabou sendo relegada a segundo plano, mas continuam sendo muito importante para auxiliar nos levantamentos de requisitos e analise de evoluções do software.

Um documento muito útil é o catálogo de objetos, onde rapidamente encontramos o programa e sua função, auxiliado peo dicionário de dados com os nomes das variáveis importantes do sistema. Cada cliente terá suas normas e padrões de desenvolvimento, um outro documento importantíssimo do cliente para todos os novos DEVs, que devem ser lidos a todos que chegam ao ambiente e irão iniciar na codificação do mesmo.

É uma boa pratica dar uma vista de olhos nos códigos prontos e ver quais os padrões, usados na casa e tirar todas as dúvidas com o analista sênior e não assumir nada, pergunte sempre. Aprimores seus soft skill, lembre-se o sistema informático é feito por pessoas, para pessoas, o computador é apenas a ferramenta. conheça um dos elementos do tríplice alicerce da informática :

Monitores de performance

Existem duas equipes distintas que irão monitorar e fiscalizar o seu código: os DBA (database administrators) e os Analistas de Produção que utilizando ferramentas especificas acompanham a evolução do software e o seu consumo dos bens escassos, normalmente enviando notificações e apontamentos as equipes responsáveis solicitando melhorias em programas.

Com a velocidade das mudanças e diminuição das equipes, a cada dia vemos um certo retrocesso a caótica época dos sem normas. Inclusive terceirizando diversas equipes e se baseando em SLA, poucos reais e de difícil implementação e cumprimento.

Lembre-se também das equipes de auditoria e inspetoria que iram fiscalizar seu software para localizar backdoors e possíveis fraudes e furtos, muito cuidado com isso, pois pode destruir sua reputação e empregabilidade em projetos futuros.

Aja eticamente, respeite as leis, seja discreto e sigiloso, sistemas informáticos lidam com dados sensíveis e vazamentos podem destruir uma empresa, principalmente com a nova lei geral de proteção de dados pessoais. Leia nosso artigo de Ética e saiba mais

Nomeando tudo corretamente

Sei padawan, que dei uma enorme volta em nosso tema, mas precisava deixar uma noção sobre o ambiente, sobre a problemática e a quantidade de equipes, que irão trabalhar com seu software.

Uma variável tem que ser explicativa pela sua função, pois ao fazermos teste de mesa e lermos o código temos uma noção geral sobre a sua funcionalidade. Leitura fácil e fácil localização dentro do código. Por isso foram criados diversos métodos para criar nomes de variáveis: Camel Case, Snake Case, Kebab Case, Pascal Case e etc, apresentadas anteriormente e temas de um artigo anterior.

Cuidados especiais ao usar caracteres e fontes, lembre-se que nosso sistema alfabético possui letras muito parecidas, que numa olhada apressada confundira e induzira a erros de simpatia.

Atenção! Perigo com o O e 0, 1 e l, I l e outras variantes, garanto a vocês ,que o uso incorreto de caractere ira acarretar em erros e horas de dor de cabeça tentando localizar o culpado por gerar erros e anomalias, gastara tempo precioso lambendo papel e dando testada no monitor.

Use e abuse das constantes, evite codificar valores diretamente no código. Exemplo

Não use: Salario = salario * 0,10

Mas sim :

Int Indice-Reajuste = 0,10 Salario = salario * Indice-Reajuste

Evite código hermético

Var001 = var001 * var002 - var003

Seja claro

Salario = ( Salario * Indice-Reajusto ) – Desconto_Previdenciario

Seja camarada e pense sempre no próximo DEV que irá trabalhar em seu código, sem conhecimento prévio das reuniões e definições.

Use comentários, mas não abuse

Quando for iniciar um programa uma boa pratica é criar um header informativo com comentários informando sobre o programa e sua função.

Exemplo

// Programa GAP3210 // // Batch da rotina de calculo de dividendos aos acionistas, acessando rotinas PSDATA para calculo de data e // CTDIARIA para contabilização dos dividendos. Acesso tabelas de movimentos acionários // // Autor: RLACOSA – REALPLAN // // Data : 2021-07-31

A partida quem chega em programa saberá suas funções básicas e necessidades, rotinas acessadas e tipo de processamento.

Identifique os tipos de variáveis

É uma recomendação que ajuda bastante os DEVs, usar um padrão que identifica o tipo de variáveis e seu uso, mas fique atento a respeitar as regras de nomeação da instalação onde você esta trabalhando, lembrando que num mundo globalizados, as vezes, será necessário usar nomenclaturas anglo-saxonicas.

“AUX-” para variáveis auxiliares

Exemplo: AUX-Texto-Intro

“CTD-” para contadores

Exemplo: Ct-Ativ-Padrao

“FLG-“ para flag (variável logica) para indicar o status de alguma rotina

Exemplo: Flg-Fim-Arquivo

“REG-“ para identificar que se trata de um registro

Exemplo: Reg-Header

“Arr-” para identificar um array

Exemplo: Arr-movim-acionistas :

“TTL- para identificar um totalizador

Exemplo: Ttl-salarios-pagos

“TAB-“ para identificar tabelas de banco de dados

Exemplo: Tab-Funcionario-Badge

“CONST-“ para identificar constantes

Exemplo: Const-taxa-de-juro

Use nome que clarifiquem o uso e auxiliem a leitura, afinal o programa esta em linguagem de alto nível justamente para humanos entenderem o que o programa faz e deve fazer.

Comentário

Todo comentário é bem-vindo, lembre-se são as dicas e ajuda para o programador seguinte, lembre-se que as vezes regras de negócios, fórmulas matemáticas e função obscuras, tenha especial atenção:

Parâmetros necessário para utilizar sua função, rotina, subr-otina e procedure;

Formula matemática com inúmeras variáveis;

Função interna dentro do programa;

Chamadas a rotinas externas;

Gravação de log;

Validações diversas;

Uso de constantes;

Informação útil sobre estrutura de arquivos, tabelas de SQL etc

A função primordial do comentário é ajudar a próximo mão que irá trabalhar no seu código, nunca sabemos quando um erro bizarro, ira acontecer, imagine o cenário em que o jovem padawan, deve trabalhar sozinho numa madrugada, feriado ou final de semana, para solucionar um problema no software , com uma SLA cruel e tenebrosa.

Ops, jovem padawan, perdoe o tiozão, citei inúmeras vezes, mais uma sigla “SLA”, assumindo que saiba o seu significado, veja o perigo das assunções, surgiu um conceito novo e avançamos, para auxiliar um pouco, deixo um resumo e uma promessa, de um artigo explicando detalhadamente.

O que é SLA?

O Service Level Agreement (SLA), traduzindo do inglês, Acordo de Nível de Serviço (ANS), num mundo globalizado, em que estamos em constantes mudanças, muitos serviços foram terceirizados, quarteirizados, por ai a fora.

É uma regra fundamental para qualquer contrato de prestação de serviços na TI. Refere-se à especificação, em termos mensuráveis e claros, de todos os serviços que o contratante pode esperar do fornecedor na negociação.

Muitas vezes com clausulas draconianas e que levam ao limite o elo mais fraco nesta cadeia de serviços e prestadores de serviço: o DEV, que ira resolver desafios com limites apertados de tempo.

Conclusão

Foi uma pequena viagem ao mundo das variáveis, SLA’s, comentários, qualidade e performance, tentei ajudar passando um pouco de conhecimento, adquiridos em sistemas mainframes, mas facilmente reproduzíveis a qualquer área de negócio e tecnologia usada

Com isso concluo nossa pequena e modesta visita a qualidade de software e nomenclatura de variáveis. Programa lógicos, de fácil leitura e rápido debug são o sonho de todo DEV em manutenção e evolução de Software, faça a sua parte e ajude o próximo.

Para relaxar, veja essa fabulosa montanha russa no parque aquático de Olímpia-SP :

Espero que tenha gostado e aproveite para comentar o que achou, afinal sua opinião é muito importante te aguardo no próximo artigo. Bom curso a todos.

Pode me dar uma ajudinha no YouTube?