Menu

Técnicas

ADOTE?

  • Cada vez mais empresas estão construindo plataformas internas para implantar novas soluções digitais de maneira rápida e eficiente. As empresas que obtêm sucesso com essa estratégia estão aplicando gestão de produto a plataformas internas. Isso significa estabelecer empatia com o público consumidor interno (os times de desenvolvimento) e colaborar com eles no design. Gerentes de produto da plataforma criam roteiros e garantem que a plataforma agregue valor aos negócios e aprimore a experiência de desenvolvimento. Infelizmente, também estamos vendo abordagens menos bem-sucedidas, nas quais os times criam uma plataforma vazia, com base em suposições não-verificadas e sem considerar clientes internos. Essas plataformas frequentemente, apesar de táticas internas agressivas, acabam sendo subutilizadas e prejudicam a capacidade de entrega da organização. Como sempre, uma boa gestão de produto tem a ver com a construção de produtos que o público consumidor adora.

    Histórico
  • Embora a infraestrutura como código seja uma técnica relativamente antiga (que destacamos no Radar em 2011), ela se tornou extremamente importante na era moderna da nuvem, em que o ato de configurar a infraestrutura se tornou a aprovação das instruções de configuração para uma plataforma em nuvem. Quando dizemos "como código", queremos dizer que todas as boas práticas que aprendemos no mundo do software devem ser aplicadas à infraestrutura. Uso do controle de origem, adesão ao princípio DRY, modularização, manutenção e uso de testes e implantação automatizados são práticas fundamentais. Aquelas de nós com profundo conhecimento de software e infraestrutura precisam ter empatia e apoiar colegas que ainda não o têm. Dizer "trate a infraestrutura como código" não é suficiente, precisamos garantir que os aprendizados conquistados com muito esforço no mundo do software sejam aplicados de forma consistente em todo o domínio da infraestrutura.

    Histórico
  • Temos visto significativos benefícios de se introduzir microsserviços, que permitem aos times escalar a entrega de serviços mantidos e implantados independentemente. Infelizmente, também vemos muitos times criarem um monólito de frontend – uma grande e confusa aplicação de navegador que fica em cima de serviços de backend –, neutralizando fortemente os benefícios dos microsserviços. Os micro frontends continuam a ganhar popularidade desde que foram introduzidos. Temos visto muitos times adotarem alguma forma dessa arquitetura como uma maneira de gerenciar a complexidade de múltiplas pessoas desenvolvedoras e times contribuindo para a mesma experiência de usuário. Em junho deste ano, um dos criadores dessa técnica publicou um artigo introdutório, que serve como referência para micro frontends. Ele mostra como esse estilo pode ser implementado usando vários mecanismos de programação web e constrói um exemplo de aplicação usando React.js. Estamos confiantes de que esse estilo vai crescer em popularidade à medida que grandes organizações tentam dividir o desenvolvimento de UI entre múltiplos times.

    Histórico
  • A técnica de pipelines como código enfatiza que a configuração dos pipelines de entrega que criam, testam e implantam nossas aplicações ou infraestrutura deve ser tratada como código. Eles devem ser colocados sob controle de origem e modularizados em componentes reutilizáveis com teste e implantação automatizados. À medida que as organizações transitam para times autônomos descentralizados, construindo microsserviços ou micro frontends, a necessidade de práticas de engenharia no gerenciamento de pipelines como código aumenta, para que os times continuem criando e implantando software consistente dentro da organização. Essa necessidade deu origem a modelos e ferramentas de pipeline de entrega que permitem uma maneira padronizada de criar e implantar serviços e aplicações. Essas ferramentas usam pipelines de entrega declarativos das aplicações, adotando um blueprint de pipeline para executar as tarefas subjacentes a vários estágios de um ciclo de entrega — como compilação, teste e implantação —, e eles abstraem os detalhes da implementação. A capacidade de criar, testar e implantar pipelines como código deve ser um dos critérios de avaliação para a escolha de uma ferramenta de CI/CD.

    Histórico
  • Acreditamos firmemente que a programação em pares melhora a qualidade do código, difunde conhecimento entre todo o time e permite a entregar software com mais rapidez. No mundo pós-COVID, no entanto, muitos times de software serão distribuídos ou totalmente remotas e, nessa situação, recomendamos pareamento remoto pragmático : ajustar as práticas de pareamento ao que é possível dadas as ferramentas disponíveis. Considere ferramentas como Visual Studio Live Share para uma colaboração eficiente e de baixa latência. Somente recorra ao compartilhamento de pixels se as duas pessoas participantes residirem em relativa proximidade geográfica e tiverem conexões de Internet de alta largura de banda. Junte pares que estejam em fusos horários semelhantes, em vez de esperar que o pareamento funcione independentemente da localização das pessoas participantes. Se o pareamento não estiver funcionando por razões logísticas, retorne a práticas como programação individual aumentada por meio de revisões de código, colaboração por pull-request (mas atente-se para branches de longa duração com Gitflow) ou sessões de pareamento mais curtas para partes críticas do código. Praticamos pareamento remoto há anos e achamos que ele é eficaz se realizado com uma dose de pragmatismo.

    Histórico
  • Infelizmente, feature toggles são menos comuns do que gostaríamos, e muitas vezes vemos pessoas misturando seus tipos e casos de uso. É bastante comum encontrar times que usam plataformas pesadas como LaunchDarkly para implementar feature toggles, incluindo release toggles, para se beneficiar da Integração Contínua, quando tudo o que você precisa são condicionais if/else. Portanto, a menos que você precise de testes A/B ou releases canário, ou transferir a responsabilidade de feature releases a pessoas de negócios, recomendamos que você use feature toggles mais simples possíveis em vez de frameworks de feature toggles desnecessariamente complexos.

    Histórico

