El Jefe Midnight Lunch

✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta qualidade de codigo. Mostrar todas as mensagens

sábado, 2 de agosto de 2025

Boas Praticas em Performance e otimização uma primeira olhada.

Um Café no Bellacosa Mainframe

2,167 subscribers

Boas Praticas em Performance e otimização uma primeira olhada.

Bellacosa Mainframe

4,424 followers

July 19, 2025

Falando sobre performance e otimização.

Salve jovem padawan, no artigo de hoje conversemos sobre um assunto pantanoso, que derruba 7 em 10 programadores, estou falando de performance e otimização de programas, infelizmente a pressa é inimiga da perfeição.

Como veremos no decorrer do artigo, o grande problema sempre é o fator tempo, somos todos coelhos da Alice: atrasados e fugindo da Rainha Louca, ops Rainha de Copas e no final quem paga é o programa implementado na máxima velocidade de desenvolvimento dentro possível, com uma qualidade mediana, atendendo o MVP.

Pense antes de codificar

Rascunhe seu programa em lápis e papel, desta forma consegue ter uma visão do todo, uma noção do caminho crítico e para o teste de mesa, num primeiro momento consegue-se visualizar pontos passiveis de melhoria e pontos onde o programa não se comporta da maneira espera.

Existem inúmeras ferramentas visuais no mercado, que auxiliam na depuração calculando o uso de memória, uso de CPU e gargalos do sistema, para o ambiente Mainframe existe o Omegamon e o APA. Ferramentas que em seus relatórios apresentam estatísticas fabulosas sobre os problemas encontrado no código, pontos de gargalo e tempo de execução.

Uso de memória

Cuidado ao codificar, não crie variáveis em excesso, lembre-se sempre de inicializar as variáveis no princípio do código, desta forma economizam-se ciclos de CPU gastos desnecessariamente, forçando paradas no processamento para inicializar as variáveis. Lembre-se I/O seja em acessos a discos e sub-programas externo estouram o Time.

Cuidado ao utilizar arrays e vetores, pois ao criar grandes tabelas internas estará consumindo memoria desnecessariamente e prejudicara o bom funcionamento do seu programa, principalmente em escala, quantos mais usuários maior queda de performance.

Verifique as variáveis não utilizadas, que gastam espaço em memória, pense num programa utilizado por milhares de usuários, com centenas de milhares de requisição, ao final de um ano, quanto de memória poderia ter sido economizado, quanto de processamento ou ciclos de CPU, gasto em gerenciamento de memória desnecessário. Imagine a pegada ecológica, gasto de eletricidade e CO2 liberado.

Ciclos de CPU

A pressa é inimiga da perfeição, muitas vezes criamos logica em que o programa consome desnecessariamente processamento, movendo variáveis semi-utilizadas ou mesmo sem nenhuma utilização, atente-se a código morto e rotinas que entram e saem sem agregar nenhum valor ao processo.

Pense no custo em CPU de chamadas repetida a functions, arrow-functions e programas externo, a cada parada de processo e pulo para outro programa e o próprio retorno ao programa chamador.

Trabalhe apenas com os campos da tabela que serão utilizados em outputs ou cálculos, o trafego de dados além da memória, gera gasto de CPU indevidos. Muitas vezes é mais produtivo, usar arquivo sequencial da tabela, através de unload, usar aplicativos específicos para ETL, a exemplo SORT do Mainframe.

Espaço em Disco

Em tempos de cloud computer e processamento distribuído, desvalorizávamos o impacto do processamento, em gravar dados desnecessariamente em disco, informações que nunca serão utilizadas e degradam o ambiente, obrigando a adquirir mais e mais espaço em disco.

Fazendo o programa perder milissegundos cruciais na busca da informação num disco imenso e cada vez mais abarrotado, uma política de dados é importante para evitar esse viés.

Os perigos de laços estilo While

Quando codificar While cuidado com os laços infinitos. Às vezes um teste de mesa incompleto deixa uma situação onde o FLAG de saída, pode parecer obvio, mas grandes programadores caíram em situação semelhante, um IF mal planejado e um FLAG descontrolado e surge o caos, com looping infinito ou anomalias de difícil reprodução.

