Comentários Engraçados D+

 Os comentários em código tem uma importância para auxiliar num futuro próximo na manutentabilidade de sistemas, tornando mais fácil ser entediado por humanos. Porém, muitos desenvolvedores, transformação essas linhas não compiláveis em verdadeira partes engraçadas do trabalho. 

Obvio, talvez sim, talvez não

// return 1; # retornar 1

int getRandomNumber()

{

Return 4; // escolhido por um lançamento de dados

}

Erro, para quê serve?

Catch (Exception e) {

//Melhor não...

}

try {

} finally { // Nunca deveria acontecer

}

Exception up = new Exception("Alguma coisa deu errado!");

throw up;  //rs

}catch(Exception ex){

// Houston, nós temos uma problema

}

catch (Ex as Exception) {

// oh merda, devemos fazer algo.

}

Só Ameaças

// Se este comentário for removido o código vai parar de funcionar

// Abandone todas as esperanças aos que entrarem além deste ponto

// Fiz isso sob ameaça, se estiver lendo isso, você é a próxima vítima, corra enquanto há tempo!!!!!

// Remova isso se você quiser ser demitido

// Mágida. NÃO TOQUE!

/* Rs rs rs! Você nunca vai entender por que isso funciona. */

Referência 

options.BatchSize = 300; //Loucura?!? ISSO É SPARTA!

last = first; /* Biblíco */

long long ago; /* Em uma galáxia muito, muito distante */

float boat;   // deve ser um barco, caso contrário, ele afunda! :D

<!-- 0101010001101000011001010111001001100101001000000110100101110011001000000110111001101111001000000111001101110000011011110110111101101110 -->

Filosofando

// bebado, arrumar isso depois

// Quando escrevi esse código, somente Deus e eu entedemos o que está sendo feito

// Agora, somente Deus. ;)

// Querido eu do futuro. Por favor, me perdoe.

// Não consigo começar a dizer o quanto estou arrependido.

// Pelos códigos que estou prestes a escrever, que Ada Lovelace me perdoe

Promessas e são promessas

// Eu preciso arrumar um emprego melhor

// Fazer comentários depois

// TODO Fazer isso funcionar

Verdades Nuas e Cruas

// Programador bons não comentam seus códigos

// O código por si se expressa, é uma arte 

// Se você está lendo isso, quer dizer que você está no meu projeto antigo

// Eu sinto muito, muito mesmo. Boa sorte.

// Não sei por que isso funciona, entretanto corrigi o problema. ;)

// São 3 da madruga, está código está horrível, porém funcionou.

// Este código é uma porcaria, você sabe e eu sei disso.

// Siga em frente, faça o que tem que fazer e passe para o próximo idiota.

Tem uns que são verdadeiras pérolas! kkk

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Fontes:

https://loudprogrammer.net/best-comments-in-source-code-i-ever-encountered/

https://meetpd.com/funny-code-comments/

https://fuzzzyblog.blogspot.com/2014/09/40-most-funny-code-comments.html

Sustentabilidade com Codificação

 

Todos somos responsáveis pela redução da emissão de CO2 e, consequentemente, com esse impacto no aquecimento global. Governos, empresas e organizações estão cada vez mais comprometidos em conter as emissões de gases que provocam o efeito estufa. Durante a Cúpula do Clima, que contou com a participação de 40 nações, o presidente dos Estados Unidos, Joe Biden, reconheceu que o país não está fazendo o suficiente para conter o aquecimento global e anunciou metas mais ambiciosas de corte nas emissões de poluentes. 

Como as empresas de Tecnologias da Informação e Comunicação podem ajudar nessa redução?

Você sabia que atualmente é necessário 1% de toda a energia gerada globalmente para alimentar os data centers? Em 2030 esse percentual pode chegar aos incríveis 30%, se somado às estruturas das TIC. Então, podemos presumir que cada linha de código gera um impacto no consumo de energia que resulta na emissão de CO2.  

E como os profissionais de TI podem gerar impacto direto na eficiência energética?

Simplesmente ao escolher formas mais inteligentes de arquitetura, recursos, codificação, estabilidade, boas experiências de usuário, tempo de utilização de processamento e alocação de memória/espaço.

Para guiar os profissionais foi criado um programa inovador chamado Green Coding, que implementa no desenvolvimento de softwares a sustentabilidade, sendo um fator fundamental para ajudar na redução de emissão de gases de efeito estufa, por meio de três pilares:

