Bemutatjuk figyelmükbe a Dropbox által a Python-kód típusellenőrző rendszerének megvalósítása során megtett útról szóló anyag fordításának harmadik részét.
→ Korábbi részek: и
Eléri a 4 millió sornyi gépelt kódot
Egy másik nagy kihívás (és a második leggyakoribb probléma a belső felmérésben részt vevők körében) a Dropbox típusellenőrzésével lefedett kód mennyiségének növelése volt. Számos megközelítést kipróbáltunk a probléma megoldására, a tipizált kódbázis méretének természetes növelésétől a mypy csapat erőfeszítéseinek a statikus és dinamikus automatizált típuskövetkeztetésre való összpontosításáig. Végül úgy tűnt, hogy nincs egyszerű nyerő stratégia, de sok megközelítés kombinálásával gyors növekedést tudtunk elérni a kommentált kódok mennyiségében.
Ennek eredményeként a legnagyobb Python-tárunkban (a háttérkóddal) közel 4 millió sornyi megjegyzéssel ellátott kód található. A statikus kódírással kapcsolatos munka körülbelül három év alatt fejeződött be. A Mypy mostantól támogatja a különböző típusú kódlefedettségi jelentéseket, amelyek megkönnyítik a gépelési folyamat nyomon követését. Különösen olyan kódokról készíthetünk jelentéseket, amelyek típusai nem egyértelműek, mint például egy típus kifejezett használata. Any olyan megjegyzésekben, amelyeket nem lehet ellenőrizni, vagy olyan dolgokkal, mint például a típusjegyzetekkel nem rendelkező, harmadik féltől származó könyvtárak importálása. A Dropboxban a típusellenőrzés pontosságának javítását célzó projekt részeként hozzájárultunk néhány népszerű nyílt forráskódú könyvtár típusdefinícióinak (úgynevezett csonkfájlok) javításához egy központi Python-tárolóban. .
Megvalósítottuk (és szabványosítottuk a következő PEP-ekben) a típusrendszer új funkcióit, amelyek pontosabb típusokat tesznek lehetővé bizonyos Python mintákhoz. Figyelemre méltó példa erre az TypeDict, amely típusokat biztosít a JSON-szerű szótárak számára, amelyek rögzített karakterlánc-kulcskészlettel rendelkeznek, amelyek mindegyike saját típusú értékkel rendelkezik. Folytatjuk a típusrendszer bővítését. A következő lépésünk valószínűleg a Python numerikus képességeinek támogatásának javítása lesz.
Az annotált kód sorainak száma: szerver
Az annotált kód sorainak száma: kliens
A megjegyzésekkel ellátott kód sorainak teljes száma
Íme egy áttekintés azon dolgok főbb jellemzőiről, amelyeket azért tettünk, hogy növeljük a megjegyzésekkel ellátott kód mennyiségét a Dropboxban:
Annotációs szigor. Fokozatosan növeltük az új kódok megjegyzéseinek szigorú követelményeit. Linter-tippekkel kezdtük, amelyek azt javasolták, hogy adjunk hozzá megjegyzéseket azokhoz a fájlokhoz, amelyek már tartalmaztak megjegyzéseket. Mostantól megköveteljük a típusjegyzeteket az új Python-fájlokban és a legtöbb meglévő fájlban.
Jelentések gépelése. A csapatoknak hetente jelentést küldünk a kód beírásának szintjéről, és tanácsot adunk, hogy mit érdemes először megjegyzésekkel ellátni.
A mypy népszerűsítése. Események alkalmával beszélünk a mypy-ről, és beszélgetünk csapatokkal, hogy segítsünk nekik elkezdeni a típusjegyzetekkel.
Szavazások. Rendszeres felhasználói felméréseket végzünk a nagyobb problémák azonosítása érdekében. Készek vagyunk messzire elmenni ezeknek a problémáknak a megoldásában (akár egy új nyelv létrehozása is a mypy felgyorsítása érdekében!).
Teljesítmény. A démon és a mypyc használatával nagymértékben javítottuk a mypy teljesítményét. Erre azért került sor, hogy az annotálási folyamat során felmerülő kellemetlenségeket kiegyenlítse, és hogy nagy mennyiségű kóddal lehessen dolgozni.
Integráció a szerkesztőkkel. Eszközöket építettünk a mypy futtatásának támogatására a Dropboxon népszerű szerkesztőkben. Ide tartozik a PyCharm, a Vim és a VS Code. Ez nagymértékben leegyszerűsítette a kód megjegyzéseinek és működésének ellenőrzésének folyamatát. Az ilyen típusú műveletek gyakoriak a meglévő kód megjegyzéseinél.
Statikus elemzés. Létrehoztunk egy olyan eszközt, amellyel statikus elemző eszközökkel lehet következtetni a függvényaláírásokra. Ez az eszköz csak viszonylag egyszerű helyzetekben tud működni, de segített nekünk különösebb erőfeszítés nélkül növelni a kódtípus lefedettségét.
Harmadik fél könyvtárainak támogatása. Számos projektünk használja az SQLAlchemy eszközkészletet. Kihasználja a Python dinamikus képességeit, amelyeket a PEP 484 típusok nem képesek közvetlenül modellezni. A PEP 561-nek megfelelően létrehoztuk a megfelelő csonkfájlt, és írtunk egy plugint a mypy (), amely javítja az SQLAlchemy támogatást.
Nehézségek, amelyekkel találkoztunk
A 4 millió sornyi gépelt kódhoz vezető út nem mindig volt könnyű számunkra. Ezen az úton sok kátyúval találkoztunk, és több hibát is elkövettünk. Ez néhány probléma, amellyel találkoztunk. Reméljük, hogy róluk elmondva másoknak is segít elkerülni a hasonló problémákat.
Hiányzó fájlok. Munkánkat csak kis mennyiségű fájl ellenőrzésével kezdtük. A fájlokban nem szereplő elemeket nem ellenőrizték. A fájlok akkor kerültek a szkennelési listára, amikor az első megjegyzések megjelentek bennük. Ha valamit importáltak egy olyan modulból, amely kívül esik az ellenőrzés hatókörén, akkor olyan értékekkel való munkáról beszéltünk, mint pl Any, amelyeket egyáltalán nem teszteltek. Ez a gépelési pontosság jelentős csökkenéséhez vezetett, különösen a migráció korai szakaszában. Ez a megközelítés eddig meglepően jól működött, bár tipikus helyzet az, hogy a fájlok hozzáadása a felülvizsgálat hatóköréhez problémákat tár fel a kódbázis más részein. A legrosszabb esetben, amikor két elszigetelt kódterületet egyesítettek, amelyekben egymástól függetlenül már típusokat ellenőriztek, kiderült, hogy ezeknek a területeknek a típusai nem kompatibilisek egymással. Ez ahhoz vezetett, hogy sok változtatást kellett végrehajtani a megjegyzéseken. Most visszatekintve rájöttünk, hogy korábban kellett volna alapkönyvtári modulokat hozzáadnunk a mypy típusellenőrzési területéhez. Ez sokkal kiszámíthatóbbá tenné a munkánkat.
Régi kód megjegyzése. Amikor elkezdtük, körülbelül 4 millió sornyi Python kód volt. Nyilvánvaló volt, hogy ennek a kódnak a kommentálása nem volt könnyű feladat. Létrehoztunk egy PyAnnotate nevű eszközt, amely a tesztek lefutása során típusinformációkat gyűjthet, és az összegyűjtött információk alapján típusjegyzeteket adhat a kódhoz. Ennek az eszköznek azonban nem vettük észre, hogy különösebben elterjedt volna. A típusinformációk gyűjtése lassú volt, és az automatikusan generált megjegyzések gyakran sok manuális szerkesztést igényeltek. Arra gondoltunk, hogy minden alkalommal, amikor áttekintjük a kódot, automatikusan lefuttatjuk ezt az eszközt, vagy kis mennyiségű tényleges hálózati kérés elemzése alapján gyűjtünk típusadatokat, de úgy döntöttünk, hogy nem tesszük, mert bármelyik megközelítés túl kockázatos.
Ennek eredményeként megjegyezhető, hogy a kód nagy részét a tulajdonosok manuálisan kommentálták. Annak érdekében, hogy ezt a folyamatot helyes irányba tereljük, jelentéseket készítünk a különösen fontos modulokról és funkciókról, amelyeket megjegyzésekkel kell ellátni. Például fontos, hogy egy több száz helyen használt könyvtári modulhoz típusjegyzeteket biztosítsunk. De egy régi szolgáltatást, amelyet egy újra cserélnek, már nem annyira fontos, hogy megjegyzéseket fűzzünk hozzá. Kísérletezünk a statikus elemzés használatával is, hogy típusjegyzeteket generáljunk a régi kódhoz.
Ciklikus import. Fentebb a ciklikus importról (a „függőségi gubancokról”) beszéltem, amelyek megléte megnehezítette a mypy felgyorsítását. Keményen kellett dolgoznunk azon is, hogy a mypy támogassa az összes idiómát, amelyet ezek a ciklikus importok okoznak. Nemrég fejeztünk be egy nagy rendszer-újratervezési projektet, amely megoldotta a legtöbb mypy-problémát a körkörös importtal kapcsolatban. Ezek a problémák valójában a projekt korai napjaiból fakadtak, még az Alore-ból, az oktatási nyelvből, amelyre a mypy projekt eredetileg összpontosított. Az Alore szintaxis megkönnyíti a ciklikus importparancsokkal kapcsolatos problémák megoldását. A modern mypy bizonyos korlátokat örökölt korábbi, egyszerű megvalósításától (ami remekül passzolt az Alore-hoz). A Python megnehezíti a körkörös importálást, főleg azért, mert a kifejezések nem egyértelműek. Például egy hozzárendelési művelet ténylegesen meghatározhat egy típusálnevet. A Mypy nem mindig képes észlelni az ehhez hasonló dolgokat, amíg az importhurok nagy részét fel nem dolgozták. Alore-ban nem voltak ilyen kétértelműségek. A rendszerfejlesztés korai szakaszában hozott rossz döntések sok év múlva kellemetlen meglepetést okozhatnak a programozónak.
Eredmények: az 5 millió kódsorhoz vezető út és új horizontok
A mypy projekt hosszú utat tett meg – a korai prototípusoktól a 4 millió soros gyártási kódtípust vezérlő rendszerig. Ahogy a mypy fejlődött, a Python típusú tippeket szabványosították. Napjainkban egy erőteljes ökoszisztéma alakult ki a Python kód beírása körül. Van helye a könyvtári támogatásnak, tartalmaz segédeszközöket IDE-khez és szerkesztőkhöz, többféle típusú vezérlőrendszerrel rendelkezik, amelyek mindegyikének megvannak a maga előnyei és hátrányai.
Annak ellenére, hogy a típusellenőrzés már adott a Dropboxnál, úgy gondolom, hogy a Python-kód beírásának még mindig az elején járunk. Úgy gondolom, hogy a típusellenőrzési technológiák tovább fognak fejlődni és javulni fognak.
Ha még nem használta a típusellenőrzést nagyszabású Python-projektjében, akkor tudja, hogy most nagyon jó alkalom a statikus gépelésre való átállásra. Beszéltem azokkal, akik hasonló átmenetet hajtottak végre. Egyikük sem bánta meg. A típusellenőrzés olyan nyelvvé teszi a Pythont, amely sokkal jobban alkalmas nagy projektek fejlesztésére, mint a „szokásos Python”.
Kedves olvasók! Használsz típusellenőrzést Python-projekteidben?
Forrás: will.com