Os perigos de laço estilo FOR

O perigo do FOR não é tão drástico quanto o While, mas devido a sua quantidade de uso é muito prejudicial a longo prazo, obrigando a aquisição de mais hardware inutilmente, uma solução bem simples é sair do laço assim que a solução for encontrada.

Os perigos de IF inúteis

Muitas vezes o programador está cheio de boas intenções e cria uma sequência sem fim de IFs. Mas para garantir a qualidade dos dados e o controle de fluxo do programa, porem muitas vezes são desnecessários, procure pensar numa lógica do IF master e somente se ele funciona gerar os outros testes em IF, quanto menos paradas para decisão mais performático e melhor será seu programa.

Use comandos em estilo EVALUATE, SWITCH para um controle de fluxo mais eficiente e atente-se a não usar ELSEs em demasia, dificultam muito a análise e ajudam a gerar erros de simpatia, pois às vezes confundimos o lugar do ELSE e no teste pulamos o IF.

Outro grande problema e a quantidade de paradas no processamento, obrigando o programa a funcionar como conta gostas.

Espionando programas em Mainframe

Como disse anteriormente existem algumas ferramentas fabulosas em ambiente Z/OS, o OMEGAMON e o APA monitoram e acompanham a performance de programas em ambiente Mainframe, indicando os custos de CPU / Memória e rotinas em looping e consumos/acessos diversos. Vale a pena conhecer o manual técnico e explorar esta ferramenta.

Em banco de dados DB2 existe o comando Explain que gera estatísticas de acesso e caminhos para melhorias tais como criar índices, reorg de tabelas, partição de ambientes e etc, auxiliando o DEV a criar querys mais performáticas.

Conclusão

Caro padawan, reconheço que fui superficial e que deixei pontos a esclarecer, mas o objetivo deste artigo. Foi fazê-lo pensar, a ter cuidado quando codifica, apesar das máquinas terem caído o custo, em quantidade, o uso de memória e CPU desnecessário tiram a competitividade da empresa, gerando custos ocultos e gerando prejuízos a longo prazo.

Como exercício de imaginação, pense um Banco com milhares de agências e milhões de clientes, usando os serviços 24 horas por dia, 7 dias por semana e 365 dias no ano. Quanto custara ao final do ano alguns IFs desnecessários e 2 segundos desperdiçados em loops inúteis?

Por isso pense bem ao codificar, faça teste de mesa, use papel e lápis para ajudar em seu trabalho, verifique os IF e loopings, não use campos de tabelas desnecessariamente e boa sorte.

Espero ter ajudado. Bom curso a todos.

Mais momento jabá, quem diria que já passou retrospectiva do meu 44° aniversario, tantas aventuras, tantos momentos únicos, memórias em imagens de momentos mágicos da vida do Tiozão visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=sBgA0nvtpdU

Bom curso a todos.

https://www.linkedin.com/in/vagnerbellacosa/

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

https://www.youtube.com/user/vagnerbellacosa

sexta-feira, 1 de agosto de 2025

Spaghetti Code: Crise do Software

Um Café no Bellacosa Mainframe

2,167 subscribers

Bellacosa Mainframe e o anti-design parttern

Spaghetti Code: Crise do Software

Bellacosa Mainframe

4,424 followers

July 18, 2025

Spaghetti Code um codigo sem nexo, o emaranhado de comandos que acabara com sua sanidade

#Programação para Internet
#Boas práticas
#Arquitetura de Sistemas

Spaghetti Code o anárquico mundo dos coders birutas

Não seja seduzido pelo lado negro da força e evite programar spaghettis

Salve jovem padawan, nesta fria noite de inverno, próximo da hora do jantar, resolvi comentar sobre um assunto, que numa primeira olhada, seria hilário, mas é coisa séria, gerando muita, mas muita dor de cabeça, nas equipes de sustentação e explodindo com SLAs.

Mas não se assuste, o tiozão não surtou, e nem está inventando a roda, o termo spaghetti code foi cunhado no final dos anos 70 do século passado, ninguém reivindicou a paternidade, mas acredita-se, que surgiu espontaneamente nas mentes de inúmeros devs em CPDs, espalhados pelo mundo.