EXPERIMENTE?

  • Aplicar aprendizado de máquina para tornar serviços e aplicações de negócios inteligentes é mais do que apenas treinar servir modelos. Requer a implementação de ciclos completos e repetíveis de treinamento, testes, implantação, monitoramento e operação dos modelos. Entrega contínua para aprendizado de máquina (CD4ML) é uma técnica que permite ciclos de desenvolvimento de ponta-a-ponta confiáveis, implantação e monitoramento de modelos de aprendizado de máquina. A stack tecnológica subjacente para ativar CD4ML inclui ferramentas para acessar e descobrir dados, controle de versão de artefatos (como dados, modelo e código), pipelines de entrega contínua, provisionamento de ambiente automatizado para várias implantações e experimentos, avaliação e rastreamento de desempenho e modelo, e observabilidade de modelo operacional. As empresas podem escolher seu próprio conjunto de ferramentas, dependendo da stack tecnológica existente. CD4ML enfatiza a automação e a remoção de transferências manuais. CD4ML é a nossa abordagem de escolha para o desenvolvimento de modelos de aprendizado de máquina.

    Histórico
  • No ano passado, vimos uma mudança no interesse em torno de aprendizado de máquina e de redes neurais profundas em particular. Até agora, o desenvolvimento de ferramentas e técnicas foi impulsionado pelo entusiasmo com as notáveis capacidades desses modelos. Atualmente, porém, há uma preocupação crescente de que esses modelos possam causar danos não-intencionais. Por exemplo, um modelo pode ser treinado para tomar decisões de crédito inadvertidamente, simplesmente excluindo pessoas candidatas desfavorecidas. Felizmente, estamos vendo um interesse crescente em testes de viés ético , que ajudarão a apontar decisões potencialmente prejudiciais. Ferramentas como lime, AI Fairness 360 ou What-If Tool podem ajudar a descobrir imprecisões resultantes de grupos sub-representados em dados de treinamento, enquanto ferramentas de visualização como Google Facets ou Facets Dive podem ser usadas para descobrir subgrupos em um corpus de dados de treinamento. Utilizamos lime (local interpretable model-agnostic explanations, ou explicações independentes de modelo interpretáveis localmente), além desta técnica, para entender as previsões de qualquer classificador de aprendizado de máquina e o que os classificadores (ou modelos) estão fazendo.

    Histórico
  • Vemos mais e mais ferramentas como Apollo Federation, que pode agregar vários endpoints do GraphQL em um único grafo. No entanto, advertimos contra o uso indevido do GraphQL, especialmente ao transformá-lo em um protocolo de servidor para servidor. Nossa prática é usar GraphQL para agregação de recursos do lado do servidor apenas. Ao usar esse padrão, os microsserviços continuam a expor APIs RESTful bem definidas, enquanto serviços agregados ocultos ou BFF (Backend for Frontends) usam os resolvedores GraphQL como a implementação para combinar recursos de outros serviços. A forma do grafo é orientada por exercícios de modelagem de domínio para garantir que a linguagem onipresente seja limitada a subgrafos quando necessário (no caso de "um microsserviço por bounded context"). Essa técnica simplifica a implementação interna de serviços agregados ou BFFs, incentivando uma boa modelagem de serviços para evitar REST anêmico.

    Histórico
  • Desde que a introduzimos no Radar em 2016, vimos a adoção generalizada de micro frontends para UIs web. Recentemente, no entanto, temos visto projetos ampliando esse estilo arquitetural para incluir também micro frontends para aplicativos móveis. Quando o aplicativo se torna suficientemente grande e complexo, torna-se necessário distribuir o desenvolvimento entre vários times, introduzindo o desafio de manter a autonomia dos times enquanto integram seu trabalho em um único aplicativo. Embora tenhamos visto times criando seus próprias frameworks para permitir esse estilo de desenvolvimento, estruturas de modularização existentes como Atlas e Beehive também pode simplificar o problema de integrar o desenvolvimento de aplicativos por múltiplos times.

    Histórico
  • A adoção de nuvem e DevOps, embora aumente a produtividade dos times que agora podem se mover mais rapidamente com dependência reduzida de infraestrutura e times de operações centralizados, também restringiu os times que não possuem as habilidades necessárias para autogerenciar uma stack completa de aplicativos e operações. Algumas organizações enfrentaram esse desafio criando times de produto de engenharia de plataforma. Esses times mantêm uma plataforma interna que permite aos times de entrega implantar e operar sistemas com prazo de entrega reduzido e complexidade de stack. A ênfase aqui está nas ferramentas de autoatendimento e suporte orientadas à API, com os times de entrega ainda responsáveis por dar suporte ao que implementam na plataforma. As organizações que consideram estabelecer um time de plataforma devem ter muito cuidado para não criar acidentalmente um time separado de DevOps, nem devem simplesmente renomear sua estrutura existente de hospedagem e operações como uma plataforma. Se você está se perguntando qual é a melhor configuração para os times de plataforma, usamos os conceitos de topologias de time para dividir os times de plataforma em nossos projetos em times de enablement, times de "plataforma em uma plataforma" plataforma e times com foco no fluxo.

    Histórico
  • Políticas de segurança são regras e procedimentos que protegem nossos sistemas de ameaças e interrupções. Por exemplo, políticas de controle de acesso definem e fazem cumprir quem pode acessar quais serviços e recursos sob quais circunstâncias; já políticas de segurança de rede podem dinamicamente limitar a taxa de tráfego de um serviço específico. A complexidade do cenário de tecnologia atualmente exige o tratamento das políticas de segurança como código : definir e manter as políticas sob sistemas de controle de versão, validá-las automaticamente, implantá-las automaticamente e monitorar suas performances. Ferramentas como a Open Policy Agent ou plataformas como Istio oferecem maneiras flexíveis de definição e execução de tais políticas e suportam a prática de políticas de segurança como código.

    Histórico
  • Loops de aprendizado semi-supervisionados são uma classe de fluxos de trabalho iterativos de aprendizado de máquina que aproveitam os relacionamentos encontrados em dados não-rotulados. Essas técnicas podem melhorar os modelos combinando conjuntos de dados rotulados e não-rotulados de várias maneiras. Em outros casos, eles comparam modelos treinados em diferentes subconjuntos de dados. Diferentemente do aprendizado não-supervisionado, em que uma máquina infere classes em dados não-rotulados ou técnicas supervisionadas nas quais o conjunto de treinamento é totalmente rotulado, as técnicas semi-supervisionadas aproveitam um pequeno conjunto de dados rotulados e um conjunto muito maior de dados não-rotulados. O aprendizado semi-supervisionado também está intimamente relacionado às técnicas de aprendizado ativo, nas quais um ser humano é direcionado para rotular seletivamente pontos de dados ambíguos. Como as pessoas especialistas que podem rotular dados com precisão são um recurso escasso e a rotulagem costuma ser a atividade que consome mais tempo no fluxo de trabalho de aprendizado de máquina, as técnicas semi-supervisionadas reduzem o custo do treinamento e tornam o aprendizado de máquina viável para uma nova classe de usuários. Também estamos vendo a aplicação de técnicas pouco supervisionadas, em que os dados rotulados por máquina são usados, mas são menos confiáveis do que os dados rotulados por humanos.

    Histórico
  • Nós havíamos incluído essa técnica em Avalie anteriormente. As inovações no cenário do PLN continuam em um ótimo ritmo, e conseguimos aproveitar essas inovações em nossos projetos graças à onipresente transferência de aprendizado para PLN. As pontuações do benchmark GLUE (um conjunto de tarefas de compreensão de linguagem) tiveram um progresso dramático nos últimos dois anos, com pontuações médias passando de 70,0 no lançamento para líderes ultrapassando 90,0 em abril de 2020. Muitos de nossos projetos no domínio PLN são capazes de atingir progressos significativos, iniciando a partir de modelos pré-treinados do ELMo, BERT e ERNIE, entre outros, e depois ajustando-os com base nas necessidades do projeto.

    Histórico
  • Os times distribuídos podem ter diferentes formatos e configurações. Os times de entrega com configuração 100% co-localizada em um único local, no entanto, tornaram-se exceção para nós. A maioria de nossos times se distribui em várias localizações ou tem pelo menos alguns membros trabalhando remotamente. Portanto, adotar processos e abordagens "nativamente remotos" por padrão pode ajudar significativamente no fluxo e na eficácia gerais do time. Isso começa com a garantia de que todos os membros tenham acesso aos sistemas remotos necessários. Além disso, usar ferramentas como Visual Studio Live Share, MURAL ou Jamboard transforma workshops online e pareamento remoto em rotinas, em vez de exceções ineficazes. Mas o "nativamente remoto" vai além de levar e substituir práticas co-localizadas para o mundo digital: adotando comunicação mais assíncrona, ainda mais disciplina em torno da documentação das decisões, e reuniões com "todo mundo sempre remoto" são outras abordagens praticadas por nossos times por padrão para otimizar a fluidez independente da localização.

    Histórico
  • Atualmente, o panorama tecnológico das organizações é cada vez mais complexo, com ativos — dados, funções, infraestrutura e usuários — espalhados pelos limites de segurança, como hosts locais, vários provedores de nuvem e uma variedade de fornecedores de SaaS. Isso exige uma mudança de paradigma no planejamento da segurança corporativa e na arquitetura dos sistemas, passando do gerenciamento estático e de mudanças lentas de políticas de segurança, baseado em zonas de confiança e configurações de rede, para a aplicação dinâmica e refinada das políticas de segurança baseadas em privilégios de acesso temporais.

    A arquitetura de confiança zero (zero-trust architecture ou ZTA) é a estratégia e a jornada de uma organização para implementar princípios de segurança de confiança zero para todos os seus ativos — como dispositivos, infraestrutura, serviços, dados e usuários — e inclui práticas de implementação, como garantia de acesso e comunicações independentemente da localização da rede, aplicação de políticas como código baseado no menor privilégio e o mais granular possível, e monitoramento contínuo e mitigação automatizada de ameaças. Nosso Radar reflete muitas das técnicas habilitadoras, como política de segurança como código, sidecars para segurança de endpoint e BeyondCorp. Se você estiver migrando para ZTA, consulte a publicação do NIST sobre ZTA para saber mais sobre os princípios, componentes de tecnologia habilitadores e padrões de migração, bem como a publicação do Google no BeyondProd.

    Histórico

