Fixo 2: próximo do Meta

Oct 16, 2023

Python é uma das linguagens mais populares em uso na Meta. Os engenheiros de produção (PEs) da Meta são engenheiros de software especializados (SWEs) que se concentram em confiabilidade, eficiência e escalabilidade. Eles trabalham em vários projetos, incluindo depuração de serviços de produção, reescrita de bibliotecas ineficientes, orquestração de implantações de projetos em escala ou planejamento e programação de capacidade. E Python é frequentemente uma das primeiras ferramentas que os PEs procuram, pois oferece desenvolvimento rápido, sintaxe fácil de ler e uma enorme variedade de bibliotecas de código aberto.

A equipe Python Language Foundation da Meta — uma equipe híbrida de PEs e SWEs tradicionais — ajuda a possuir e manter a infraestrutura e as ferramentas para Python na Meta. A equipe apoia engenheiros, cientistas de dados, pesquisadores e qualquer outra pessoa na Meta que use Python para realizar seu trabalho.

Uma das maneiras de conseguir isso é construir ferramentas que permitam aos desenvolvedores Python escrever códigos melhores e mais confiáveis ​​com mais eficiência. Isso inclui ferramentas como formatação automática e classificação de importação que eliminam o tédio, ou linters que orientam os engenheiros em direção a um código sustentável com menos bugs.

Este ano, estamos construindo um novo linter, Fixit 2, projetado desde o início para tornar os desenvolvedores mais eficientes e capazes, tanto em projetos de código aberto quanto no cenário diversificado de nosso monorepo interno. Na Meta, estamos usando o Fixit 2 com alguns primeiros usuários e planejamos lançá-lo para o restante do nosso monorepo em breve. Mas qualquer desenvolvedor pode usá-lo para realizar a correção automática com mais eficiência e fazer melhorias mais rápidas em suas próprias bases de código.

Há uma variedade de linters excelentes no ecossistema Python, muitos dos quais possuem uma grande comunidade de plug-ins de terceiros que fornecem uma gama diversificada de regras de lint. Usamos Flake8 internamente na Meta desde 2016 e ele tem tido muito sucesso em ajudar os desenvolvedores a reduzir bugs e manter uma base de código limpa. O popular plugin flake8-bugbear foi criado por Łukasz Langa (autor de Black, desenvolvedor residente do PSF e gerente de lançamento para Python 3.8 e 3.9) enquanto trabalhava no Meta (então Facebook), como um lar para regras de lint mais opinativas que poderíamos usar internamente e compartilhar com o resto da comunidade de desenvolvedores Python.

Também temos um grande número de plug-ins internos criados por várias equipes, e o Flake8 permite que eles escrevam e habilitem regras de lint personalizadas diretamente na base de código, sem obter a aprovação de um gatekeeper central e sem esperar que uma nova implantação do Flake8 aconteça. fora.

Mas embora o Flake8 seja há muito tempo a base da nossa solução de fiapos, ele também apresenta algumas arestas. Escrever novas regras de lint requer a construção de plugins inteiros (cada um reivindicando uma parte do “namespace” para códigos de erro) e incentiva os desenvolvedores a construir plugins complicados que cobrem múltiplas classes de erros. Quando esses erros de lint são encontrados, Flake8 só pode apontar para um número de linha e coluna onde ocorreu, mas não tem como sugerir alterações ao desenvolvedor que olha uma lista de resultados de lint, deixando-os em um estado de tentativa e erro para encontrar mudanças que deixam o linter feliz. Além disso, Flake8 usa o módulo stdlib ast, tornando-o incapaz de analisar recursos de sintaxe futuros e forçando os desenvolvedores a esperar pela atualização das ferramentas antes de poderem usar o novo recurso brilhante.

Existem alternativas ao Flake8, é claro, mas muitas delas sofrem de uma ou mais desvantagens:

Embora alguns desses recursos não sejam críticos, o mais importante para a eficiência do desenvolvedor é oferecer correções automáticas – alterações sugeridas automaticamente que satisfariam a regra do lint. Isso elimina as suposições ao usar um linter e permite que os usuários revisem e aceitem rapidamente essas alterações quando possível, eliminando a necessidade de executar novamente o linter até que o código esteja finalmente limpo. A combinação dessas correções automáticas com regras de lint personalizadas no repositório fornece um nível de melhorias de qualidade de código personalizadas que é difícil de superar.

Infelizmente, mesmo o Fixit, o linter de correção automática que construímos para o Instagram e de código aberto, não suportava regras locais de lint ou configuração hierárquica – requisitos básicos para nosso monorepo que abriga milhares de projetos, muitos dos quais são eles próprios projetos de código aberto com suas próprias necessidades distintas de linting e CI. Recebemos muitas solicitações de desenvolvedores para oferecer suporte ao Fixit em nosso monorepo, mas havia obstáculos suficientes para que pudéssemos oferecer suporte apenas a um pequeno conjunto de regras de lint de segurança, reduzindo os benefícios diretos para nossa base de código Python.