Em artigos anteriores exploramos o mundo da consultoria desgovernada com as 9 Gestantes gerando um bebe em um mês, terceirizações, quarteirizações e outros males, problemas do Dr. Ivon Safe e o teorema da seringa e o bumbum, podemos dizer que o Spaghetti Code é cria destes e outras mazelas dos Centro de Processamento de Dados.

Mas não pense que é um problema do mundo mainframe, ledo engano pequeno gafanhoto, o spaghetti surge em toda a parte, onde impera o caos, porem ele causa mais estragos nas pequenas e medias empresa, em que a estrutura hierarquia, QA e analise de performance são mais brandos, mas vamos por partes, primeiro vamos as definições.

O que é Spaghetti Code?

A definição não é nada pomposa, spaghetti code é uma piada interna no mundo da informática para código ruim, para ser franco, pior que ruim, péssimo mesmo, geralmente são longos e grandes linguições de código, sem ou com pouco comentário, variáveis herméticas, laços de repetição enormes e emanharados, recheado de instruções de salto, o famoso (GoTo).

São programas legados, que todo dev se apavora em analisar e resolver um abend, tentar corrigir um erro é ato de coragem, com certeza gerara muita dor de cabeça, perdera horas e horas analisando o código com suas centenas quiça milhares de linhas, tentando decifrar o que o criador estava pensando ao criar esse programa spaghetti bizarro.

Todo CPD tem dessas crias, os DEVs conhecem pelo nome, nas rodas de café, sempre é citado e lembrando. As equipes de sustentação o evitam a todo custo, mexer nele e uma maldição, afinal ele esta quieto e funcionando, quem arriscara? Qualquer alteração pode acordar o dragão e com certeza, iras sair chamuscado desta empreitada, cuidado meu amigo a culpa sempre cai no ultimo que mexeu, e mexeu fedeu.

Saiba que neste reino dos codes catastróficos, o spaghetti não está sozinho, a todo dia surge uma nova pasta com os últimos deslizes de pseudo-programadores, existem outras delicias que enlouquecem os programadores, alguém espirituoso até cunhal o termo de "anti-design pattern", para explicar essas insanidades em bits e bytes.

Como surge um spaghetti code?

Normalmente prazos apertados e falta de acompanhamento das equipes, onde muitas empresas adquiriam software chave na mão, a preços baixos de hora-homem na codificação, como o requisito era economia e não qualidade, abre-se mão da qualidade, deixando de verificar o que estava codificado, recebendo uma caixa-preta que recebe o input, processa e devolve um output.

A softhouse, por sua vez, no afã de entregar o software acordado, dentro das limitações orçamentarias e muito trabalho a ser feito, contrata equipes juniores, estagionarios e profissionais com pouco conhecimento funcional e os deixa a própria sorte, tendo que desenrascar-se e entregar o código a tempo e a ordem.

Muitas vezes ocorre a meio do projeto desligamento de elementos seniores, principalmente quando a pressão aumenta, gerando turnovers altíssimos, a equipe que perdendo know-how valioso entra em desespero e o improviso entra em cena, tornando a coisa mais confusa e caotica, aliados a proximidade do dead-end, que acaba obrigando a equipe trabalhar além do horário, cansados e desmotivados. Afinal ninguém gosta de fazer um trabalho ruim repleto de pontas soltas.

Se não me dispersei muito apresentei alguns dos fatores criadores do spaghetti: prazo curtos (apertados e sem margem de manobra), equipe de devs inexperiente, uma equipe enxuta, com baixa remuneração, pressão do comercial que vendeu um iate e está vendo uma canoa, fata de conhecimento na linguagem por parte da equipe, falta de planejamento, falta de documentação, usuário desconhece as regras do negócio e acaba confundindo o analista de sistema que cria especificações mucho locas e é claro este projeto está fadado ao desastre.

Outra maneira de criar um spaghetti code é pegar um código muito velho e ir acrescentando novas e novas funcionalidades, que ocorrem numa vida normal do software em produção, aliada a IFs pontuais para solucionar solicitações do usuário, junte isso com o passar dos anos e suas implementaçoes tecnologicas, terás um monstrengo de código-