AVALIE?

  • A malha de dados é um paradigma arquitetural e organizacional que desafia a antiga suposição de que devemos centralizar grandes volumes de dados analíticos para usá-los, manter todos os dados em um só lugar ou gerenciá-los por meio de um time de dados centralizado para entregar valor. A noção de malha de dados afirma que, para que o big data incentive a inovação, sua propriedade deve ser compartilhada entre as partes proprietárias dos dados do domínio responsáveis pelo fornecimento de dados como produtos (com o suporte de uma plataforma de dados de autoatendimento para abstrair a complexidade técnica envolvida no fornecimento de produtos de dados). Também deve-se adotar uma nova forma de governança compartilhada por meio da automação, para permitir a interoperabilidade de produtos de dados orientados ao domínio. A descentralização, juntamente com a interoperabilidade e o foco na experiência de quem consome os dados, são essenciais para a democratização da inovação no uso de dados.

    Histórico
  • Desde o nascimento da Internet, o cenário tecnológico experimentou uma evolução acelerada em direção à descentralização. Embora protocolos como HTTP e padrões de arquitetura como microsserviços ou malha de dados permitam implementações descentralizadas, o gerenciamento de identidades permanece centralizado. O surgimento da tecnologia de ledger distribuído (DLT), no entanto, habilita a possibilidade do conceito de identidade descentralizada. Em um sistema de identidade descentralizada, as entidades – unidades identificáveis, como pessoas, organizações e outras coisas – são livres para usar qualquer root compartilhada de confiança. Por outro lado, os sistemas convencionais de gerenciamento de identidades são baseados em autoridades e registros centralizados, como serviços de diretório corporativo, autoridades de certificação ou registros de nomes de domínio.

    O desenvolvimento de identificadores descentralizados – identificadores globalmente únicos, persistentes e auto-soberanos que são criptograficamente verificáveis – é um dos principais padrões de habilitação. Embora as implementações em escala de identificadores descentralizados ainda sejam raras, estamos otimistas com a premissa desse movimento e começamos a usar o conceito em nossas arquiteturas. Para os últimos experimentos e colaborações do setor, consulte a Decentralized Identity Foundation.

    Histórico
  • Muitos pipelines de dados são definidos em um script grande, mais ou menos imperativo, escrito em Python ou Scala. O script contém a lógica das etapas individuais, bem como o código que as une. Quando confrontadas com uma situação semelhante nos testes Selenium, as pessoas desenvolvedoras descobriram o padrão Objeto de Página e, posteriormente, muitos frameworks de desenvolvimento orientado a comportamento (BDD) implementaram uma divisão entre as definições de etapas e sua composição. Agora, alguns times estão tentando trazer o mesmo pensamento para a engenharia de dados. Uma definição de pipeline de dados declarativa separada, talvez escrita em YAML, contém apenas a declaração e a sequência de etapas. Ela indica conjuntos de dados de entrada e saída, mas refere-se a scripts se e quando uma lógica mais complexa for necessária. Com o A La Mode, estamos vendo a primeira ferramenta de código aberto a aparecer nesse espaço.

    Histórico
  • DeepWalk é um algoritmo que ajuda a aplicar aprendizado de máquina em grafos. Ao trabalhar em conjuntos de dados representados como grafos, um dos principais problemas é extrair recursos deles. É aqui que o DeepWalk pode ajudar. Ele usa o SkipGram para construir incorporações de nós, visualizando o grafo como uma linguagem em que cada nó é uma palavra única e percursos aleatórios de comprimento finito no grafo constituem uma sentença. Essas incorporações podem ser usadas por vários modelos de ML. O DeepWalk é uma das técnicas que estamos testando em alguns de nossos projetos nos quais precisamos aplicar aprendizado de máquina em grafos.

    Histórico
  • Recomendamos cautela no gerenciamento de sistemas com estado usando plataformas de orquestração de contêineres como o Kubernetes. Alguns bancos de dados não são construídos com suporte nativo para orquestração — eles não esperam que um agendador os mate e realoque para outro host. Criar um serviço altamente disponível em cima de tais bancos de dados não é trivial e ainda recomendamos executá-los em hosts bare metal ou em uma máquina virtual (VM), em vez de forçar o ajuste em uma plataforma de orquestração de contêiner.

    Histórico
  • Embora defendamos fortemente a integração contínua em vez de Gitflow, sabemos que executar commits diretamente no trunk e integração contínua em uma master branch pode ser ineficaz se o time for muito grande, se as construções forem lentas ou instáveis ou se o time não tiver disciplina para executar o conjunto de testes completo localmente. Nessa situação, uma construção vermelha pode bloquear várias pessoas desenvolvedoras ou pares. Em vez de corrigir a causa raiz subjacente — construções lentas, a incapacidade de executar testes localmente ou arquiteturas monolíticas que exigem muitas pessoas trabalhando na mesma área — os times geralmente confiam em feature branches para contornar esses problemas. Nós desencorajamos os feature branches, pois eles podem exigir um esforço significativo para resolver conflitos de merge e introduzem ciclos de feedback mais longos e possíveis erros durante a resolução de conflitos. Em vez disso, propomos usar compilações preflight como alternativa: são compilações baseadas em pull request para "microbranches" que permanecem apenas pelo período de execução do pipeline, com o branch aberto para cada commit. Para ajudar a automatizar esse fluxo de trabalho, encontramos bots como Bors, que automatiza o merge para controlar e excluir branches caso a construção da minibranch tenha êxito. Estamos avaliando esse fluxo, e você também deve; mas não use isso para resolver o problema errado, pois pode levar ao uso indevido de branches e causar mais danos do que benefícios.

    Histórico

