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

Shu-Ha-Ri no Agile

 

Shu-Ha-Ri é uma filosofia japonesa aplicada em artes marciais, ela engloba o processo de aprendizagem e maestria de uma ou mais técnicas, obedecendo esta ordem: Shu:  obedecer/proteger; Ha: romper/modificar; Ri: separar/superar. Você pode estar se perguntando, o que isso tem haver com agilidade, onde isso é aplicado? Calma, pequeno gafanhoto, vamos definir as três ordens para entender e relacioná-las com a agilidade.

Shu – Seguindo as regras

Em qualquer arte marcial um iniciante precisa entender e praticar as regras passadas pelo mestre, para que possa iniciar seu domínio. É fundamental  praticar sozinho, em conjunto, com o mestre, várias vezes para que os movimentos sejam absorvidos e passem a ser mais naturais. 

Na agilidade, durante o processo de adoção de uma metodologia ágil, como por exemplo o SCRUM, é necessário primeiramente a disseminação das regras, dos papéis, das cerimônias para que todos envolvidos a cada nova sessão se sintam mais confiantes para praticar, gerando assim uma maior aderência.

Ha – Quebrando as regras

Neste ponto um aluno, já acumulou bastante experiência, realiza os movimentos com um excelente domínio, a figura do mestre acaba não sendo tão necessária, e o aluno ainda pode arriscar alguns lances diferentes, realizando movimentos suavemente diferentes, que podem aperfeiçoar sua luta.

Na agilidade, quando um time já executa uma metodologia ágil, o time começa a desenvolver uma maturidade suficiente para se permitir a “quebrar algumas regras”, um exemplo, pular uma Daily porque todos os assuntos estão em andamento e nada de novo está no radar e o assunto foi tratado via e-mail. Ou seja, não existe perda de performance e nada foi prejudicado, por conta da experiência do time é possível flexibilizar algumas regras.

Ri – Extrapolando as regras 

Em RI, o aluno já não precisa racionalizar os movimentos na hora de praticar a arte marcial, todos os movimentos estão nativamente em seu ser, neste ponto onde é possível começar a incorporar novos movimentos de outra arte marcial, ou ainda efetuar a adaptação de movimentos para gerar um novo. É basicamente quando o aluno se torna mestre de si mesmo.

Na agilidade, é onde um time consegue adaptar a metodologia ágil para aumentar a performance, desde a simples remoção de algo que não esteja agregando, ou ainda implementar uma ferramenta proveniente de uma outra metodologia. Ainda no exemplo da Daily, digamos que a equipe decida eliminar as reuniões diárias e substituí-las por um quadro atualizado em tempo real e com indicações de impedimentos. Basicamente cada time já contém experiência suficiente para efetuar adaptações com o foco de aumentar a performance. No conceito Ágil toda equipe deve chegar neste ponto em algum momento.

O próprio Manifesto Ágil (aqui) se define com uma metodologia que se adapta às diferentes realidades e é totalmente flexível para que possa derivar novas formas de trabalho que agregam valor para todos. Aplicando as ordens do Shu-Ha-Ri, poderemos avaliar o estágio da maturidade da agilidade dentro da empresa, para auxiliar as equipes a se tornarem mestre de si mesmo.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br