Lembrei de mais outra, existem ferramentas geradoras de código, onde um analisa usando linguagem natural especifica o programa e o software gera o código pronto do outro lado, funcional, porem enorme e cheio de pendulicarios que ninguém sabe o que faz.

Existem outras formas, mas seria chover no molhado, falando do mesmo de modo diferente. A única constante sempre é juntar uma equipe despreparadas, prazos apertados e ganancia de alguns elementos, que preocupam-se apenas com o OKR, pois uma vez entregue o código, ele passa a ser problema da equipe de sustentação.

Como evitar spaghetti code?

Cabe ao gestor da equipe orientar a equipe a produzir código com qualidade, isto é. Bem comentarizado, identado, performático, com variáveis legíveis e bem declaradas, tenho dois artigos falando sobre variáveis, vale a pena reler que trata sobre variáveis e boas praticas.

Tenha em mente, o código fonte é escrito por humanos para humanos, afinal um código tem vida, recebe atualizações, alterações, evolui e até mesmo falece, por isso pense sempre no próximo DEV que irá analisar e trabalhar com seu código, acrescentando ou removendo funcionalidades.

Com o passar dos anos, foram sendo criadas inúmeras metodologias para evitar código de difícil leitura e manutenções custosas, estude os design patterns e aplique codificando no estado da arte.

Conheça outros pasta codes

Alguns espíritos jocosos foram além, e dentro do universo dos spaghetti code, foram desmembrando situações caricatadas e anti-profissionai e as reagruparam em novos cods-groups, sempre seguindo a ideia de apresentar monstrengos da codificação em delicias da culinária mediterrânica, em especial “la bella cucina italiana”.

Esses códigos são de difícil entendimento e manutenção, somente um programador corajoso, ou insano-temerário ira meter a mão e sujeitar-se aos seus perigosos bugs e abendes, falando nisso você leu meu artigo sobre a origem do bug?

Macaroni code

O código do macarrão é uma analogia sarcástica da linguagem macarrônica, esse código é definido como o programa que usa uma mistura de patterns, linguagens de programaçao em um único package.

Um programa em Linguagem de alto nível, é geralmente escrito para que outros programadores possam entender e trabalhar, evoluindo o software, o macaroni code além de ter várias linguagens de programação misturadas e terem a mesma funcionalidade escrita de forma diferente, com a desvantagem de trabalhar em um ambiente computacional misto em uma única instalação com inumeros donos.

Necessita ser um Jedi com um bom conhecimento da maioria das linguagens de programação, é necessário abstraçao para entender o código do macarrão e cuidado para não perder a sanidade no processo.

Stromboli code

Um código totalmente enrolado, sem logica compreensível a primeira vista, imprima o código fonte, analise por horas e desenrole até o fim, totalmente pulverizado e codificado de maneira desleixada, bem assustador quando abendam de madrugado, improdutível e desmotivador quando a vista esta bem cansada, após uma longa jornada.

Campanelle code

Com tantas frameworks, metodologias e designs sendo criados a cada dia, algum gênio resolve inovar e usa uma daquelas frameworks inovadoras e na modinha, cheias de recursos e que ninguém conhece, sofri desse male, quando fiz o giro na Europa, cada cliente tinha a sua própria framework padronizada e os primeiros meses gastava-se aprendendo a usar a ferramenta, conhecer suas funcionalidades para poder surfar nas suas nuances.

Bakava code

Ai meu rim, os gênios da arquitetura sempre inovando e nos surpreendendo, o baklava code e bem semelhante ao lasagna code, uma base de código com muitas camadas arquitetônicas / abstratas, que exigem muitas horas de analise para conhece-lo e situar-se minimamente no codigo.

Lasagna code

O descuido não é a única maneira de acabar com um código difícil de manter; o excesso de complicação também pode ser uma causa. Trabalhei durante uma década em Portugal, em 2004 aceitei um emprego em uma consultoria informática, que tinha uma das bases de código mais confusas que já vi. O programa era escrito numa framework, numa pseudo linguagem natural de alto nivel, que ao compilar-se gerava um fonte em Cobol ou Java, terrivelmente confuso e cheio de copybooks e referências externas.