Aplicar o programa significará adicionar uma nova questão ao processo de design de software, o que coloca também em foco a eficiência energética, que por consequência oferecerá economia financeira e melhores soluções. Vamos verificar alguns exemplos desses pilares.

Lógica

Você sabia que cada linguagem gera um impacto diferente no consumo de energia? Conforme um estudo apresentado pelo GreenLab, é possível efetuar uma comparação por meio de um fator entre as linguagens. Isso leva em conta a taxa de utilização de tempo de processamento, alocação de memória e armazenamento. Claramente, essa escolha de uma linguagem não pode simplesmente ser baseada nessa métrica, pois também temos que colocar na conta os desenvolvedores, a facilidade da utilização, a manutenção, entre outros tantos fatores.

Ação Prática: Criar mecanismos para metrificar blocos de código de processamento, para que seja possível coletar os tempos e percentuais de utilização. Dessa forma gerar parâmetros comparativos que deverão ser usados para a avaliação de melhoria de performance e resultando em uma melhora na eficiência dos processamentos visíveis.

Metodologia

Reutilização de resultados de projetos, seja em partes ou na sua totalidade, para que esses possam ser pesquisados ​​por membros da equipe, pessoas dentro da organização ou até mesmo pela comunidade em geral. Assim, as melhores práticas e resultados são rapidamente absorvidos e implementados.

Ação Prática: Criar um repositório com estudos de casos dos levantamentos de cenários de melhorias de projetos e das possíveis soluções que foram analisadas e posteriormente implementadas. Isso gera uma documentação que poderá ser consultada. Lembre-se, muitos projetos podem se beneficiar das implementações simples e que já foram testadas. 

Plataforma

Aqui, a adoção de computação em nuvem faz todo o sentido. Dado que os recursos são facilmente provisionados, oferecem escalabilidades conforme a demanda de utilização e também oferecem recursos granularizados. Assim temos um conjunto perfeito para criar o ambiente com o tamanho exato de cada necessidade para o momento, o que evita o desperdício de super alocações para atender cenários imaginados. 

Ação Prática: Programar o desligamento automático de equipamentos ou desprovisionamento de recursos que não estejam sendo utilizados no momento, assim os ambientes deixam de funcionar enquanto não estão sendo utilizados ​​(noite, fins de semana, etc.).

O programa GreenCoding está dando os seus primeiros passos, contudo a sua adoção do processo de desenvolvimento de soluções com sustentabilidade é uma responsabilidade de todos. Os recursos do nosso planeta são finitos e não devem ser desperdiçados aleatoriamente, é a nossa obrigação oferecer métodos mais eficientes para gerar maiores impactos na redução de emissão de CO2 e consequentemente salvar o nosso precioso planeta. 

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Artigo original publicado em https://blog.gft.com/br/2021/05/11/sustentabilidade-com-codificacao/

Registro de Decisão de Arquitetura

 

Todos que atuam com tecnologia já se deparam com situações em que ninguém sabe explicar o porquê de determinada soluções tecnológicas, é tipo a tartaruga em cima da árvore, todos sabemos que é impossível a tartaruga ter chego lá sozinha, logo alguém a colocou lá, entretanto como não temos o contexto, não fazemos ideia do porque a tartaruga está lá e para piorar, que efeitos positivos ou negativos podem ocorrer caso a tartaruga seja removida. 

Pegando o gancho dessa analogia, podemos transportar essa mesma ironia para arquitetura de softwares, muitas vezes nos deparamos com soluções implementadas de formas anormais as práticas comuns e a nossa primeira reação é corrigi-la. Porém, precisamos contextualizar que se algo foi feito daquela maneira, com certeza existia um contexto a época que culminou nesta escolha, logo, é sempre muito simples entender as razões e consequências, se pudermos facilmente acessar essas informações, para elucidar as principais dúvidas da tomada de decisão no passado. 

Para isso, Michael Nygard recomendou que fosse criado um documento chamado Architectural Decision Records (ADR), em tradução livre, Registro de Decisão de Arquitetura, seu propósito principal é capturar as tomadas de decisões arquiteturais, incluindo o contexto que em foi gerada, as consequências adotadas pela decisão. Esses simples documentos, promovem inúmeros benefícios, principalmente no contexto ágil, sendo alguns desses:

Integração de Novos Membros

Haverá todo um histórico de decisões que deve ser absorvido e que auxiliará na contextualização dos porquê somos e estamos assim. Desde uma simples decisão da adoção de uma tecnologia específica, como a linguagem para desenvolvimento de sites, até a utilização de micro serviços em containers.

Transferência de Conhecimento

