Käesolevaga esitame teile kolmanda osa tõlgitud materjalist Dropboxi teekonnast, kui nad rakendasid enda Python-koodi tüübi kontrollimise süsteemi.
→ Eelnevad osad: ja
4 miljoni rea tüübiga koodi saavutamine
Veel üks oluline ülesanne (see oli teine populaarseim probleem, mis muretses sisekaalutlustes osalejaid) oli koodi mahu suurendamine Dropboxis, mis on kaetud tüübikontrollidega. Proovisime seda probleemi lahendamiseks mitmeid lähenemisviise — alates tüübiga koodibaasi loomulikust kasvust kuni mypy meeskonna liikmete statistilise ja dünaamilise automatiseeritud tüpifitseerimise jõupingutusteni. Lõpuks jäi mulje, et lihtsat ja võitjat strateegiat pole olemas, kuid suutsime saavutada kiire kasvu anoteeritud koodi mahus, kombineerides erinevaid lähenemisviise.
Kuna meie suurimas Python-repos, kus on tagakoodi, on märgitud koodiridu peaaegu 4 miljonit. Statistiline tüpiseerimise töö on kestnud umbes kolm aastat. Mypy toetab nüüd erinevaid tüübi kattearuande vorme, mis lihtsustavad tüpiseerimise edenemise jälgimist. Eriti saame koostada aruandeid tüüpide ebakindluste kohta, näiteks selgete tüüpide kasutamise puhul. Any anotatsioonides, mida ei saa kontrollida, või sellistes, nagu kolmandate osapoolte raamatukogude import, kus puuduvad tüpi anotatsioonid. Projekti raames, mille eesmärk on parandada tüüpide kontrollimise täpsust Dropboxis, oleme panustanud tüüpide määratlemise (nii-öelda stub-failide) parandamisse mõnede populaarsete avatud lähtekoodiga raamatukogude jaoks tsentraliseeritud Python-repos. .
Me oleme rakendanud (ja standardiseerinud järgnevates PEP-des) uusi tüübisüsteemi funktsioone, mis võimaldavad kasutada täpsemaid tüüpe mõnede spetsiifiliste Python-mustrite jaoks. Märkimisväärne näide sellest on TypeDict, mis pakub JSON-laadsetele sõnastikele tüüpide komplekti, millel on kindel rida stringi võtmeid, millest igaühel on oma tüüpi väärtus. Me jätkame tüüpide süsteemi laiendamist. Meie järgmine samm on tõenäoliselt Python'i numbrite töötlemise võimaluste toetuse parandamine.
Annoteritud koodi ridade arv: server
Annoteritud koodi ridade arv: klient
Annotatud koodi koguarv
Siin on ülevaade peamistest omadustest tegevustes, mida oleme teinud annotatud koodi mahu suurendamiseks Dropboxis:
Annotatsiooni rangeus. Oleme järk-järgult suurendanud uue koodi annotatsiooni rangeuse nõudeid. Alustasime lintersi soovitustega, mis soovitasid lisada annotatsioone failidesse, kus on juba mõned annotatsioonid olemas. Nüüd nõuame tüübi annotatsioonide olemasolu uutes Python-failides ja enamikus olemasolevates failides.
Tüübiaruanded. Saadame meeskondadele iganädalasi aruandeid nende koodi tüüpide tasemest ja anname soovitusi selle kohta, mida tasub esmalt annotatsiooni alla võtta.
mypy populariseerimine. Me räägime mypy’st erinevatel üritustel ja suhtleme meeskondadega, aidates neil alustada tüüpide annotatsioonide kasutamisega.
Küsimustikud. Korraldame perioodiliselt kasutajaküsimustikke, et tuvastada peamised probleemid. Oleme valmis nendest probleemidest päris kaugele minema (sealhulgas uue keele loomine mypy kiirendamiseks!).
Jõudlus. Oleme oluliselt parandanud mypy jõudlust tänu deemonile ja mypyc’ile. See on tehtud, et sujuvdada tüüpide annotatsiooni korral tekkivaid ebamugavusi ja võimaldada töötada suuremate koodimassidega.
Redaktoritega integreerimine. Oleme loonud tööriistu mypy käivitamiseks redaktoreides, mida Dropboxis laialdaselt kasutatakse. Nende hulka kuuluvad PyCharm, Vim ja VS Code. See on oluliselt lihtsustanud koodide annotatsioonide tegemise ja nende tõhususe kontrollimise protsessi. Sellised tegevused on tavaliselt iseloomulikud olemasoleva koodi annotatsioonile.
Statistiline analüüs. Oleme loonud tööriista funktsioonide signatuuride genereerimiseks, kasutades staatilise analüüsi vahendeid. See tööriist toimib ainult suhteliselt lihtsates olukordades, kuid aitas meil vaevata suurendada koodi katvust tüüpidega.
Kolmandate osapoolte teekide tugi. Paljudes meie projektides kasutatakse SQLAlchemy tööriistakomplekti. See rakendab Python'i dünaamilisi võimalusi, mida PEP 484 tüübid ei suuda otse modelleerida. PEP 561 kohaselt lõime vastava stub-faili ja kirjutasime mypy jaoks plugina (), mis parandab SQLAlchemy tuge.
Kohtume raskustega
Tee 4 miljoni tüübitud koodirida juurde ei olnud alati lihtne. Sellel teel kohtasime palju takistusi ja tegime mõned vead. Siin on mõned probleemid, millega silmitsi seisisime. Loodame, et nende jagamine aitab teisi sarnaste probleemide vältimisel.
Puuduvad failid. Alustasime tööga vaid väikese arvu failide kontrollimisega. Kõik, mis ei kuulunud nende failide hulka, ei olnud kontrollitud. Failid lisati kontrollimise nimekirja siis, kui nendes ilmusid esimesed annotatsioonid. Kui midagi imporditi modulist, mis asub väljaspool kontrollimise ala, siis oli jutt väärtuste tüübist. Any, mis ei olnud üldse kontrollitud. See tõi kaasa märkimisväärse tüübistamise täpsuse languse, eriti migreerimise varajastes etappides. Selline lähenemine toimis endiselt üllatavalt hästi, kuigi tüüpiline oli olukord, kus failide lisamine kontrollitud ala paljastas probleeme koodi muudes osades. Kõige halvemal juhul, kui kaks isoleeritud koodiala ühendati, kus mõlemad olid juba iseseisvalt kontrollitud, selgus, et nende tüüpide vahel on ühilduvuse probleeme. See viis vajaduseni teha esitustes mitmeid muudatusi. Nüüd, tagasi vaadates, mõistame, et oleksime pidanud võimalikult varakult lisama mypy tüübikontrolli alla põhiraamatukogu moodulid. See oleks teinud meie töö palju ennustatavamaks.
Vana koodi annotatsioon. Kui alustasime tööd, oli meil umbes 4 miljonit rida juba olemasolevat Python-koodi. Oli selge, et kogu selle koodi annotatsioon on keeruline ülesanne. Me lõime tööriista nimega PyAnnotate, mis suudab koguda tüübiteavet testide käigus ning oskab koodile lisada tüübianotatsioone põhinedes kogutud teabele. Siiski ei märganud me seda tööriista laialdast kasutuselevõttu. Tüübiteabe kogumine oli aeglane, automaatselt genereeritud annotatsioonid nõudsid sageli palju käsitsi parandusi. Mõtlesime tööriista automaatse käivitamise peale iga koodikontrolli ajal või tüübiteabe kogumise peale, põhinedes mõne väikese hulga reaalseid veebipäringuid analüüsides, kuid otsustasime seda mitte teha, kuna ükski neist lähenemistest oli liiga riskantne.
Kokkuvõttes võib öelda, et enamik kodeerimist on käsitsi annotatsiooni teinud selle omanikud. Me valmistame eriti oluliste moodulite ja funktsioonide kohta aruandeid, et suunata see protsess õigesse suunda. Näiteks on oluline varustada tüübid annotatsioonidega raamatukogu moodulit, mida kasutatakse sadades kohtades. Kuid vana teenuse annotatsioon ei ole enam nii oluline, kui see asendatakse uuega. Lisaks katsetame me staatilise analüüsi kasutamist tüübi annotatsioonide genereerimiseks vana koodi jaoks.
Tsüklilised impordid. Ülal rääkisin tsüklilistest imporditest ("sõltuvuste pundardest"), mille olemasolu raskendas mypy kiirus. Me pidime tõsiselt vaeva nägema, et varustada mypy kõigi nende tsükliliste impordite tõttu tekkinud idiomade toetusega. Just hiljuti lõpetasime suure projekti, mille käigus uuendasime süsteemi ja lahendasime suurema osa mypyga seotud tsükliliste impordite probleemidest. Need probleemid ulatusid tegelikult projekti varajastest päevadest, isegi Alore'ist, kergest programmeerimiskeelest, millele mypy algselt suunatud oli. Alore süntaks võimaldab tsükliliste importide probleemide lahendamist hõlpsasti. Kaasaegne mypy on pärinud mõned piirangud oma varaselt primitiivsest teostusest (mis oli suurepäraselt sobiv Alore jaoks). Python muudab tsükliliste importidega töötamise keeruliseks peamiselt väljendite mitmetähenduslikkuse tõttu. Näiteks võib väärtuse määramise käigus tegelikult määrata tüüpide aliasi. Mypy ei pruugi selliseid asju alati tuvastada, enne kui suur osa imporditsüklist on töödeldud. Alore'isse ei olnud selliseid mitmetähenduslikkusi. Varases arendusetapis tehtud ebaõnnestunud lahendused võivad programmerijale tuua ebameeldivaid üllatusi aastaid hiljem.
Kokkuvõte: tee 5 miljoni koodireani ja uute horisoniteni
Projekt mypy on läbinud pika tee – alates varajastest prototüüpidest kuni süsteemini, millega hallatakse 4 miljoni koodirea tootmistüüpide kontrollimist. MyPy arendamise käigus viidi läbi Pythonis tüüpide soovituste standardimine. Tänapäeval on loodud võimas ökosüsteem, mis ümbritseb Python-koodi tüüpimist. Selles on ruumi teegide toetamiseks, seal on IDE-de ja redaktorite abivahendid, samuti mitmeid tüüpide kontrollimise süsteeme, millest igal on oma plussid ja miinused.
Kuid kuigi tüüpide kontrollimist peetakse Dropboxis juba iseenesestmõistetavaks, olen ma kindel, et me elame endiselt Python-koodi tüpiseerimise alguses. Arvan, et tüüpide kontrollimise tehnoloogiad jätkavad arendamist ja täiustamist.
Kui te ei ole veel tüübi kontrolli oma suurtes Python-projektides kasutanud, siis teadke, et praegu on suurepärane aeg alustada üleminekut staatilisele tüübistamisele. Olen rääkinud nendega, kes on sellise ülemineku teinud. Keegi neist ei kahetse seda. Tüübikontroll muudab Pythoni keeleks, mis sobib palju paremini suuremate projektide arendamiseks kui 'tavaline Python'.
Lugupidamisega lugejad! Kas kasutate oma Python-projektides tüübikontrolli?
Allikas: habr.com