Imagine que cada elemento do produto foi abstraído em dezenas de componentes aninhados singulares. Era quase impossível fazer uma alteração em uma camada da pilha sem afetar todas as outras camadas. A base de código não so era uma bagunça, mas também não era sustentável. Para analisar um programa Cobol necessitávamos compilar e verificar a listagem estendida.

Se o código espaguete sofre de desleixo arquitetônico, o código da lasanha é uma característica do excesso de engenharia em sua forma mais extrema. Os coitados dos programadores que trabalham com bases de código orientadas a objetos geralmente caem nessa armadilha.

O código da lasanha é abstraído, camadas fortemente conectadas; os desenvolvedores o escrevem porque estão convencidos de que cada subcomponente necessita de seu próprio objeto. Esses programadores tendem a se concentrar no layout do código em detrimento de sua manutenção. O que começa como uma base de código altamente organizada rapidamente se torna um desastre arquitetado demais.

Esta é uma boa regra a seguir: seja conservador com suas abstrações. Se você planeja abstrair um componente que apenas um outro componente usa, o que, por sua vez, apenas outro componente usa, você foi longe demais. Mantenha a base de código simples. Olho vivo meu jovem padawan.

Ravioli code

A estrutura de software ideal é aquela com componentes pequenos e fracamente acoplados; essa estrutura ideal é chamada de código de ravioli.

Ravioli são basicamente pequenos pacotes de massa com coisas deliciosas, então em um código de ravióli, cada um dos componentes, ou objetos, é um pacote contendo um pouco de carne ou outro alimento para o sistema.

Qualquer componente pode ser modificado ou substituído sem afetar significativamente outros componentes em um código de ravióli. Mas cuidado com sua lucidez, pois em um código de ravióli, existem milhares de pequenas classes e é muito difícil descobrir de onde e para onde, qual o lugar onde tudo acontece?.

Embora esse tipo de codificação seja bastante atraente do ponto de vista de acoplamento e coesão, a separação e o encapsulamento do código podem expandir as pilhas de chamadas, o que, por sua vez, cria um problema de navegação pelo código para fins de manutenção, pobre padawan isso foi cruel, ne

Gnocchi code

Ai meu caro, são blocos ilegíveis de código, você pode dizer que há um algo acontecendo lá dentro, mas você não tem a menor ideia do que é, alterar esses blocos de código densos e inacessíveis é algo bem temerário, pois a alteração, a guarda em produção parecera impossível, pois ele irá abendar e causar muitos danos a sua reputação.

Pizza code

Pequeno glutão, está pizza não é uma delícia do Bras ou do Luigi, mas se encaixa com o código do espaguete e seu mal afamada laia na teoria da massa como um antipadrão de programação. Na maioria dos casos, o código de pizza é descrito como um código com uma arquitetura plana.

O código de pizza geralmente tem um grande número de classes ou funções, todas interconectadas no mesmo nível no topo de uma camada fundamental. No código da pizza, os componentes individuais são geralmente independentes uns dos outros, mas às vezes pode ser difícil extraí-los sem interferir nos outros.

Todo bom software requer estrutura. O código da pizza sofre por ser mal projetado. É bom ter componentes relativamente isolados, mas o código de pizza torna quase impossível entender as funções e responsabilidades de cada classe. Para obter a base de código sob controle, corte o código da pizza em fatias; adicione alguma estrutura lógica a cada componente.

Ps:

Nao confunda com a PIZZA, companheira inseparável do DEV, que adentra na madrugada tentando solucionar abends, debugando spaghetti code e perdendo cabelos ao solucionar problemas e cumprir a SLA espartana.

Spaghetti code in the cloude

Bem vindo ao século XXI, com tanta gente entrando no universo do Cloude Computer, prepara-se, aperte o sinto e divirta-se com essa modalidade, código espalhado em múltiplas maquinas em inúmeros países, o céu é o limite.

Conclusão

Acabei me empolgando, o tiozão escreveu muito virou um testamento, quase se transformando em capitulo do pentateuco, perdoe-me, pois o assunto é instigante e tem tanta informação a passar, que ficaria aqui a noite toda escrevendo.

Espero ter ajudado e não confundindo muito, duvidas, correções e reprimendas, já sabem aqui no Forum ou no Discord.