EVITE?

  • É bastante curioso que, após mais de uma década de experiência com migração para nuvem na indústria, ainda sentimos que é necessário chamar atenção para a prática de lift and shift para nuvem ; na qual a nuvem é vista simplesmente como uma solução de hospedagem, e a arquitetura existente, práticas de segurança e modelos operacionais de TI são simplesmente replicados na nuvem. Isso não cumpre as promessas de agilidade e inovação digital da nuvem. Uma migração para nuvem requer uma mudança intencional em vários eixos em direção a um estado nativo da nuvem. Dependendo das circunstâncias únicas da migração, cada organização pode acabar em algum lugar do espectro: desde lift and shift até estruturas nativas de nuvem. A arquitetura de sistemas, por exemplo, é um dos pilares da agilidade na entrega e geralmente requer mudanças. A tentação de simplesmente fazer lift and shift dos sistemas existentes como contêineres para a nuvem pode ser forte. Embora essa tática possa acelerar a migração para a nuvem, ela deixa a desejar na criação de agilidade e entrega de funcionalidades e valor. A segurança corporativa na nuvem é fundamentalmente diferente da segurança tradicional baseada em perímetro por meio de firewalls e zoneamento, e exige uma jornada em direção à arquitetura de confiança zero. O modelo operacional de TI também precisa ser reformulado para fornecer serviços de nuvem com segurança por meio de plataformas automatizadas de autoatendimento e para capacitar os times a assumirem mais responsabilidades operacionais e ganharem autonomia. Por último, mas não menos importante, as organizações devem criar uma base para permitir mudanças contínuas, como a criação de pipelines com testes contínuos de aplicações e infraestrutura como parte da migração. Isso ajudará o processo de migração, resultará em um sistema mais robusto e bem estruturado e dará às organizações uma maneira de continuar evoluindo e melhorando seus sistemas.

    Histórico
  • Estamos descobrindo que mais e mais empresas precisam substituir sistemas legados envelhecidos para acompanhar as demandas de clientes (tanto internas quanto externas). Um antipadrão que continuamos vendo é a paridade de funcionalidades na migração de legados , o desejo de manter a paridade de funcionalidades com os sistemas antigos. Vemos isso como uma grande oportunidade perdida. Frequentemente, os sistemas antigos incham com o tempo, com muitos recursos que não são usados pelos usuários (50%, segundo um relatório de 2014 do Standish Group) e processos de negócios que evoluíram com o passar do tempo. Nosso conselho: convença seus clientes a dar um passo atrás para entender o que os usuários precisam atualmente e priorizar essas necessidades de acordo com resultados de negócios e métricas — o que é muitas vezes mais fácil de falar do que de fazer. Isso significa conduzir uma pesquisa de usuário e aplicar práticas modernas de desenvolvimento de produto em vez de simplesmente substituir as práticas existentes.

    Histórico
  • Vários anos atrás, surgiu uma nova geração de plataformas de agregação de logs, capazes de armazenar e pesquisar vastas quantidades de dados de log para descobrir tendências e insights de dados operacionais. Splunk foi o mais proeminente, mas de maneira alguma o único exemplo dessas ferramentas. Como essas plataformas fornecem ampla visibilidade operacional e de segurança em todo o conjunto de aplicações, pessoas desenvolvedoras e administradoras se tornaram cada vez mais dependentes delas. Esse entusiasmo se espalhou à medida que stakeholders descobriram que podiam usar a agregação de logs para análise de negócio. No entanto, as necessidades de negócio podem superar rapidamente a flexibilidade e a usabilidade dessas ferramentas. Os logs destinados à observabilidade técnica geralmente são inadequados para inferir uma compreensão profunda de clientes. Preferimos usar ferramentas e métricas projetadas especificamente para análise de clientes ou adotar uma abordagem mais orientada a eventos para a observabilidade, na qual os eventos comerciais e operacionais são coletados e armazenados de forma que possam ser reproduzidos e processados por ferramentas mais específicas.

    Histórico
  • Há cinco anos, destacamos os problemas com branches de longa duração com Gitflow. Essencialmente, branches de longa duração são o oposto da integração contínua de todas as alterações no código-fonte e, em nossa experiência, a integração contínua é a melhor abordagem para a maioria dos tipos de desenvolvimento de software. Mais tarde, estendemos nossa cautela ao próprio Gitflow, porque vimos equipes usando-o quase exclusivamente com branches de longa duração. Hoje, ainda vemos times com configurações nas quais a entrega contínua de sistemas baseados na web é o objetivo declarado sendo atraídos para branches de longa duração. Por isso, ficamos felizes com o fato de o autor do Gitflow ter adicionado uma nota ao seu artigo original, explicando que o Gitflow não se destinava a esses casos de uso.

    Histórico
  • O valor do teste de captura instantânea é inegável ao se trabalhar com sistemas legados, garantindo que o sistema continue funcionando e o código legado não quebre. No entanto, estamos vendo a prática comum e bastante prejudicial de usar apenas testes de captura instantânea como mecanismo de teste principal. Os testes de captura instantânea validam o resultado exato gerado no DOM por um componente, e não o comportamento do componente; portanto, podem ser fracos e não confiáveis e promover a má prática de "apenas excluir a captura instantânea e regenerá-la". Em vez disso, você deve testar a lógica e o comportamento dos componentes emulando o que os usuários fariam. Essa mentalidade é incentivada pelas ferramentas da família Testing Library.

    Histórico
Não encontrou algo que você esperava achar?

Cada edição do radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode estar faltando um tópico específico porque o radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

Novo ou modificado,Sem modificação