Jūsų dėmesiui pristatome trečiąją medžiagos vertimo dalį apie kelią, kuriuo Dropbox nuėjo diegiant Python kodo tipo tikrinimo sistemą.
→ Ankstesnės dalys: и
Pasiekti 4 milijonus įvesto kodo eilučių
Kitas didelis iššūkis (ir antras labiausiai paplitęs susirūpinimas tarp apklaustųjų viduje) buvo padidinti kodo, kuriam taikoma tipo patikra „Dropbox“, kiekį. Išbandėme kelis šios problemos sprendimo būdus – nuo natūralaus įvestos kodų bazės dydžio padidinimo iki „mypy“ komandos pastangų sutelkimo ties statinio ir dinaminio automatizuoto tipo išvadomis. Galų gale atrodė, kad nėra paprastos laimėjimo strategijos, tačiau mes sugebėjome greitai padidinti anotuoto kodo apimtį, derindami daugybę metodų.
Todėl mūsų didžiausioje Python saugykloje (su foniniu kodu) yra beveik 4 milijonai anotuoto kodo eilučių. Statinio kodo rinkimo darbai buvo baigti maždaug per trejus metus. Dabar „Mypy“ palaiko įvairių tipų kodo aprėpties ataskaitas, kurios leidžia lengviau stebėti spausdinimo eigą. Visų pirma galime generuoti ataskaitas apie kodą, kurio tipai yra dviprasmiški, pvz., aiškus tipo naudojimas Any komentaruose, kurių negalima patikrinti, arba su tokiais dalykais kaip trečiųjų šalių bibliotekų, kuriose nėra tipo komentarų, importavimas. Vykdydami projektą, skirtą „Dropbox“ tipo tikrinimo tikslumui pagerinti, prisidėjome prie kai kurių populiarių atvirojo kodo bibliotekų tipų apibrėžimų (vadinamųjų „stub“ failų) tobulinimo centralizuotoje „Python“ saugykloje. .
Įdiegėme (ir standartizavome vėlesniuose PEP) naujas tipo sistemos funkcijas, leidžiančias tikslesnius kai kurių konkrečių Python modelių tipus. Ryškus to pavyzdys yra TypeDict, kuriame pateikiami į JSON panašūs žodynai, turintys fiksuotą eilučių raktų rinkinį, kurių kiekvienas turi savo tipo reikšmę. Ir toliau plėsime tipų sistemą. Kitas mūsų žingsnis greičiausiai bus pagerinti Python skaitmeninių galimybių palaikymą.
Anotuoto kodo eilučių skaičius: serveris
Anotuoto kodo eilučių skaičius: klientas
Bendras anotuoto kodo eilučių skaičius
Štai pagrindinių dalykų, kuriuos atlikome norėdami padidinti komentuojamo kodo kiekį „Dropbox“, ypatybių apžvalga:
Anotacijos griežtumas. Palaipsniui padidinome naujo kodo anotavimo griežtumo reikalavimus. Pradėjome nuo „Linter“ patarimų, kurie pasiūlė pridėti komentarų prie failų, kuriuose jau buvo keletas komentarų. Dabar naujuose Python failuose ir daugumoje esamų failų reikalaujame tipo komentarų.
Rašyti ataskaitas. Komandoms kas savaitę siunčiame ataskaitas apie kodo įvedimo lygį ir patariame, ką pirmiausia reikėtų pažymėti.
Mypy populiarinimas. Renginiuose kalbame apie mypy ir kalbamės su komandomis, kad padėtume joms pradėti rašyti tipo komentarus.
Apklausos. Periodiškai atliekame vartotojų apklausas, kad nustatytų pagrindines problemas. Esame pasirengę nueiti gana toli spręsdami šias problemas (net kurdami naują kalbą, kad paspartintume mypy!).
Spektaklis. Naudodami demoną ir mypyc labai pagerinome mypy našumą. Tai buvo padaryta siekiant išlyginti nepatogumus, kylančius anotavimo procese, ir tam, kad būtų galima dirbti su dideliais kodo kiekiais.
Integracija su redaktoriais. Sukūrėme įrankius, skirtus palaikyti „mypy“ paleidimą „Dropbox“ populiariuose redaktoriuose. Tai apima PyCharm, Vim ir VS kodą. Tai labai supaprastino kodo anotavimo ir jo funkcionalumo tikrinimo procesą. Tokio tipo veiksmai yra įprasti komentuojant esamą kodą.
Statinė analizė. Sukūrėme įrankį funkcijų parašams nustatyti naudojant statinės analizės įrankius. Šis įrankis gali veikti tik gana paprastose situacijose, bet padėjo mums be didelių pastangų padidinti kodo tipo aprėptį.
Trečiųjų šalių bibliotekų palaikymas. Daugelis mūsų projektų naudoja SQLAlchemy įrankių rinkinį. Jis naudojasi Python dinaminėmis galimybėmis, kurių PEP 484 tipai negali tiesiogiai modeliuoti. Mes, vadovaudamiesi PEP 561, sukūrėme atitinkamą stub failą ir parašėme įskiepį mypy (), kuris pagerina SQLAlchemy palaikymą.
Sunkumai, su kuriais susidūrėme
Kelias iki 4 milijonų įvesto kodo eilučių mums ne visada buvo lengvas. Šiame kelyje susidūrėme su daugybe duobių ir padarėme keletą klaidų. Tai yra keletas problemų, su kuriomis susidūrėme. Tikimės, kad pasakojimas apie juos padės kitiems išvengti panašių problemų.
Trūksta failų. Savo darbą pradėjome patikrinę tik nedidelį kiekį failų. Viskas, kas neįtraukta į šiuos failus, nebuvo patikrinta. Failai buvo įtraukti į nuskaitymo sąrašą, kai juose pasirodė pirmieji komentarai. Jei kažkas buvo importuota iš modulio, esančio už patikrinimo ribų, tada mes kalbėjome apie darbą su tokiomis vertėmis kaip Any, kurie iš viso nebuvo išbandyti. Dėl to smarkiai sumažėjo spausdinimo tikslumas, ypač ankstyvosiose migracijos stadijose. Šis metodas iki šiol veikė stebėtinai gerai, nors įprasta situacija yra ta, kad įtraukus failus į peržiūros sritį, atsiranda problemų kitose kodų bazės dalyse. Blogiausiu atveju, sujungus dvi izoliuotas kodo sritis, kuriose, nepriklausomai viena nuo kitos, tipai jau buvo patikrinti, paaiškėjo, kad šių sričių tipai tarpusavyje nesuderinami. Dėl to reikėjo atlikti daug anotacijų pakeitimų. Žvelgdami atgal, suprantame, kad turėjome anksčiau įtraukti pagrindinius bibliotekos modulius į „mypy“ tipo tikrinimo sritį. Taip mūsų darbas būtų daug labiau nuspėjamas.
Seno kodo anotacija. Kai pradėjome, turėjome apie 4 milijonus esamo Python kodo eilučių. Buvo aišku, kad komentuoti visą šį kodą nebuvo lengva užduotis. Sukūrėme įrankį, pavadintą PyAnnotate, kuris gali rinkti informaciją apie tipą atliekant bandymus ir gali pridėti tipo komentarus prie jūsų kodo pagal surinktą informaciją. Tačiau nepastebėjome, kad šis įrankis būtų ypač plačiai naudojamas. Tipo informacijos rinkimas buvo lėtas, o automatiškai generuojamus komentarus dažnai reikėdavo daug redaguoti rankiniu būdu. Galvojome apie šio įrankio paleidimą automatiškai kiekvieną kartą, kai peržiūrime kodą, arba rinkome informaciją apie tipą, pagrįstą kai kurių faktinių tinklo užklausų analize, bet nusprendėme to nedaryti, nes bet kuris metodas buvo pernelyg rizikingas.
Dėl to galima pastebėti, kad didžiąją kodo dalį jo savininkai komentavo rankiniu būdu. Siekdami nukreipti šį procesą tinkama linkme, rengiame ataskaitas apie ypač svarbius modulius ir funkcijas, kurias būtina anotuoti. Pavyzdžiui, svarbu pateikti bibliotekos modulio, kuris naudojamas šimtuose vietų, tipo anotacijas. Tačiau seną paslaugą, kuri pakeičiama nauja, nebėra taip svarbu komentuoti. Taip pat eksperimentuojame naudodami statinę analizę, kad sukurtume senojo kodo tipo komentarus.
Ciklinis importas. Aukščiau kalbėjau apie ciklinį importą ("priklausomybės raizgynes"), dėl kurių buvo sunku pagreitinti mypy. Taip pat turėjome sunkiai dirbti, kad „mypy“ palaikytų visas idiomas, kurias sukelia šis cikliškas importas. Neseniai užbaigėme didelį sistemos perkūrimo projektą, kuris išsprendė daugumą „mypy“ problemų, susijusių su cirkuliaciniu importu. Šios problemos iš tikrųjų kilo nuo pačių ankstyvųjų projekto dienų, dar iš Alore – mokomosios kalbos, į kurią iš pradžių buvo skirtas mypy projektas. Alore sintaksė leidžia lengvai išspręsti ciklinio importavimo komandų problemas. Šiuolaikinė mypy paveldėjo tam tikrus apribojimus iš ankstyvo, nesudėtingo įgyvendinimo (kuris puikiai tiko Alore). „Python“ apsunkina darbą su cirkuliaciniu importu, daugiausia dėl to, kad išraiškos yra dviprasmiškos. Pavyzdžiui, priskyrimo operacija iš tikrųjų gali apibrėžti tipo slapyvardį. „Mypy“ ne visada gali aptikti tokius dalykus, kol neapdorota didžioji importo ciklo dalis. Alore tokių neaiškumų nebuvo. Netinkami sprendimai, priimti ankstyvose sistemos kūrimo stadijose, po daugelio metų programuotojui gali tapti nemalonia staigmena.
Rezultatai: kelias į 5 milijonus kodo eilučių ir nauji horizontai
„Mypy“ projektas nuėjo ilgą kelią – nuo ankstyvųjų prototipų iki sistemos, valdančios 4 milijonus gamybos kodų tipų eilučių. Vystantis mypy, Python tipo užuominos buvo standartizuotos. Šiomis dienomis įvedant Python kodą sukurta galinga ekosistema. Jame yra bibliotekos palaikymo vieta, yra pagalbiniai IDE ir redaktorių įrankiai, yra kelių tipų valdymo sistemos, kurių kiekviena turi savo privalumų ir trūkumų.
Nors „Dropbox“ tipo tikrinimas jau nustatytas, manau, kad mes vis dar tik pradedame vesti Python kodą. Manau, kad tipo tikrinimo technologijos toliau vystysis ir tobulės.
Jei dar nenaudojote tipo tikrinimo savo didelio masto Python projekte, žinokite, kad dabar labai tinkamas metas pereiti prie statinio spausdinimo. Kalbėjausi su tais, kurie padarė panašų perėjimą. Nė vienas jų nesigailėjo. Tipo tikrinimas daro Python kalbą, kuri daug geriau tinka dideliems projektams nei „įprastas Python“.
Mieli skaitytojai! Ar savo Python projektuose naudojate tipo tikrinimą?
Šaltinis: www.habr.com