Python կոդի 4 միլիոն տողերի տիպի ստուգման ուղին: Մաս 3

Ձեր ուշադրությանն ենք ներկայացնում նյութի թարգմանության երրորդ մասը այն ուղու մասին, որն անցել է Dropbox-ը Python կոդի համար տիպերի ստուգման համակարգ իրականացնելիս։

Python կոդի 4 միլիոն տողերի տիպի ստուգման ուղին: Մաս 3

→ Նախորդ մասեր. առաջին и երկրորդ

Հասնելով մուտքագրված կոդի 4 միլիոն տողի

Մեկ այլ կարևոր մարտահրավեր (և ներքին հարցվածների շրջանում երկրորդ ամենատարածված մտահոգությունը) Dropbox-ում տիպի ստուգմամբ ծածկված ծածկագրի քանակի ավելացումն էր: Մենք փորձել ենք այս խնդիրը լուծելու մի քանի մոտեցումներ՝ տպագրված կոդերի բազայի բնականոն չափի մեծացումից մինչև mypy թիմի ջանքերը ստատիկ և դինամիկ ավտոմատացված տիպի եզրակացության վրա կենտրոնացնելը: Ի վերջո, թվում էր, թե պարզ հաղթող ռազմավարություն չկար, բայց մենք կարողացանք հասնել ծանոթագրված կոդի ծավալի արագ աճի` համատեղելով բազմաթիվ մոտեցումներ:

Արդյունքում, Python-ի մեր ամենամեծ պահոցը (backend կոդով) ունի մոտ 4 միլիոն տող ծանոթագրված կոդ: Ստատիկ կոդի մուտքագրման աշխատանքներն ավարտվեցին մոտավորապես երեք տարում: Mypy-ն այժմ աջակցում է կոդերի ծածկույթի տարբեր տեսակի հաշվետվությունների, որոնք հեշտացնում են մուտքագրման առաջընթացը վերահսկելը: Մասնավորապես, մենք կարող ենք կոդի վերաբերյալ հաշվետվություններ ստեղծել տեսակների երկիմաստություններով, ինչպիսիք են, օրինակ, տիպի բացահայտ օգտագործումը Any ծանոթագրություններում, որոնք չեն կարող ստուգվել, կամ այնպիսի բաների հետ, ինչպիսիք են երրորդ կողմի գրադարանների ներմուծումը, որոնք չունեն տեսակի ծանոթագրություններ: Որպես Dropbox-ում տիպերի ստուգման ճշգրտությունը բարելավելու նախագծի մաս, մենք նպաստեցինք Python կենտրոնացված պահոցում որոշ հայտնի բաց կոդով գրադարանների տիպերի սահմանումների (այսպես կոչված կոճ ֆայլերի) բարելավմանը: մեքենագրված.

Մենք ներդրել ենք (և ստանդարտացրել ենք հետագա PEP-ներում) տիպային համակարգի նոր առանձնահատկություններ, որոնք թույլ են տալիս ավելի ճշգրիտ տիպեր որոշ Python-ի որոշ օրինաչափությունների համար: Դրա ուշագրավ օրինակն է TypeDict, որը տրամադրում է տեսակներ JSON-ի նման բառարանների համար, որոնք ունեն լարային ստեղների ֆիքսված հավաքածու, որոնցից յուրաքանչյուրն ունի իր տեսակի արժեք: Մենք շարունակելու ենք ընդլայնել տիպային համակարգը։ Մեր հաջորդ քայլը, հավանաբար, կլինի բարելավել Python-ի թվային հնարավորությունների աջակցությունը:

Python կոդի 4 միլիոն տողերի տիպի ստուգման ուղին: Մաս 3
Ծանոթագրված կոդի տողերի քանակը՝ սերվեր

Python կոդի 4 միլիոն տողերի տիպի ստուգման ուղին: Մաս 3
Ծանոթագրված կոդի տողերի քանակը՝ հաճախորդ

Python կոդի 4 միլիոն տողերի տիպի ստուգման ուղին: Մաս 3
Ծանոթագրված կոդի տողերի ընդհանուր քանակը

Ահա Dropbox-ում ծանոթագրված կոդի քանակն ավելացնելու համար մեր արած գործերի հիմնական առանձնահատկությունների ակնարկը.

Անոտացիայի խստություն. Մենք աստիճանաբար ավելացրինք նոր կոդի ծանոթագրման խստության պահանջները: Մենք սկսեցինք լինտերի խորհուրդներով, որոնք առաջարկում էին ծանոթագրություններ ավելացնել ֆայլերին, որոնք արդեն ունեին որոշ ծանոթագրություններ: Այժմ մենք պահանջում ենք տիպի ծանոթագրություններ նոր Python ֆայլերում և առկա ֆայլերի մեծ մասում:

Մուտքագրման հաշվետվություններ: Մենք թիմերին ամենշաբաթյա հաշվետվություններ ենք ուղարկում իրենց ծածկագիրը մուտքագրելու մակարդակի վերաբերյալ և խորհուրդներ ենք տալիս այն մասին, թե ինչ պետք է նախ նշվի:

Mypy-ի հանրահռչակում. Մենք խոսում ենք mypy-ի մասին իրադարձությունների ժամանակ և զրուցում թիմերի հետ՝ օգնելու նրանց սկսել տիպի ծանոթագրություններով:

Հարցումներ. Մենք պարբերաբար անցկացնում ենք օգտատերերի հարցումներ՝ բացահայտելու հիմնական խնդիրները: Մենք պատրաստ ենք բավականին հեռու գնալ այս խնդիրների լուծման գործում (նույնիսկ ստեղծելով նոր լեզու mypy-ն արագացնելու համար):

Կատարում. Մենք մեծապես բարելավել ենք mypy-ի կատարումը՝ օգտագործելով daemon-ը և mypyc-ը: Դա արվել է անոտացիայի գործընթացում առաջացող անհարմարությունները հարթելու և մեծ քանակությամբ կոդի հետ աշխատելու համար։

Ինտեգրում խմբագիրների հետ: Մենք ստեղծել ենք գործիքներ՝ աջակցելու mypy-ի գործարկմանը Dropbox-ում տարածված խմբագիրներում: Սա ներառում է PyCharm, Vim և VS Code: Սա զգալիորեն պարզեցրել է կոդը ծանոթագրելու և դրա ֆունկցիոնալությունը ստուգելու գործընթացը: Այս տեսակի գործողությունները սովորական են գոյություն ունեցող ծածկագիրը ծանոթագրելիս:

Ստատիկ վերլուծություն. Մենք ստեղծել ենք գործիք՝ ստատիկ վերլուծության գործիքների միջոցով ֆունկցիոնալ ստորագրությունները եզրակացնելու համար: Այս գործիքը կարող է աշխատել միայն համեմատաբար պարզ իրավիճակներում, սակայն այն օգնեց մեզ առանց մեծ ջանքերի մեծացնել մեր կոդի տեսակի ծածկույթը:

Աջակցություն երրորդ կողմի գրադարաններին: Մեր նախագծերից շատերն օգտագործում են SQLAlchemy գործիքակազմը: Այն օգտվում է Python-ի դինամիկ հնարավորություններից, որոնք PEP 484 տեսակները չեն կարողանում ուղղակիորեն մոդելավորել: Մենք, համաձայն PEP 561-ի, ստեղծեցինք համապատասխան անավարտ ֆայլը և գրեցինք հավելված mypy-ի համար (բաց կոդով), որը բարելավում է SQLAlchemy-ի աջակցությունը։

Դժվարություններ, որոնց հանդիպեցինք

Մեզ համար 4 միլիոն տող մուտքագրված կոդի ճանապարհը միշտ չէ, որ հեշտ է եղել: Այս ճանապարհին մենք հանդիպեցինք բազմաթիվ փոսերի և թույլ տվեցինք մի քանի սխալ: Սրանք այն խնդիրներից են, որոնք մենք բախվել ենք: Հուսով ենք, որ նրանց մասին պատմելը կօգնի մյուսներին խուսափել նմանատիպ խնդիրներից:

Բացակայող ֆայլեր: Մենք սկսեցինք մեր աշխատանքը՝ ստուգելով միայն փոքր քանակությամբ ֆայլեր: Այն, ինչ ներառված չէ այս ֆայլերում, չի ստուգվել: Ֆայլերը ավելացվել են սկանավորման ցանկում, երբ դրանցում հայտնվեցին առաջին ծանոթագրությունները: Եթե ​​ինչ-որ բան ներմուծվել է ստուգման շրջանակից դուրս գտնվող մոդուլից, ապա մենք խոսում էինք այնպիսի արժեքների հետ աշխատելու մասին, ինչպիսիք են. Any, որոնք ընդհանրապես չեն փորձարկվել։ Սա հանգեցրեց մուտքագրման ճշգրտության զգալի կորստի, հատկապես միգրացիայի սկզբնական փուլերում: Այս մոտեցումը մինչ այժմ զարմանալիորեն լավ է աշխատել, չնայած բնորոշ իրավիճակն այն է, որ վերանայման շրջանակում ֆայլեր ավելացնելը բացահայտում է կոդերի բազայի այլ մասերում առկա խնդիրներ: Վատագույն դեպքում, երբ կոդի երկու մեկուսացված տարածքներ միավորվեցին, որոնցում, միմյանցից անկախ, արդեն ստուգված էին տիպերը, պարզվեց, որ այդ տարածքների տեսակներն անհամատեղելի են միմյանց հետ։ Սա հանգեցրեց անոտացիաներում բազմաթիվ փոփոխություններ կատարելու անհրաժեշտությանը: Հիմա հետ նայելով, մենք հասկանում ենք, որ ավելի շուտ պետք է ավելացնեինք հիմնական գրադարանային մոդուլները mypy-ի տիպերի ստուգման տարածքում: Սա մեր աշխատանքը շատ ավելի կանխատեսելի կդարձներ։

Հին ծածկագրի նշում: Երբ մենք սկսեցինք, մենք ունեինք մոտ 4 միլիոն տող գոյություն ունեցող Python կոդ: Հասկանալի էր, որ այս ամբողջ ծածկագրի նշումը հեշտ գործ չէր։ Մենք ստեղծել ենք PyAnnotate կոչվող գործիքը, որը կարող է հավաքել տիպի տեղեկություններ, երբ թեստերն աշխատում են, և կարող է ավելացնել տիպի ծանոթագրություններ ձեր կոդի վրա՝ հիմնվելով հավաքված տեղեկատվության վրա: Այնուամենայնիվ, մենք չենք նկատել այս գործիքի առանձնապես լայն տարածում: Տիպի տեղեկությունների հավաքումը դանդաղ էր, և ինքնաբերաբար ստեղծվող ծանոթագրությունները հաճախ պահանջում էին բազմաթիվ ձեռքով խմբագրումներ: Մենք մտածում էինք այս գործիքը ավտոմատ կերպով գործարկելու մասին ամեն անգամ, երբ վերանայում էինք կոդը, կամ հավաքում էինք տիպի մասին տեղեկատվություն՝ հիմնված ցանցի իրական հարցումների որոշ փոքր ծավալի վերլուծության վրա, բայց որոշեցինք չանել, քանի որ երկու մոտեցումն էլ չափազանց ռիսկային էր:

Արդյունքում, կարելի է նշել, որ կոդի մեծ մասը ձեռքով գրվել է դրա տերերի կողմից: Այս գործընթացը ճիշտ ուղղությամբ տանելու համար մենք պատրաստում ենք հաշվետվություններ հատկապես կարևոր մոդուլների և գործառույթների վերաբերյալ, որոնք պետք է ծանոթագրվեն: Օրինակ, կարևոր է տիպային ծանոթագրություններ տրամադրել գրադարանային մոդուլի համար, որն օգտագործվում է հարյուրավոր վայրերում: Սակայն հին ծառայությունը, որը փոխարինվում է նորով, այլևս այնքան էլ կարևոր չէ ծանոթագրել: Մենք նաև փորձարկում ենք՝ օգտագործելով ստատիկ վերլուծություն՝ ժառանգական կոդի համար տիպային ծանոթագրություններ ստեղծելու համար:

Ցիկլային ներմուծում. Վերևում ես խոսեցի ցիկլային ներմուծման մասին («կախվածության խճճվածություններ»), որոնց առկայությունը դժվարացնում էր mypy-ի արագացումը։ Մենք նաև ստիպված էինք քրտնաջան աշխատել, որպեսզի mypy-ն աջակցի բոլոր տեսակի արտահայտություններին, որոնք առաջանում են այս ցիկլային ներմուծման հետևանքով: Մենք վերջերս ավարտեցինք համակարգի վերանախագծման հիմնական նախագիծը, որը շտկեց mypy-ի խնդիրների մեծ մասը՝ կապված շրջանաձև ներմուծման հետ: Այս խնդիրներն իրականում բխում էին նախագծի հենց վաղ օրերից՝ վերադառնալով Alore-ից՝ կրթական լեզվից, որի վրա ի սկզբանե կենտրոնացած էր mypy նախագիծը: Alore շարահյուսությունը հեշտացնում է ցիկլային ներմուծման հրամանների հետ կապված խնդիրները: Ժամանակակից mypy-ը ժառանգել է որոշ սահմանափակումներ իր ավելի վաղ, պարզամիտ իրականացումից (որը հիանալի հարմար էր Alore-ի համար): Python-ը դժվարացնում է շրջանաձև ներմուծումների հետ աշխատելը, հիմնականում այն ​​պատճառով, որ արտահայտությունները երկիմաստ են: Օրինակ, հանձնարարական գործողությունը կարող է իրականում սահմանել տիպի այլանուն: Mypy-ը միշտ չէ, որ կարողանում է հայտնաբերել նման բաներ, քանի դեռ ներմուծման օղակի մեծ մասը չի մշակվել: Ալորեում նման երկիմաստություններ չկային։ Համակարգի զարգացման վաղ փուլերում ընդունված սխալ որոշումները կարող են շատ տարիներ անց տհաճ անակնկալ մատուցել ծրագրավորողին:

Արդյունքները. ճանապարհ դեպի 5 միլիոն տող կոդ և նոր հորիզոններ

Mypy նախագիծը երկար ճանապարհ է անցել՝ վաղ նախատիպերից մինչև համակարգ, որը վերահսկում է արտադրության կոդի տեսակների 4 միլիոն տող: Երբ mypy-ն զարգացավ, Python-ի տիպի ակնարկները ստանդարտացվեցին: Այս օրերին հզոր էկոհամակարգ է ձևավորվել Python կոդը մուտքագրելու շուրջ: Այն ունի գրադարանային աջակցության տեղ, պարունակում է օժանդակ գործիքներ IDE-ների և խմբագիրների համար, ունի մի քանի տեսակի կառավարման համակարգեր, որոնցից յուրաքանչյուրն ունի իր դրական և բացասական կողմերը։

Թեև տիպի ստուգումն արդեն տրված է Dropbox-ում, ես կարծում եմ, որ մենք դեռ Python կոդը մուտքագրելու առաջին օրերին ենք: Կարծում եմ՝ տեսակի ստուգման տեխնոլոգիաները կշարունակեն զարգանալ և կատարելագործվել:

Եթե ​​դուք դեռ չեք օգտագործել տիպի ստուգումը ձեր լայնածավալ Python նախագծում, ապա իմացեք, որ հիմա շատ լավ ժամանակ է անցնելու ստատիկ մուտքագրմանը: Ես խոսել եմ նրանց հետ, ովքեր նմանատիպ անցում են կատարել։ Նրանցից ոչ ոք չզղջաց դրա համար։ Տիպի ստուգումը Python-ին դարձնում է լեզու, որը շատ ավելի հարմար է մեծ նախագծեր մշակելու համար, քան «սովորական Python»-ը:

Հարգելի ընթերցողներ: Դուք օգտագործում եք տիպի ստուգում ձեր Python նախագծերում:

Python կոդի 4 միլիոն տողերի տիպի ստուգման ուղին: Մաս 3
Python կոդի 4 միլիոն տողերի տիպի ստուգման ուղին: Մաս 3

Source: www.habr.com

Добавить комментарий