Muitas vezes, sistemas são transferidos entre colaboradores, equipes, consultorias, ou seja, mover a propriedade dos sistemas para outra parte que assumirá o comando. Estando os contextos das decisões documentadas, nenhum conhecimento irá se perder no processo, porque os novos proprietários podem rapidamente entender como e por que a arquitetura do sistema evoluiu da maneira que evoluiu simplesmente lendo. 

Alinhamento

Todos sabendo da presença desses documentos, será criado o hábito do conhecimento compartilhado das decisões, facilitando a consulta em níveis hierárquicos da arquitetura, de quais são os “combinados” dentro da corporação. 

E como fazer acontecer? Simples, escrevendo os documentos de Registro de Decisão de Arquitetura no momento em que decisões de impacto significativo são feitas, ou nos mapeamento de débito técnico ou ainda nas implementações fora do comum. 

Mas quando deve ser feito? Um documento pode ser escrito previamente ou posterior a solução, a preferência é que seja feito previamente para estimular a discussão das consequências, fomentando assim mais insumos para uma decisão assertiva. Nos casos posteriores, é necessário para criação de uma base histórica dos contextos que foram aplicados perpetuando o conhecimento.

E o processo como é? Os documentos de Registro de Decisão de Arquitetura são baseado num template com simples marcações em seções, composto pelo seguintes blocos:

Título

Composto por um código e um texto curto e direto sobre o tema. O código é para facilitar o controle e também a inter-relação entre os documentos.

Exemplo: ADR-0012 - Requisições API devem gerar logs

Data

A data que o documento foi criado.

Exemplo: 2021-mai-05

Status

Existem por padrão seis possíveis status, porém você tem a liberdade de criar seus próprios, segue os sugeridos:

• Proposto: Criação do Documento.

• Aceito: Decisão Aprovada.

• Depreciado: Decisão não faz mais sentido.

• Substituído: A decisão foi substituída - importante referenciar a que substituiu

• Complemento: Uma decisão complementar - importante referenciar a original

• Rejeitado: A decisão proposta foi rejeitada

Contexto do Problema

Neste bloco deve ser descrito os fatos que levaram a tomada da decisão, elencando todas as influências que estavam atuando no momento, sejam elas políticas, corporativas, econômicas, tecnológicas, ou mesmo sociais.  

Exemplo: Não conseguimos visualizar os logs em tempo real das requisições, o que resulta em atraso do monitoramento preventivo de erros e comportamentos fora do comum das chamadas. Existe a possibilidade de aquisição de uma ferramenta para efetuar esse monitoramento, entretanto o processo é burocrático e lento. Sendo previsto a sua disponibilização em 6 meses.

Decisão

Neste bloco será descrita a decisão tomada, é vital relacionar com o problema descrito, utilizando a voz ativa com sentenças completas e organizadas em parágrafos.

Exemplo:  Todas as requisições terão implementado em seu cabeçalho a chamada do sistema de log que salvará os dados em um banco de dados. As requisições ao sistema log são assíncronas. Utilizaremos o framework Log4Net para implementação.

Consequências

Este bloco talvez seja o mais importante, porque é aqui que deve ser descrito os resultados positivos e/ou negativos e/ou neutros da decisão, é neste ponto que deve fazer sentido a decisão tomada. Tudo que puder afetar o projeto deve ser registrado e também os débitos técnicos, ou seja, o que precisa ficar no radar para ser decidido no futuro.

Exemplo: O armazenamento “manual” dos logs em tempo real não é a melhor solução, principalmente com a necessidade de atualização de todas estruturas atuais de API que precisavam ser entregues em produção. É importante a implementação de um sistema de gerenciamento de APIs para que seja feito o monitoramento completo do ciclo de vida de uma requisição.

Esses documentos devem preferencialmente serem armazenados em repositórios acessíveis para todos, incentivando assim o compartilhamento de conteúdo e facilitando o acesso às decisões. É crucial que exista um nível organizacional hierárquico para demonstrar as decisões que são dependentes em camadas, por exemplo, uma decisão de arquitetura afeta automaticamente um departamento, que por consequência afeta um projeto.

Com a metodologia ágil cada vez mais presente nas empresas, estamos muito mais propensos às mudanças constantes, e para dar maior visibilidade às decisões tomadas, o documento de Registro de Decisão de Arquitetura nos ajuda a não fazer um julgamento precipitado sobre o que foi feito há época, oferecendo contexto para maior segurança aos times no entendimento do passado e fornecedor informações para melhor decisões no presente que afetam o futuro.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br