Risolto 2: Meta è il prossimo

Oct 16, 2023

Python è uno dei linguaggi più popolari in uso su Meta. Gli ingegneri di produzione (PE) di Meta sono ingegneri software specializzati (SWE) che si concentrano su affidabilità, efficienza e scalabilità. Lavorano su vari progetti, tra cui il debug di servizi di produzione, la riscrittura di librerie inefficienti, l'orchestrazione di distribuzioni di progetti su larga scala o la pianificazione e pianificazione della capacità. E Python è spesso uno dei primi strumenti a cui i PE si rivolgono, poiché offre uno sviluppo rapido, una sintassi di facile lettura e una vasta gamma di librerie open source.

Il team Python Language Foundation di Meta, un team ibrido di PE e SWE tradizionali, aiuta a possedere e mantenere l'infrastruttura e gli strumenti per Python in Meta. Il team supporta ingegneri, data scientist, ricercatori e chiunque altro in Meta utilizzi Python per svolgere il proprio lavoro.

Uno dei modi in cui raggiungiamo questo obiettivo è creare strumenti che consentano agli sviluppatori Python di scrivere codice migliore e più affidabile in modo più efficiente. Ciò include strumenti come la formattazione automatica e l'ordinamento delle importazioni che eliminano la noia o linter che guidano gli ingegneri verso un codice gestibile con meno bug.

Quest'anno abbiamo creato un nuovo linter, Fixit 2, progettato da zero per rendere gli sviluppatori più efficienti e capaci, sia nei progetti open source che nel panorama diversificato del nostro monorepo interno. In Meta, stiamo utilizzando Fixit 2 con alcuni early adopter e prevediamo di distribuirlo presto al resto del nostro monorepo. Ma qualsiasi sviluppatore può utilizzarlo per eseguire la correzione automatica in modo più efficiente e apportare miglioramenti più rapidi alle proprie basi di codice.

Nell’ecosistema Python sono presenti numerosi linter eccellenti, molti dei quali dispongono di un’ampia comunità di plugin di terze parti che forniscono una vasta gamma di regole lint. Utilizziamo Flake8 internamente a Meta dal 2016 e ha avuto molto successo nell'aiutare gli sviluppatori a ridurre i bug e mantenere una base di codice pulita. Il popolare plugin flake8-bugbear è stato creato addirittura da Łukasz Langa (autore di Black, sviluppatore residente di PSF e gestore del rilascio per Python 3.8 e 3.9) mentre lavorava su Meta (allora Facebook), come casa per regole di lanugine più supponenti che potremmo utilizzare internamente e condividere con il resto della comunità di sviluppatori Python.

Disponiamo inoltre di un gran numero di plugin interni realizzati da vari team e Flake8 consente loro di scrivere e abilitare regole di lint personalizzate direttamente nella codebase senza ottenere l'approvazione da un gatekeeper centrale e senza attendere l'avvio di una nuova distribuzione di Flake8. fuori.

Ma sebbene Flake8 sia da tempo una pietra miliare della nostra soluzione di lanugine, presenta anche alcuni aspetti irregolari. La scrittura di nuove regole lint richiede la creazione di interi plug-in (ciascuno dei quali richiede una parte dello "spazio dei nomi" per i codici di errore) e incoraggia gli sviluppatori a creare plug-in complicati che coprono più classi di errori. Quando vengono rilevati questi errori di lanugine, Flake8 può solo puntare a un numero di riga e di colonna in cui si è verificato, ma non ha modo di suggerire modifiche allo sviluppatore che esamina un elenco di risultati di lanugine, lasciandolo in uno stato di tentativi ed errori per trovare cambiamenti che rendono felice il linter. Inoltre, Flake8 utilizza il modulo stdlib ast, rendendolo incapace di analizzare le future funzionalità di sintassi e costringendo gli sviluppatori ad attendere l'aggiornamento degli strumenti prima di poter utilizzare la nuova brillante novità.

Naturalmente esistono alternative a Flake8, ma molte di esse presentano uno o più inconvenienti:

Sebbene alcune di queste funzionalità non siano fondamentali, la più importante per l'efficienza dello sviluppatore è l'offerta di correzioni automatiche: modifiche automatiche suggerite che soddisfino la regola della lanugine. Ciò elimina le congetture dall'utilizzo di un linter e consente agli utenti di rivedere e accettare rapidamente tali modifiche quando possibile, eliminando la necessità di rieseguire il linter fino a quando il codice non sarà finalmente pulito. Combinando queste correzioni automatiche con le regole di lanugine personalizzate nel repository, fornisce un livello di miglioramenti personalizzati della qualità del codice difficile da battere.

Sfortunatamente, anche Fixit, il linter con correzione automatica che abbiamo creato per Instagram e open source, non supportava le regole lint locali o la configurazione gerarchica, requisiti fondamentali per il nostro monorepo che ospita migliaia di progetti, molti dei quali sono essi stessi progetti open source. con le proprie esigenze distinte di linting e CI. Abbiamo ricevuto molte richieste dagli sviluppatori per supportare Fixit nel nostro monorepo, ma c'erano abbastanza ostacoli da consentirci di supportare solo un piccolo set di regole di sicurezza, riducendo i vantaggi diretti per la nostra base di codice Python.