Como funciona o Single Source of Truth ou SSoT no fluxo de documentação
Quando pensamos na documentação de alguma informação, sempre imaginamos que esse processo seja organizado, centralizado e acessível. É aí que o Single Source of Truth ou SSoT aparece! Um bom exemplo para imaginar a atuação do SSoT é o trabalho de Technical Writers. Essa equipe precisa reunir informações dos times de engenharia para desenvolver documentações de software, ter uma base de conhecimento vai auxiliar muito nesse processo. Para conhecer mais sobre o tema, neste artigo, vamos apresentar o que é o Single Source of Truth e quais são seus principais benefícios no dia a dia de uma empresa que desenvolve produtos digitais. O que é Single Source of Truth (SSoT)? Single Source of Truth (SSoT) ou Fonte Única da Verdade é um termo utilizado para se referir ao conceito de gestão do conteúdo a partir de uma ferramenta única. Segundo esse conceito, então, todo o conteúdo (técnico e não técnico) de uma empresa deve ser centralizado em uma base de conhecimento. No dia a dia dos times de documentação, por exemplo, alguns dos maiores problemas enfrentados pelo time de Technical Writers (TWs) são: informações duplicadas, descentralizadas e desatualizadas, que geralmente são causadas pela ocorrência do fenômeno de silos organizacionais. Muitas vezes, isso resulta em frustração do público-alvo, em razão da dificuldade, ou até mesmo impossibilidade, de localizar a informação desejada. No entanto, isso não quer dizer que a aplicação do Single Source of Truth esteja restrita à utilização de uma única ferramenta para todas as documentações da empresa, até porque cada time e produto possuem peculiaridades e diferentes necessidades em relação à disponibilização do conteúdo. Então, esse conceito também pode dar origem aos chamados hubs de documentação. Os hubs nada mais são do que plataformas, através das quais o público-alvo é redirecionado ao conteúdo que procura. A ideia, portanto, é criar um ponto de centralização de conhecimento que sirva como referência, para garantir que todo mundo tenha acesso às mesmas informações. Esse conceito é um dos pilares da metodologia de DocOps, vamos conhecer mais sobre ela! O que é DocOps? O conceito de DocOps (Documentation Operations) ou Operações de Documentação surgiu da metodologia DevOps e seu objetivo é o mesmo de seu precursor. No entanto, o DocOps é voltado ao desenvolvimento de documentação, e não de software. As práticas de DocOps estão diretamente ligadas à infraestrutura do processo de documentar e visam a adoção de um conjunto de práticas de automatização e integração desse processo, de modo a tornar o conteúdo escalável e sustentável. Isso significa que durante a atividade de documentar são adotadas práticas e ferramentas voltadas ao ciclo de vida da documentação, com foco em garantir que todo o público-alvo tenha acesso ao mesmo conteúdo, e que ele esteja sempre atualizado. Para que a aplicação dessa metodologia funcione corretamente, é imprescindível que haja colaboração de todo o time envolvido no desenvolvimento do produto, principalmente quando se tratar de times grandes e multidisciplinares. O time de Technical Writing é responsável pela adoção de boas práticas e por garantir a qualidade da documentação, enquanto o time de engenharia deve trazer os detalhes técnicos do conteúdo a ser documentado. As etapas desse processo estão ilustradas no diagrama abaixo: Exemplo do dia a dia Digamos que uma determinada empresa disponibilize suas APIs em uma plataforma voltada ao público-alvo, nesse caso, pessoas desenvolvedoras. Dentre as APIs disponibilizadas, uma delas possui diversas versões, sem uma indicação clara de qual é a mais recente. Além disso, não há uma sessão de release notes na documentação, ou seja, não há o detalhamento do histórico de atualizações. Essa situação gera dúvidas durante a utilização daquela API, pois não se sabe se a versão utilizada é a mais recente. Isso viola os requisitos mínimos de uma documentação de qualidade: fácil de usar, fácil de entender e fácil de encontrar. Por isso é imprescindível que o processo de atualização de um produto envolva também a disponibilização de release notes (que fazem parte da documentação técnica). Esse processo pode ser realizado manualmente ou de forma automatizada, o que importa é garantir que todo mundo tenha acesso ao mesmo conteúdo e que ele não gere dúvidas durante a utilização do produto. Nesse sentido, enquanto o SSoT preza pela usabilidade da documentação, o DocOps tem o papel operacional de garantir que os procedimentos adotados sejam eficientes para que o objetivo seja alcançado. Vantagens do Single Source of Truth A adoção das boas práticas do SSoT é essencial para a usabilidade do produto, mas os benefícios também se refletem diretamente para os times e a empresa como um todo. Os principais benefícios são: Evitar perda de conhecimento Definir o local exato onde as informações devem ser documentadas evita que o conhecimento seja perdido, duplicado, descentralizado e adulterado. Com isso, o risco de se perder aquela informação, ou aquele conhecimento, é mitigado. Facilitar a localização de informações Uma vez que se define onde cada tipo de informação deve ser documentada, a localização de conteúdo se torna intuitiva. Engajar melhor os públicos Com uma navegação mais intuitiva, o público que consome a documentação fica mais engajado a continuar consumindo e contribuindo para a evolução do conteúdo e, consequentemente, do produto em si. Ou seja, isso faz com que a documentação alcance seu objetivo: facilitar a vida do público-alvo, e não dificultar. Diminuir custos Cada plataforma possui um custo de manutenção. Centralizando a informação, é possível diminuir o número de plataformas utilizadas e o custo suportado pela empresa para a manutenção de várias ferramentas. Com esses benefícios em mente, não há dúvidas de que o SSoT pode, realmente, virar a chave de um projeto no tópico de documentação. Basta a coragem e a iniciativa de iniciar a implementação, que os resultados certamente farão todo o trabalho valer a pena. Implementação no projeto Em um primeiro momento as dores devem ser mapeadas por nível de prioridade, que deve ser definido pelo time de TWs, em conjunto com a liderança do projeto. Com essa definição, a ferramenta de centralização é escolhida e a documentação passa a ser centralizada. O SSoT é um modelo para funcionar a longo prazo. Isso significa que os primeiros resultados após a implementação devem surgir
CDD e legibilidade do código: essa relação garante melhorias?
A relação entre CDD e legibilidade de código é um assunto rico quando se trata da compreensão de linhas de código. Afinal, usar CDD garante melhorias de legibilidade ou não? É essa questão que buscamos responder neste conteúdo. Lembrando que este blog post é o resumo do artigo científico publicado na trilha de pesquisa da conferência ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), em 2022. O texto completo do artigo, em inglês, está disponível aqui. O que é esse tal de CDD? Cognitive-Driven Development (CDD) é uma técnica de design de código que visa reduzir o esforço cognitivo que devs empregam na compreensão de uma determinada unidade de código, por exemplo, uma classe. A ideia que CDD defende é que deve existir um limite no tamanho das unidades de código, mas esse limite deve ser definido de forma disciplinada. CDD tem suas raízes em duas teorias psicológicas bem conhecidas: a Teoria do Número Mágico Sete e a Teoria da Carga Cognitiva (CLT). Conheça um pouco mais sobre elas: Quando se fala do processo de desenvolvimento de software, pode não ser uma surpresa que um grande número de construções de código possam dificultar a compreensão de um programa. Quem nunca precisou ler várias e várias vezes um método com vários if alinhados e um ou dois fors para compreender o objetivo de um método? Quanto maior o número de construções de código concentradas na mesma unidade de código, maior tende a ser o esforço para compreendê-la. Tudo tem limite, CDD também O CDD tem como objetivo limitar a quantidade de elementos de código que podem aumentar a sua complexidade. Para isso, pessoas que usam a abordagem do CDD precisam definir os “pontos de complexidade intrínseca”, do inglês, Intrinsic Complexity Points ou ICP, do código. ICPs são elementos de código que podem afetar o entendimento das pessoas desenvolvedoras, de acordo com sua frequência de uso. Exemplos de ICPs são: Isoladamente, estes elementos de código podem não embaraçar o entendimento de um trecho. No entanto, se usados com frequência em uma mesma unidade de código, eles potencialmente podem dificultar o seu entendimento. É importante notar que o CDD é uma abstração, ela apenas fornece mecanismos para que devs decidam o que deve ser limitado. Pessoas desenvolvedoras precisam antes de tudo decidir quais são os ICPs e quantos podem ser tolerados. E essa não é necessariamente uma tarefa simples. Por exemplo, quantas declarações de ifs devem existir em uma determinada unidade de código? Como várias pessoas estão envolvidas na criação de um produto de software, o limite de complexidade deve ser definido de forma colaborativa, levando em consideração o grau de especialização de devs do time e a natureza do projeto. Estudo sobre CDD e legibilidade Embora evidências iniciais indiquem que a prática de CDD possa facilitar a manutenção do software, uma vez que o código fonte criado usando as premissas do CDD utiliza menos elementos de código, pouco se sabe se o código que foi desenvolvido usando o mecanismo também tem melhor legibilidade. Para entender até que ponto a utilização de CDD pode melhorar a legibilidade de um código fonte, conduziu-se um estudo empírico com o objetivo de avaliar a legibilidade de trechos de código que foram conduzidos utilizando CDD como prática de desenvolvimento de software. Primeiros passos O estudo foi primariamente baseado em um questionário que foi respondido por 133 devs profissionais, sendo 73 zuppers. Nesse questionário, apresentamos 10 pares de trechos de código, como ilustrado na figura abaixo. Nessa figura, o trecho de código à esquerda representa um trecho de código original, extraído de um projeto Java existente. Por outro lado, o trecho de código à direita representa o mesmo trecho de código, mas refatorado utilizando as diretrizes do CDD. Para encontrar estes 10 pares de código, utilizamos como base um outro estudo sobre CDD. Nele, 18 zuppers realizaram refatorações – utilizando as diretrizes do CDD – em alguns projetos de código aberto bem conhecidos, como o feign, por exemplo. Esse conjunto de refatorações originadas nesse outro estudo foi analisado e filtrado por três pessoas pesquisadoras, no fim, apenas 10 pares foram selecionados. Para selecionar esses pares, levou-se em consideração critérios como: Os 10 pares foram então apresentados para devs profissionais, que deveriam apenas indicar qual trecho era mais legível. Após indicar o trecho mais legível, a pessoa também deveria apresentar seu raciocínio. Esse questionário foi divulgado internamente na Zup, mas também em redes sociais como Twitter e LinkedIn. Os resultados Será que um código desenvolvido com CDD tem melhor legibilidade de código? De maneira geral, nós observamos que 7 das 10 refatorações de código guiadas com CDD foram mais positivamente avaliadas do que os trechos de código originais. Em dois casos, não foi possível decidir quais trechos de código eram mais legíveis. Por fim, somente um trecho de código original foi considerado mais legível do que sua versão refatorada utilizando CDD. A seguir exemplificamos cada um desses casos. Encapsulando tratadores de exceção Neste exemplo, o código original tinha um bloco try-catch que tratava a exceção SendFailedException. A versão CDD deste código extraiu a responsabilidade pelo tratamento da exceção e moveu o bloco try-catch para um novo método chamado sendMessageToAdvisor, como pode ser visto a seguir. Versão original Versão refatorada usando CDD Observamos uma semelhança notável nas votações: 66 participantes preferiram o código original, enquanto 66 preferiram a versão refatorada usando CDD. Ao analisar os comentários das pessoas que participaram, notamos que devs que favoreceram o código original têm um certo hábito com esta prática de codificação. Como foi argumentado por uma pessoa: “registrar com try-catch é tão comum que eu nem precisei ler o código para entender o propósito”. Outra mencionou que: “há mais visibilidade das ações realizadas no código, o que está sendo executado é mais explícito”. Por outro lado, participantes que favoreceram a versão refatorada usando CDD indicaram que o código refatorado é próximo do inglês, como mencionou uma pessoa: “o código é mais curto e com uma linguagem mais próxima da natural”. Também
Docker: tudo o que você precisa saber
À medida que a abordagem de nuvem está ganhando popularidade, muitas empresas começaram a adotar práticas e conceitos de nuvem como a conteinerização. Com isso, ferramentas DevOps, como o Docker, estão em alta demanda. Neste artigo, você vai descobrir o que é Docker, o que precisa saber para usá-lo e qual a sua função no universo de desenvolvimento, além de conhecer mais sobre contêineres e suas imagens. A relevância disso? De acordo com uma pesquisa do Gartner, mais de 75% das organizações globais estarão executando contêineres em produção em 2022. Atualmente, o Docker Hub contém mais de um milhão de imagens de contêiner, incluindo imagens certificadas e fornecidas pela comunidade. Agora vamos aprender mais sobre esse universo. Mas o que é Docker? É uma ferramenta Open Source para desenvolvimento, envio e execução de aplicativos. Ele permite que você separe os aplicativos de sua infraestrutura, para que você possa entregar um software rapidamente. Se Docker se tornou uma ferramenta padrão para pessoas desenvolvedoras de software e administradoras de sistemas é porque é uma maneira elegante de iniciar aplicativos rapidamente sem afetar o resto do seu sistema, pois permite gerenciar sua infraestrutura da mesma forma que gerencia seus aplicativos, usando o conceito de contêineres. O conceito de contêineres Um contêiner fornece um ambiente isolado semelhante a uma máquina virtual (VM). Mas ao contrário das VMs, os contêineres do Docker não executam um sistema operacional completo. Eles compartilham o kernel do seu host e o hardware da máquina host com, aproximadamente, a mesma sobrecarga dos processos iniciados diretamente na máquina host. Observação: A ferramenta utiliza, na verdade, o kernel subjacente e não o sistema operacional. Portanto, mesmo que a máquina na qual o Docker está instalado use Ubuntu, Docker ainda pode instalar contêineres baseados no Fedora, etc., pois o kernel subjacente é o mesmo (neste caso, Linux). Os contêineres encapsulam tudo o que é necessário para executar um aplicativo, desde as dependências do pacote do Sistema Operacional (SO), até seu próprio código-fonte. Docker permite automatizar a implantação de aplicativos no ambiente do contêiner. Para isso, a pessoa usuária define as etapas de criação de um contêiner como instruções em um Dockerfile e Docker usa ele para construir uma imagem. Tá, e o que são imagens? As imagens definem o software disponível nos contêineres. Uma imagem do Docker contém código de aplicativo, bibliotecas, ferramentas, dependências e outros arquivos necessários para executar um aplicativo. Quando alguém executa uma imagem, ela pode se tornar uma ou várias instâncias de um contêiner. Em outras palavras, se você criar uma imagem, qualquer user do poderá iniciar seu aplicativo através de um comando (docker run). Vantagens de usar contêineres Uma das principais vantagens de usar contêineres é a garantia de que todos os ambientes são idênticos: Hoje, sem contêineres, as organizações entram em algo chamado “Matrix from Hell“, onde você tem diferentes tipos de aplicativos, dependências e ambientes, e todos esses elementos precisam trabalhar juntos para que seu software funcione com eficiência. Isso realmente é um inferno. Em outras palavras, Docker permite que você economize muito tempo no processo de configuração, que em alguns casos pode ser muito longo e caro, tanto em termos de tempo quanto em termos de pessoal dedicado (consequentemente, também em nível econômico). Usar Docker também pode ser mais conveniente do que usar uma máquina virtual completa. As VMs são ferramentas projetadas para oferecer suporte a todas as cargas de trabalho possíveis. Por outro lado, os contêineres são leves, autossuficientes e mais adequados para casos de usos descartáveis. Como o Docker compartilha o kernel do host, os contêineres têm um impacto insignificante no desempenho do sistema. O tempo de inicialização do contêiner é quase instantâneo, pois você está apenas iniciando processos, não um sistema operacional inteiro. Desafios de usar contêineres Apesar das suas inúmeras vantagens, a ferramenta não é uma bala de prata. Ele também tem seus desafios, vamos abordar alguns deles aqui. 1. Foi projetado como solução para implantação de aplicativos de servidores, que não requerem uma interface gráfica. Embora existam algumas estratégias para poder executar um aplicativo GUI dentro de um contêiner, essas soluções são, na melhor das hipóteses, desajeitadas. 2. Persistir dados é complicado. Por design, todos os dados dentro de um contêiner desaparecem para sempre quando o contêiner é encerrado, a menos que você os salve em outro lugar primeiro. Contudo, existem maneiras de fazer isso no Docker, como usando o Docker Data Volumes, por exemplo. 3. Com o uso adequado, Docker pode aumentar o nível de segurança (em comparação com a execução de aplicativos diretamente no host). Por outro lado, algumas configurações incorretas podem levar ao downgrade do nível de segurança ou até mesmo introduzir novas vulnerabilidades. Quer saber mais como manter sua operação com contêineres segura? Então assista a palestra “Vulnerabilidades em Imagens de Containers” retirada da trilha da Zup no TDC Connections 2021. Orquestração de contêineres Hoje em dia, é comum usar uma plataforma de orquestração como o Kubernetes ou Docker Swarm para usar Docker em produção. Essas ferramentas são projetadas para lidar com várias réplicas de contêiner, o que melhora a escalabilidade e a confiabilidade. Docker se tornou um componente. Os orquestradores utilizam as mesmas tecnologias de tempo de execução de contêiner para fornecer um ambiente mais adequado à produção. O uso de várias instâncias de contêiner permitem atualizações contínuas, bem como distribuição entre máquinas, tornando sua implantação mais resiliente à mudanças e interrupções. Resumindo a terminologia do Docker Contêiner: ambiente isolado e leve que pode ter seus próprios processadores, interfaces de rede, etc., mas compartilham o mesmo kernel do sistema operacional. Criado a partir de uma versão de imagem específica.Imagem: uma imagem é basicamente um pacote executável que possui tudo o que é necessário para executar aplicativos, o que inclui um arquivo de configuração, variáveis de ambiente, tempo de execução e bibliotecas. Dockerfile: contém todas as instruções para criar uma imagem do Docker. É basicamente um arquivo de texto simples com instruções para construir uma imagem. Você também pode se referir a isso como a
Conheça como funciona a SE4ML, a Engenharia de Software para o Aprendizado de Máquina
A área de pesquisa chamada de “Engenharia de software para Aprendizado de Máquina”, ou SE4ML, surgiu para apoiar cientistas de dados na construção, avaliação e manutenção de seus modelos de software. Este artigo é para você conhecer mais sobre a SE4ML, componentes inteligentes e os desafios encontrados na sua implementação. Contexto da SE4ML Múltiplas áreas do conhecimento como biologia, finanças e física, bem como empresas e organizações governamentais, acreditam que soluções que utilizem abordagens inteligentes são necessárias para atacar os problemas atuais. No contexto do desenvolvimento de software, aplicações inteligentes foram popularizadas por empresas como Google, quando tentamos fazer uma busca de imagens; Netflix, quando nos recomenda uma série; ou Microsoft, quando autocompleta nossos textos de e-mail. Todos esses sistemas são notoriamente constituídos por componentes inteligentes. Por sua vez, esses componentes são desenvolvidos utilizando um conjunto de práticas, algoritmos e ferramentas especializadas, que raramente são utilizados para a construção de sistemas de software, digamos, tradicionais. Alguns exemplos incluem: No entanto, esses componentes não existem de maneira isolada, eles estão conectados aos demais componentes de um sistema de software. E é aí que mora o perigo! Desafios para construção de modelos em sistemas de software No momento em que profissionais de software começaram a fazer deploy de sistemas de software inteligentes, percebeu-se que a engenharia de modelos inteligentes não é algo tão simples assim. Segundo pesquisa da Gartner, dos cerca de 3000 CIOs que responderam a pesquisa, somente 4% já adotaram abordagem inteligentes em seus negócios, enquanto outros 46% têm interesses em adotar. O que é mais interessante é que a pesquisa também mostrou que um grande número de projetos que utilizam componentes inteligentes nunca chegaram a um ambiente de produção. Nem se trata pelo tamanho de linhas dos modelos criados, uma vez que estes modelos de aprendizagem de máquina, geralmente, representam uma parcela pequena do total de linhas de código do produto de software. Neste caso, é preciso lidar com questões de autenticação, segurança, regras de negócio, acesso e manipulação de dados, etc. Razões que podem levar modelos de aprendizado de máquina a se tornarem complexos Os modelos de aprendizado de máquina podem rapidamente se tornar complexos e existem algumas razões que sustentam esse fato: Embora não seja garantido, essas adaptações podem levar a modelos com maiores acurácias e com maior capacidade de generalização. O aprimoramento dos modelos tendem a deixá-los mais complexos, dificultando não somente o seu entendimento por não especialistas, mas também sua manutenção por cientistas de dados. Desafios organizacionais Além das dificuldades técnicas, há também alguns desafios organizacionais, como apontado pelo estudo de Arpteg e colegas. Por exemplo: Estimativa de esforço Em modelos de aprendizado de máquina, como comumente observado em projetos de pesquisa e inovação, o objetivo da tarefa é definido. No entanto, nem sempre é clara a quantidade de esforço necessário para que o modelo alcance esse objetivo; e, dessa forma, a quantidade de ciclos de iterações que serão necessários para alcançar níveis aceitáveis. Entendimento dos modelos Falando de modelos complexos e de difícil entendimento, não é incomum encontrar modelos em que devs ou cientistas de dados tenham dificuldades em entender o comportamento observado. Nesses casos, é ainda mais difícil compreender qual parte do modelo poderia ser modificado para alcançar melhores resultados. Privacidade dos dados A falta de entendimento do comportamento interno de modelos sofisticados pode impactar em questões de segurança e privacidade dos dados. Por exemplo, o conhecimento em uma rede neural é armazenado de maneira distribuída entre os pesos da rede. Logo, é difícil controlar a forma que os dados são armazenados na rede. Em tempos de legislações como a LGPD, conhecer e ter controle sobre como dados de users são tratados adiciona uma camada extra de complexidade a um projeto que utilize modelos inteligentes. Modelos inteligentes e cultura Outro fator importante é que o mundo real é multivariável, e modelos de aprendizado de máquina devem ser avaliados de múltiplas perspectivas. Por exemplo, modelos inteligentes que são integrados em carros autônomos não podem ser avaliados somente com relação a sua acurácia na detecção de objetos, mas também com relação à segurança de quem vai usá-lo. Outros modelos devem ser analisados sob a perspectiva de discriminação ou, até mesmo, da ética. Esses desafios, quando somados, levam a diversas dificuldades do processo de engenharia de modelos inteligentes, devido: Para apoiar melhor cientistas de dados na construção, avaliação e manutenção de seus modelos de software, há uma área de pesquisa chamada “Engenharia de software para Aprendizado de Máquina”, do inglês, Software Engineering for Machine Learning, ou somente SE4ML. Modelos inteligentes e engenharia Quando criamos software com modelos inteligentes, precisamos utilizar práticas de engenharia de software. Uma vez que modelos de aprendizado de máquina podem fornecer respostas incorretas, sistemas de software que utilizam esses modelos precisam ser desenhados para tolerar esses erros. Embora seja uma frase fácil de ser entendida, ela é difícil de ser implementada. Por isso, proponho algumas questões para você pensar: Para responder essas (e outras) perguntas, é preciso ter um entendimento holístico não somente sobre os modelos de aprendizado de máquina, mas também sobre como estes modelos interagem com os demais componentes do sistema de software. Para isso, a área de pesquisa de SE4ML tem como objetivo entender e adaptar práticas da engenharia de software para construção de sistemas que fazem uso de modelos inteligentes. Práticas como engenharia de requisitos, CD/CI, arquitetura de software, monitoramento, versionamento, dentre outras, tem grande possibilidade de aplicação para apoiar o processo de construção e desenvolvimento de modelos inteligentes. Mesmo assim, pesquisas recentes reportaram que poucas são as empresas que adotam essas práticas. Enquanto que algumas práticas de desenvolvimento de software poderiam ser adotadas com facilidade, como o versionamento de código, observado por Serban e colegas, várias dessas práticas precisam ser adaptadas para que sejam utilizadas num cenário de SE4ML. Confira dois exemplos a seguir: Deploy automático Embora práticas de entrega contínua sejam comumente empregadas na indústria de software, realizar deploy automático de modelos de aprendizado de máquina requer cuidado especial. Um dos motivos está relacionado às
DeFi: o que são finanças descentralizadas e tecnologia blockchain
São tantas novidades quando falamos de inovações tecnológicas em sistemas financeiros, não é mesmo? Dentre essas novidades temos o conceito de DeFi, ou finanças descentralizadas, além da tecnologia blockchain, muito usada para criar plataformas para a contratação de produtos e serviços. Neste artigo, quero te apresentar o momento atual do setor financeiro relacionado com a chegada da tecnologia blockchain. Além de falar sobre a sua relevância e os desafios que temos pela frente na área de tecnologia e finanças. O tema ainda oferece a oportunidade de falar da criação de uma categoria especial no setor de tecnologia financeira, o Hybrid Finance. Quer conhecer mais sobre o assunto e refletir sobre o futuro das nossas transações bancárias? Então vem comigo! Antes de avançar mais, o que é blockchain? Para começo de conversa, blockchain é uma tecnologia que atua como um livro-razão descentralizado de qualquer interesse central de controle. Os dados ou transações são registrados em blocos conectados para formar uma cadeia de informações. Devido à sua natureza descentralizada, quanto mais a tecnologia é adotada, mais pessoas colaboram para desenvolver soluções. Uma delas é justamente o DeFi, as finanças descentralizadas. O que é DeFi, ou finanças descentralizadas? DeFi, ou finanças descentralizadas, são um conjunto de códigos autoexecutáveis, habilitados por meio de uma blockchain. O diferencial desse sistema descentralizado é a criação de um ecossistema livre, de confiança, transparência e open-source. Possibilitando, dessa forma, que transações sejam feitas sem intermediários. Essa nova abordagem possui vantagens sobre os sistemas financeiros centralizados convencionais e pode funcionar de maneira mais transparente, sem a necessidade de câmaras de compensação centrais ou serviços de custódia. Ao adotar o DeFi substituímos elementos tradicionais do sistema financeiro centralizado por contratos inteligentes. O que é um contrato inteligente? Mesmo sem a centralização de um sistema financeiro tradicional, os DeFis são seguros justamente por conta de seus contratos inteligentes. Um contrato inteligente estabelece os termos de um acordo, mas é executado como um código autoexecutável em uma blockchain. Com isso, os times podem contar com as vantagens de um desenvolvimento com blockchain, por exemplo, sua segurança e acessibilidade. Nesse caso, os protocolos DeFi são implementados usando aplicativos descentralizados, (dApps) onde muitos dos papéis são por acordos, escrito em linhas de código. Um breve histórico Para se ter ideia, as finanças descentralizadas começaram a ganhar os holofotes no final de 2020, por meio de plataformas como Uniswap, Maker DAO, Aave e Curve. A capitalização de mercado agregada das finanças descentralizadas ultrapassou US$ 87 bilhões do valor total bloqueado em maio de 2021. Em outras palavras, isso tudo é muito recente! Esse “boom” nos últimos anos passou por muitos elementos, que há pouco eram novidades, por exemplo: stablecoins, bitcoin tokenizado, NFTs e empréstimos de dinheiro a plataformas de empréstimos. Isso tudo foi só o começo. Mesmo com tantas vantagens, as finanças descentralizadas também enfrentam muitos desafios que servem como alertas, por exemplo, transações lentas e custos de transação imprevisíveis, às vezes altos, assim como a questão regulatória. Resumindo: as finanças descentralizadas (DeFi) são um instrumento financeiro alternativo, construído por meio da tecnologia blockchain, uma plataforma de registro de dados imutável e inviolável. Arquitetura das finanças descentralizadas A arquitetura das finanças descentralizadas possuem muitas camadas e cada uma delas tem funções específicas. As camadas de uma estrutura DeFi típica são: Quanto mais a tecnologia ganha casos de usos exponenciais por meio de staking, mais a indústria financeira tem uma oportunidade única de contribuir positivamente com o ecossistema financeiro e com o mundo, fornecendo um instrumento alternativo. Por exemplo, ao criar uma plataforma DeFi, permite-se investimentos e empréstimos até mesmo para quem nunca teve contato com essas transações. Os desafios do DeFi Falando do ponto de vista acadêmico, muitos times de pesquisa da área refletiram sobre o aumento da conscientização sobre o DeFi e o projetaram como um instrumento financeiro alternativo emergente [1-3]. Por exemplo, Werner et al. [1] forneceu uma visão geral dos protocolos DeFi com base na operação desta ferramenta e delineou os aspectos técnicos e econômicos de segurança das plataformas DeFi. Afinal, ele pode resolver muitas questões que fazem parte do cotidiano de sistemas tradicionais de finanças centralizadas (CeFi), como acesso, tempo, custo e eficiência [3]. Mesmo que o próprio DeFi forneça um conjunto de novos desafios para o mercado, cito alguns deles abaixo: Regulação e governança Falta clareza regulatória em blockchain, o que é algo que não podemos descuidar. Entre os pontos importantes que deveriam estar contemplados nessa categoria de regulação e governança temos, por exemplo: Privacidade e segurança Por design, as informações sobre DLs (Decentralized Ledger) estão disponíveis para toda a rede de participantes. No livro-razão, as contrapartes podem explorar o histórico de transações, incluindo aquelas das quais não fazem parte, sem a necessidade de permissões. Em termos de segurança, falta aos sistemas de blockchain um modelo de antifraude robusto, como KYC e AML, é visível que existem desafios em vincular a criptografia de identidades para as identidades do mundo real. Embora seja possível identificar o proprietário de um endereço usado para o dinheiro, não seria possível bloquear tais transações antecipadamente. Em outras palavras, as cadeias de transações anônimas são visíveis para todo mundo e podem ser rastreadas publicamente. Risco comportamental e de transição Mesmo que não seja uma unanimidade entre especialistas, existem riscos de falta de cooperação e colaboração entre as partes interessadas, como reguladores, bancos, empresas e entidades comerciais, bolsas, serviços de compensação e liquidação, e outros. Esse relacionamento precisa ser acertado para darmos novos passos no sistema DeFi. Risco de liquidação A liquidação definitiva é um requisito legal na compensação e liquidação pós-negociação. Porém, por design, blockchains públicos não podem garantir o caráter definitivo da liquidação. Como resultado, a responsabilidade legal pode ser ambígua ou difícil de atribuir. Riscos tecnológicos Além de todos os desafios mencionados, a adoção do blockchain pela Instituições Financeiras (FIs) também pode ser afetada por impasses tecnológicos, como: (a) Performance – muitos aplicativos de blockchain têm demonstrado baixa escalabilidade, atrasos no processamento de transações e problemas de latência, sendo que sua implantação exige
Open Data: definições e questões sobre abertura de dados
Dados fazem parte direta ou indireta de nosso cotidiano: ao acessar redes sociais, aplicativos de mobilidade ou até mesmo sites de compra. O constante aumento do volume e da variedade das informações abre espaço para que diversos serviços, muitos que ainda nem imaginamos, possam ser construídos e disponibilizados. Em paralelo a isso, há um grande movimento global chamado Open Data (Dados Abertos). O Open data prega que dados possam ser acessados por empresas, instituições e times de pesquisa de maneira mais fácil e livre. De forma aberta. Quer saber mais sobre o que é Open Data, seus desdobramentos no mundo acadêmico e corporativo e de quebra entender sobre Open Finance? Então continue lendo! Mas o que é Open Data? O portal The Open Data Handbook, mantido pelo Open Knowledge Foundation, traz uma definição sobre o tema: “Dados abertos são dados que podem ser livremente usados, reutilizados e redistribuídos por qualquer pessoa – sujeitos, no máximo, à exigência de atribuição da fonte e compartilhamento pelas mesmas regras.” (DIETRICH et all, s/d.) Origem Para entender melhor o contexto do Open Data é bom retomar um pouco de sua História. O debate por trás desse movimento não é novo, até pode-se entender que é uma certa expansão ou continuidade de um debate antigo, datado ainda da primeira metade do século XX, presente no mundo acadêmico: o de deixar público a metodologia de trabalho adotada em pesquisas, assim como seus resultados. O movimento ganhou, de fato, força ao longo de 2010 como consequência de debates iniciados por ativistas e pensadores norte-americanos, envolvidos também em iniciativas de softwares open source, em 2007. O que caracteriza um dado aberto? Para os dados se tornarem, de fato, abertos, ainda de acordo com o The Open Data Handbook, sua disponibilização deve seguir o princípio da interoperabilidade, ou seja, de serem passíveis de serem utilizados e reutilizados a partir da sua combinação com diferentes fontes. Para a concretização do princípio, a empresa / instituição / time de pesquisa responsável deve considerar os seguintes pontos: (DIETRICH et all, s/d.) Importante ressaltar que junto dos dados é essencial documentação coerente: dicionário de dados, informações da licença que estão ancorados e para quais finalidades podem ser usados. Tecnicamente falando, a disponibilização dos dados pode se dar de diferentes formas, por exemplo, através de download direto de arquivos (csvs, json, xml, txt, xlxs…) ou através de APIs. Abertura de dados por instituições públicas O movimento de abertura de dados por parte de instituições públicas é diferente do que ocorre em instituições privadas. Pode-se dizer que a diferença se dá não somente no escopo, mas também nos objetivos e motivações. Em âmbito de Estados, a questão é uma conquista da própria sociedade civil a partir da aprovação de instrumentos legais como, por exemplo, a lei complementar de transparência de 2009 e a lei de acesso à informação de 2011. É um movimento do Estado para a população, em que um dos intuito é o de acompanhar o que está sendo feito e qual verba está sendo empregada. A título de exemplo, o site dados.gov.br, disponibilizado pelo governo brasileiro, é um dos modelos que podem ser seguidos. Além de deixar público para download diversos conjuntos de dados, muitos acompanham sua descrição e dicionário, assim como a Política de uso deles é de fácil acesso (disponível aqui). Abertura de dados por instituições privadas O mercado privado não está submisso às mesmas questões legais acima citadas, mas cada vez mais existem iniciativas que buscam beber do movimento do Open Data. Open Finance Um dos grandes desdobramentos do Open Data no setor financeiro é o chamado Open Finance. Esse termo pode gerar confusão com outro termo, o “Open Banking”, e, de fato, havia diferença entre ambos. Em março de 2022, entretanto, o Banco Central percebeu que o uso de diferentes nomenclaturas para iniciativas muito parecidas poderia gerar confusão e decidiu acatar o termo Open Finance como único e correto para tratar da iniciativa de compartilhamento de dados de clientes, com consentimento, entre instituições financeiras. Você pode ler sobre essa decisão no site oficial do Banco Central. Em contrapartida, olhar de auditoria na relação sociedade e Estado, dentro do Open Finance é o próprio cliente que disponibiliza seus dados junto de termo de consentimento para, entre outros objetivos, receber produtos personalizados. Ao mesmo tempo, as próprias instituições bancárias, corretoras, companhias de câmbio e fundos de previdência (entre outras) trocam informações sobre clientes visando diminuir risco da eventual inadimplência a partir da concessão de um empréstimo. É importante destacar que para aderência ao programa de Open Finance as instituições financeiras precisam passar pela aprovação do Conselho Monetário Nacional e pelo Banco Central, assim como garantir alinhamento com “boas práticas de governança, como políticas de controles internos, gestão de riscos, auditoria, transparência e de comunicação” (BANCO CENTRAL DO BRASIL, 2022). As instituições participantes também precisarão estar em conformidade com as normas periodicamente publicadas pelo Banco Central do Brasil. Etapas do Open Finance A implementação do Open Finance, que até a 3a fase era chamado Open Banking, segue o seguinte cronograma: (adaptado de OPEN BANKING BRASIL, s/d) Você pode saber mais sobre as fases de implementação do Open Banking no Brasil neste artigo e saber quais instituições participam neste link. Quer conhecer mais sobre Open Finance e Open Data? Então ouça o episódio do Zupcast sobre o tema: E não vai parar no Open Finance… Dentro do Open Finance ainda existem outras duas iniciativas: Open Insurance e o Open Investment, que caminham junto também da quarta fase de implementação e são direcionados a tipos de instituições específicas, como seguradoras e investidoras. Neste sentido, entende-se que Open Data têm beneficiado e muito o setor financeiro e de serviços. Outros desdobramentos do Open Data Para além dos exemplos de iniciativas de Open Data apresentados, pode-se encontrar desdobramentos para outros fins, como educacionais, acadêmicos e até mesmo dentro do próprio mundo corporativo. Educacionais Para fins educacionais, dados podem ser encontrados em sites dedicados à comunidade de profissionais de dados, por exemplo, o site Kaggle.
Satisfação na Engenharia de Software: entenda como funciona
O que é satisfação e como funciona a satisfação na Engenharia de Software? Com base nessas perguntas, vamos conhecer pesquisas sobre o tema e descobrir como aplicar boas práticas para ter um time satisfeito no trabalho de desenvolvimento de software. Pesquisas sobre satisfação Este artigo é a continuação do anterior que apresentava os principais conceitos sobre Motivação na Engenharia de Software. Pode continuar a leitura, contudo sugiro que leia o post anterior para ter um contexto mais aprofundado. Isso se deve ao fato de que a motivação e a satisfação são fatores que estão muito próximos um do outro, não só nas pesquisas, mas também no dia a dia de trabalho. Muitas teorias, como a Teoria de Motivação de Herzberg, investigam os dois conceitos em simultâneo. Na Engenharia de Software até mais ou menos metade dos anos 2010’s, era muito comum observar pesquisas confundirem os dois termos. Recentemente, avaliei um artigo para congresso e o time de pesquisa afirmava que investigava motivação, só que avaliavam a satisfação das pessoas. É, de fato, algo muito próximo. Na Engenharia de Software, o trabalho que mudou essa visão foi a tese de César França e principalmente seu artigo “Motivation and Satisfaction of Software Engineers”. Este trabalho apresenta uma teoria da motivação e satisfação de pessoas engenheiras de software chamada: Theory of Motivation and Satisfaction of Software Engineers – (TMS – SE). É sobre essa teoria que iremos falar neste artigo. Por que falar sobre satisfação no trabalho? Antes de entrar em detalhes nós precisamos entender qual a importância da satisfação do trabalho no contexto de desenvolvimento de software. A relação mais clara e uma das mais estudadas é a relação da satisfação com o turnover, ou seja, pedidos de demissão. De acordo com Westlund e Hannon (2008), pessoas mais satisfeitas tendem a ter uma menor intenção de turnover. Acunhã et al. (2009) realizaram estudos no contexto de software e encontraram uma pequena correlação positiva entre a satisfação do trabalho e a qualidade do software. Portanto, existe uma leve relação entre pessoas que estão satisfeitas com o trabalho e a qualidade do software produzido (mensurado com quantidade de defeitos detectados, número de requisitos satisfeitos, número de módulos reusáveis, etc.) Ribeiro (2020) também investigou profissionais de desenvolvimento de software e encontrou algumas relações interessantes: pessoas que se acham mais adaptáveis também se sentem mais satisfeitas com o trabalho na Engenharia de Software. Além disso, existe uma correlação negativa entre a satisfação e todas as dimensões do burnout (exaustão, cinismo e baixa autoeficácia). Em outras palavras, pessoas que estão mais satisfeitas com o trabalho tendem a ter menores índices de percepção de burnout. Poderíamos passar uma eternidade comentando dos resultados, porque existem quase 600 mil artigos sobre o tema satisfação no contexto de desenvolvimento de software. Para te ajudar a compreender o assunto, nas próximas seções, nós vamos definir o que é satisfação e entender o que pode influenciar a satisfação conforme a TMS-SE. Teoria da Satisfação na Engenharia de Software Para Locke (1976), a satisfação com o trabalho pode ser definida como um estado emocional prazeroso ou positivo resultante da avaliação do indivíduo sobre o trabalho, ou das experiências de trabalho vividas por ele. Para França et al. (2018), a satisfação com o trabalho é operacionalizada enquanto o indivíduo está feliz em trabalhar naquela organização. De acordo com Graziotin et al. (2018), essa felicidade, ou a falta dela, tem um conjunto de consequências para as pessoas desenvolvedoras de software. Quando profissionais sentem mais satisfação, tendem a: Ainda de acordo com Graziotin et al. (2018), quando as pessoas não estão felizes, algumas consequências negativas podem aparecer, por exemplo: A partir da definição e de uma investigação, França et al. (2018) desenvolveram a teoria apresentada na imagem abaixo. Fatores-chave Para França et al. (2018), as características do trabalho contém os principais influenciadores da satisfação (felicidade) das pessoas desenvolvedoras. São elas: Quem trabalha com desenvolvimento sente satisfação quando recebe bem e tem bons benefícios, que façam sentido para o que acredita como justo. As pessoas também se sentem satisfeitas quando seus pares e sua liderança direta reconhecem o seu trabalho. Além disso, elas se sentem mais satisfeitas quando são promovidas ou tem essa possibilidade de promoção muito clara e alcançável para conseguir. Fatores moderadores Os três pontos anteriores são chaves para manter as pessoas satisfeitas. No entanto, existem outros fatores observados que atuam como moderadores da relação entre os fatores-chave e a satisfação. Os autores afirmam que existem características da empresa, da parte da liderança e dos outros indivíduos da equipe que podem ajudar a maximizar o impacto dos fatores-chave na satisfação. Como tipo de atividades da empresa, decisões sobre situações, linguagem escolhida, burocracia, etc. Tudo isso pode impactar a satisfação das pessoas. Quando falamos de posição de liderança, características da função, confiança, maneira de conversar, entre outros aspectos, podem ajudar a diminuir ou até mesmo aumentar o impacto dos fatores-chave na satisfação. Por fim, mas não menos importante, como as pessoas enxergam colegas de equipe também influencia essa relação. Outros fatores também moderam a relação entre as características do trabalho e a satisfação. Como o desempenho, as características individuais (por exemplo, adaptabilidade, personalidade, entre outros) e os feedbacks recebidos. Os indivíduos obtêm satisfação quando conseguem produzir resultados tão bons ou melhores do que foi planejado anteriormente. Isso evidencia o quão importante é a atividade de planejamento para a satisfação de profissionais da engenharia de software, porque mostra que o planejamento é fonte primária para o estabelecimento das expectativas dos indivíduos, que por sua vez é responsável pelo julgamento de valor sobre seu próprio desempenho. Motivação x Satisfação Por fim, os autores comentam que existe uma relação muito forte entre a motivação e a satisfação. Para França et al. (2018) a satisfação no trabalho é o estado emocional prazeroso resultante da avaliação que o indivíduo faz do seu trabalho, conquistando ou permitindo a realização de valores importantes do trabalho para ele, enquanto que a motivação refere-se ao desejo que o indivíduo tem para trabalhar. Portanto, a motivação acontece
10 boas práticas e dicas para usar o GitHub Actions
O seu fluxo de trabalho usando o GitHub Actions será ainda mais otimizado com essas dicas e boas práticas. Leia mais no blog!
Motivação na Engenharia de Software: o que sabemos? Como usar ao nosso favor?
Quando se tem contato com a literatura recente, assim como as práticas realizadas no mercado, tem se observado um interesse maior nas práticas de gestão de comportamento. Pensando nisso, aqui estão bons insights sobre motivação na Engenharia de Software para gerir sua equipe. O objetivo deste artigo é trazer uma luz sobre a teoria da motivação no contexto de desenvolvimento de software. Com base nos principais estudos da área e a partir de trabalhos conceituados, de maneira menos densa, mas carregando os principais resultados para serem aplicados por você, leitor, na prática. Contextualizando o assunto Boa parte desse interesse em motivação tem sido suportado por duas premissas para a efetividade do trabalho: a primeira corresponde à necessidade de criação de ferramentas, que impulsionam um melhor clima organizacional, e a segunda é a ideia de que pessoas motivadas produzem mais. A motivação em especial é um tema bastante debatido informal e formalmente em diversas indústrias, inclusive na de desenvolvimento de software. Líderes desejam que suas equipes sejam as mais motivadas possíveis, mas eu gostaria que você refletisse sobre algumas questões que ouço muito: Tenho certeza que várias pessoas têm diferentes respostas sobre esses questionamentos. Assim como acredito que todas essas perguntas são relevantes quando queremos construir times de alta performance. Pesquisas acadêmicas sobre motivação A boa notícia é que essas perguntas fazem sentido não só para você, como também para times de pesquisa da academia. Por exemplo, eu tenho dois trabalhos que buscam entender como funciona a motivação no contexto open source / software livre. A pergunta principal dos trabalhos é: afinal, por que alguém trabalha de graça, em seu horário livre, feliz e alegre? Para essas respostas você pode conferir estes dois artigos: Motivação de Engenheiros de Software no Contexto Open Source e Open Source: o que está por trás da motivação dos desenvolvedores?. Você também pode esperar o próximo post do blog e te adianto um spoiler: mesmo nesses contextos, as pessoas buscam autopromoção também. Outro pesquisador brasileiro com vários trabalhos na área é César França, que tem diversos estudos na área de Engenharia de Software sobre o tema. É com base na tese dele, defendida em 2014, e neste artigo que reúne os resultados da pesquisa, que iremos seguir nossa conversa. O que é motivação? De acordo com França (2009), a motivação é motivo de estudo desde o século XX, a partir do interesse de times de pesquisa sobre temas como teoria da aprendizagem. Contudo, o tema isoladamente começou a ser popular na década de 30 na psicologia e na administração. Um ponto interessante levantado pelo autor que surge desde aquela época é a falta de uma definição universal sobre o que é motivação, embora exista uma infinidade de possíveis definições (BUENO, 2002; SALGADO, 2005). Ao olharmos para o dicionário, motivação pode ser definida como: “um conjunto de fatores, os quais agem entre si e determinam a conduta de um indivíduo“. (AURÉLIO, 2004) “o ato de despertar interesse por algo, uma reunião de razões pelas quais alguém age de certa forma” (Dicio). O que chama a atenção nessas duas definições é que motivação é “força” que faz com que o indivíduo aja de alguma forma em busca de algo. Golembiewski (2005), comenta que a motivação é interna ao indivíduo, ou seja, depende das suas percepções e pode mudar de pessoa para pessoa, variando de acordo com o objetivo. Portanto, pode diferir de acordo com o que se deseja buscar; apresenta intensidade, força e duração; e é capaz de determinar o comportamento. Para Chiavenato (1999) a motivação é a vontade de exercer atividades com alto nível de esforço, de modo que pode ir ao encontro de objetivos organizacionais, satisfazendo também os objetivos individuais. Com isso, a motivação passa a depender de direção, força, comportamento, duração e persistência. Motivação na Engenharia de Software França et al. (2018) conduziu uma investigação com pessoas desenvolvedoras de diferentes contextos (pública x privada x grande x pequena) em busca de entender o significado de motivação. Como resultado foi observado que a motivação pode ser caracterizada como um conjunto de forças internas e externas que levam profissionais desenvolvedores de software a terem foco e engajamento em suas tarefas. Onde o foco pode ser interpretado como o nível de atenção que devs dão em suas atividades e o engajamento é expresso como o nível de esforço aplicado na tarefa. Portanto, alguém motivado no desenvolvimento de software deve ser uma pessoa focada e engajada nos seus objetivos. Além disso, França et al. (2018) também apresenta quatro categorias: cuidado, comprometimento, trabalho duro e interesse, que ajudam a caracterizar pessoas motivadas a olharem para o foco e o engajamento. Por exemplo, a falta de cuidado ocorre quando alguém está distraído com a tarefa e não está focado. Uma pessoa engajada com seu trabalho deveria também estar interessada nos resultados dele, assim como do trabalho como um todo; e também estaria “dando duro” (hard-working) em suas atividades. Vale ressaltar que esses comportamentos podem ser observados antes e depois da execução de uma tarefa (FRANÇA et al. 2018). Por fim, é esperado que nesta seção você perceba que existem diversas definições, inclusive, outras além das apresentadas que, em geral, falam de objetivos, esforço, força, fatores internos e externos dos indivíduos. Neste artigo, nós iremos utilizar a definição proposta por França et al. (2020) por ela ter surgido de um contexto de desenvolvimento de software. Teoria da motivação na Engenharia de Software Primeiramente, é importante lembrar que existem diferentes perspectivas quando falamos de motivação. Este artigo não irá entrar em detalhes sobres essas perspectivas, mas basicamente essas perspectivas são complementares e dependem de como você está investigando a motivação. Alguns exemplos são: a teoria da hierarquia das necessidades de Marslow, a teoria de expectativa de Victor Vroom, teoria dos dois fatores de Herzberg, e a teoria das características do trabalho de Hackman e Oldham. Para ter conhecimento geral sobre eles, você pode consultar este link sobre teorias motivacionais. Dito isto, vamos nos concentrar em entender a principal teoria desenvolvida para a