Tutvustame teie tähelepanu kolmanda osa materjali tõlke kohta Dropboxi tee kohta Pythoni koodi tüübikontrollisüsteemi juurutamisel.
→ Eelmised osad: и
Jõuab 4 miljonile trükitud koodireale
Teine suur väljakutse (ja teine kõige levinum mure siseselt küsitletute seas) oli Dropboxis tüübikontrolliga hõlmatud koodide hulga suurendamine. Oleme proovinud selle probleemi lahendamiseks mitmeid lähenemisviise, alustades trükitud koodibaasi suuruse loomulikust suurendamisest kuni mypy meeskonna jõupingutuste keskendumiseni staatilisele ja dünaamilisele automatiseeritud tüübijäreldamisele. Lõppkokkuvõttes tundus, et lihtsat võidustrateegiat polegi, kuid paljusid lähenemisviise kombineerides suutsime saavutada annoteeritud koodi mahu kiire kasvu.
Selle tulemusena on meie suurimas Pythoni hoidlas (taustakoodiga) ligi 4 miljonit rida kommenteeritud koodi. Staatilise koodi tippimisega seotud töö lõppes ligikaudu kolme aastaga. Mypy toetab nüüd erinevat tüüpi koodi katvuse aruandeid, mis muudavad tippimise edenemise jälgimise lihtsamaks. Eelkõige saame koostada aruandeid koodi kohta, mille tüübid on mitmetähenduslikud, nagu näiteks tüübi selgesõnaline kasutamine Any märkustes, mida ei saa kontrollida, või selliste asjadega nagu kolmandate osapoolte teekide importimine, millel pole tüübimärkusi. Dropboxi tüübikontrolli täpsuse parandamise projekti osana aitasime kaasa mõne populaarse avatud lähtekoodiga teegi tüübimääratluste (nn tünnifailide) täiustamisele tsentraliseeritud Pythoni hoidlas. .
Rakendasime (ja standardiseerisime järgmistes PEP-des) tüübisüsteemi uued funktsioonid, mis võimaldavad mõne konkreetse Pythoni mustri jaoks täpsemaid tüüpe. Märkimisväärne näide sellest on TypeDict, mis pakub tüüpe JSON-sarnaste sõnaraamatute jaoks, millel on fikseeritud stringivõtmete komplekt, millest igaühel on oma tüüpi väärtus. Jätkame tüübisüsteemi laiendamist. Meie järgmine samm on tõenäoliselt Pythoni numbriliste võimaluste toe parandamine.
Annoteeritud koodi ridade arv: server
Annoteeritud koodi ridade arv: klient
Annoteeritud koodi ridade koguarv
Siin on ülevaade põhifunktsioonidest, mida tegime Dropboxis annoteeritud koodi hulga suurendamiseks:
Annotatsiooni rangus. Suurendasime järk-järgult nõudeid uue koodi märkuste tegemisele. Alustasime linteri näpunäidetega, mis soovitasid lisada märkusi failidele, millel on juba mõned märkused. Nüüd nõuame uutes Pythoni failides ja enamikes olemasolevates failides tüübimärkusi.
Aruannete tippimine. Saadame meeskondadele iganädalased aruanded nende koodi sisestamise taseme kohta ja anname nõu, mida tuleks esimesena märkida.
Mypy populariseerimine. Räägime üritustel müpyst ja räägime meeskondadega, et aidata neil tüübimärkimistega alustada.
Küsitlused. Suuremate probleemide tuvastamiseks viime läbi perioodilisi kasutajauuringuid. Oleme nende probleemide lahendamisel valmis minema üsna kaugele (isegi uue keele loomisega, et müpy kiirendada!).
Esitus. Oleme deemoni ja mypyci abil oluliselt parandanud mypy jõudlust. Seda tehti annotatsiooniprotsessi käigus tekkivate ebamugavuste tasandamiseks ja suure koodihulgaga töötamiseks.
Integreerimine toimetajatega. Oleme loonud tööriistad, mis toetavad mypy käitamist Dropboxis populaarsetes redaktorites. See hõlmab PyCharmi, Vimi ja VS-koodi. See lihtsustas oluliselt koodi märkimise ja selle funktsionaalsuse kontrollimise protsessi. Seda tüüpi toimingud on olemasoleva koodi märkuste tegemisel tavalised.
Staatiline analüüs. Lõime tööriista funktsioonide allkirjade järeldamiseks staatilise analüüsi tööriistade abil. See tööriist töötab ainult suhteliselt lihtsates olukordades, kuid see aitas meil kooditüübi leviala ilma suurema vaevata suurendada.
Kolmandate osapoolte raamatukogude tugi. Paljud meie projektid kasutavad SQLAlchemy tööriistakomplekti. See kasutab ära Pythoni dünaamilisi võimalusi, mida PEP 484 tüübid ei suuda otse modelleerida. Kooskõlas PEP 561-ga lõime vastava tünnifaili ja kirjutasime pistikprogrammi mypy (), mis parandab SQLAlchemy tuge.
Raskused, millega me kokku puutusime
Teekond 4 miljoni rea trükitud koodini pole meie jaoks alati lihtne olnud. Sellel teel sattusime palju auke ja tegime mitmeid vigu. Need on mõned probleemid, millega me kokku puutusime. Loodame, et nendest rääkimine aitab teistel sarnaseid probleeme vältida.
Puuduvad failid. Alustasime oma tööd vaid väikese hulga failide kontrollimisega. Midagi, mida nendes failides ei olnud, ei kontrollitud. Failid lisati skannimisloendisse, kui neisse ilmusid esimesed märkused. Kui midagi imporditi moodulist, mis asub väljaspool kontrolli ulatust, siis me rääkisime selliste väärtustega töötamisest nagu Any, mida üldse ei testitud. See tõi kaasa trükkimise täpsuse olulise vähenemise, eriti migratsiooni algfaasis. See lähenemine on siiani üllatavalt hästi toiminud, kuigi tüüpiline olukord on see, et failide lisamisel ülevaatuse ulatusse ilmnevad probleemid koodibaasi muudes osades. Halvimal juhul, kui liideti kaks isoleeritud koodiala, milles üksteisest sõltumatult juba tüüpe kontrolliti, selgus, et nende alade tüübid ei ühildu omavahel. See tõi kaasa vajaduse teha märkustes palju muudatusi. Nüüd tagasi vaadates mõistame, et oleksime pidanud varem lisama mypy tüübikontrolli alale põhiteegi moodulid. See muudaks meie töö palju etteaimatavamaks.
Vana koodi märkimine. Kui alustasime, oli meil olemasolevat Pythoni koodi umbes 4 miljonit rida. Oli selge, et kogu selle koodi märkuste tegemine ei olnud lihtne ülesanne. Oleme loonud tööriista nimega PyAnnotate, mis kogub testide käigus tüübiteavet ja saab kogutud teabe põhjal lisada teie koodile tüübimärkusi. Siiski ei ole me täheldanud selle tööriista eriti laialdast kasutuselevõttu. Tüübi teabe kogumine oli aeglane ja automaatselt loodud märkused nõudsid sageli palju käsitsi muudatusi. Mõtlesime selle tööriista automaatsele käitamisele iga kord, kui koodi üle vaatame, või tüübiteabe kogumisele, mis põhineb mõne väikese tegelike võrgupäringute analüüsimisel, kuid otsustasime seda mitte teha, kuna kumbki lähenemisviis oli liiga riskantne.
Selle tulemusena võib märkida, et selle omanikud tegid suurema osa koodist käsitsi. Selle protsessi õiges suunas suunamiseks koostame aruandeid eriti oluliste moodulite ja funktsioonide kohta, mis vajavad märkusi. Näiteks on oluline anda tüübimärkused teegi moodulile, mida kasutatakse sadades kohtades. Kuid vana teenus, mis asendatakse uuega, pole enam nii oluline, et kommenteerida. Samuti katsetame staatilise analüüsi kasutamist pärandkoodi tüübimärkuste genereerimiseks.
Tsükliline import. Eespool rääkisin tsüklilisest impordist (“sõltuvussõltuvustest”), mille olemasolu muutis müpy kiirendamise keeruliseks. Samuti pidime kõvasti tööd tegema, et panna mypy toetama igasuguseid idioome, mis on põhjustatud sellest tsüklilisest impordist. Lõpetasime hiljuti suure süsteemi ümberkujundamise projekti, mis lahendas enamiku ringimpordiga seotud Mypy probleemidest. Need probleemid tulenesid tegelikult projekti algusest, Alore'ist, mis oli hariduskeel, millele mypy projekt algselt keskendus. Alore süntaks muudab tsükliliste impordikäskude probleemide lahendamise lihtsaks. Kaasaegne mypy on pärinud mõned piirangud oma varasest ja keerukast rakendamisest (mis sobis Alore jaoks suurepäraselt). Python muudab ringikujulise impordiga töötamise keeruliseks peamiselt seetõttu, et väljendid on mitmetähenduslikud. Näiteks võib määramisoperatsioon tegelikult määratleda tüübialiase. Mypy ei suuda alati selliseid asju tuvastada, kuni suurem osa impordiahelast on töödeldud. Alores selliseid kahemõttelisusi ei olnud. Süsteemi arendamise algfaasis tehtud kehvad otsused võivad paljude aastate pärast programmeerijale ebameeldiva üllatuse valmistada.
Tulemused: tee 5 miljoni koodireani ja uutele horisontidele
Mypy projekt on jõudnud kaugele – varastest prototüüpidest kuni süsteemini, mis kontrollib 4 miljonit tootmiskooditüüpi. Mypy arenedes standardiseeriti Pythoni tüübivihjed. Nendel päevadel on Pythoni koodi tippimise ümber välja kujunenud võimas ökosüsteem. Sellel on koht raamatukogu toe jaoks, see sisaldab IDE-de ja redaktorite abitööriistu, sellel on mitu tüüpi juhtimissüsteemi, millest igaühel on oma plussid ja miinused.
Kuigi tüübikontroll on Dropboxis juba ette nähtud, usun, et oleme Pythoni koodi tippimisega alles algusaegadel. Arvan, et tüübikontrolli tehnoloogiad arenevad ja täiustuvad jätkuvalt.
Kui te pole oma suuremahulises Pythoni projektis tüübikontrolli veel kasutanud, siis tea, et praegu on väga hea aeg hakata üle minema staatilisele tippimisele. Olen rääkinud nendega, kes on sarnase ülemineku teinud. Keegi neist ei kahetsenud. Tüübikontroll teeb Pythonist keele, mis sobib suurte projektide arendamiseks palju paremini kui "tavaline Python".
Kallid lugejad! Kas kasutate oma Pythoni projektides tüübikontrolli?
Allikas: www.habr.com