ProHoster > Blogs > Administrācija > CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa

CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa

Piedāvājam jÅ«su uzmanÄ«bai treÅ”o daļu no materiāla tulkojuma par ceļu, kuru Dropbox veica, ievieÅ”ot Python koda tipa pārbaudes sistēmu.

CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa

ā†’ IepriekŔējās daļas: vispirms Šø otrais

Sasniedzot 4 miljonus ierakstītā koda rindiņu

Vēl viens nozÄ«mÄ«gs izaicinājums (un otrais visbiežāk sastopamais jautājums iekŔēji aptaujāto vidÅ«) bija palielināt koda daudzumu, uz kuru attiecas Dropbox tipa pārbaudes. Mēs esam izmēģinājuÅ”i vairākas pieejas, lai atrisinātu Å”o problēmu, sākot ar dabisku drukātās kodu bāzes lieluma palielināŔanu un beidzot ar mypy komandas centienu koncentrÄ“Å”anu uz statisku un dinamisku automatizētu tipu secinājumu izdarÄ«Å”anu. Galu galā Ŕķita, ka nav vienkārÅ”as uzvaras stratēģijas, taču mēs spējām panākt strauju anotētā koda apjoma pieaugumu, apvienojot daudzas pieejas.

Rezultātā mÅ«su lielākajā Python repozitorijā (ar aizmugurkodu) ir gandrÄ«z 4 miljoni anotēta koda rindu. Darbs pie statiskā koda rakstÄ«Å”anas tika pabeigts aptuveni trÄ«s gadu laikā. Mypy tagad atbalsta dažāda veida koda pārklājuma pārskatus, kas atvieglo rakstÄ«Å”anas progresa pārraudzÄ«bu. Jo Ä«paÅ”i mēs varam Ä£enerēt pārskatus par kodu ar neskaidrÄ«bām tipos, piemēram, piemēram, nepārprotami izmantotu veidu. Any anotācijās, kuras nevar pārbaudÄ«t, vai ar tādām lietām kā treÅ”o puÅ”u bibliotēku importÄ“Å”ana, kurām nav tipa anotāciju. Kā daļu no projekta, lai uzlabotu Dropbox tipa pārbaudes precizitāti, mēs palÄ«dzējām uzlabot tipu definÄ«cijas (tā sauktos stub failus) dažām populārām atvērtā pirmkoda bibliotēkām centralizētā Python repozitorijā. sadrukāts.

Mēs ieviesām (un standartizējām turpmākajos PEP) jaunas tipa sistēmas funkcijas, kas ļauj noteikt precÄ«zākus veidus dažiem konkrētiem Python modeļiem. Ievērojams piemērs tam ir TypeDict, kas nodroÅ”ina veidus JSON lÄ«dzÄ«gām vārdnÄ«cām, kurām ir fiksēta virkņu atslēgu kopa, katrai no kurām ir sava veida vērtÄ«ba. Mēs turpināsim paplaÅ”ināt tipu sistēmu. MÅ«su nākamais solis, visticamāk, bÅ«s uzlabot atbalstu Python skaitliskajām iespējām.

CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa
Anotētā koda rindu skaits: serveris

CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa
Anotētā koda rindu skaits: klients

CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa
Kopējais anotētā koda rindiņu skaits

Tālāk ir sniegts pārskats par galvenajām funkcijām, ko veicām, lai palielinātu anotētā koda daudzumu pakalpojumā Dropbox.

Anotācijas stingrÄ«ba. Mēs pakāpeniski palielinājām prasÄ«bas attiecÄ«bā uz jaunā koda anotÄ“Å”anas stingrÄ«bu. Mēs sākām ar lintera padomiem, kas ieteica pievienot anotācijas failiem, kuriem jau bija dažas anotācijas. Tagad mums ir nepiecieÅ”amas tipa anotācijas jaunajos Python failos un lielākajā daļā esoÅ”o failu.

Pārskatu rakstÄ«Å”ana. Mēs nosÅ«tām komandām iknedēļas ziņojumus par to koda ievadÄ«Å”anas lÄ«meni un sniedzam padomus par to, kas vispirms bÅ«tu jāanotē.

Mypy popularizÄ“Å”ana. Mēs runājam par mypy pasākumos un runājam ar komandām, lai palÄ«dzētu viņiem sākt darbu ar veidu anotācijām.

Aptaujas. Mēs veicam periodiskas lietotāju aptaujas, lai identificētu galvenās problēmas. Mēs esam gatavi iet diezgan tālu, risinot Ŕīs problēmas (pat izveidojot jaunu valodu, lai paātrinātu mypy!).

Performance. Mēs esam ievērojami uzlabojuÅ”i mypy veiktspēju, izmantojot dēmonu un mypyc. Tas tika darÄ«ts, lai izlÄ«dzinātu neērtÄ«bas, kas rodas anotācijas procesā, un lai varētu strādāt ar lielu koda daudzumu.

Integrācija ar redaktoriem. Mēs esam izveidojuÅ”i rÄ«kus, lai atbalstÄ«tu mypy palaiÅ”anu redaktoros, kas ir populāri pakalpojumā Dropbox. Tas ietver PyCharm, Vim un VS kodu. Tas ievērojami vienkārÅ”oja koda anotÄ“Å”anas un tā funkcionalitātes pārbaudes procesu. Šāda veida darbÄ«bas ir izplatÄ«tas, anotējot esoÅ”o kodu.

Statiskā analÄ«ze. Mēs izveidojām rÄ«ku funkciju parakstu izsecināŔanai, izmantojot statiskās analÄ«zes rÄ«kus. Å is rÄ«ks var darboties tikai salÄ«dzinoÅ”i vienkārŔās situācijās, taču tas mums palÄ«dzēja bez lielām pÅ«lēm palielināt koda veidu pārklājumu.

Atbalsts treÅ”o puÅ”u bibliotēkām. Daudzos mÅ«su projektos tiek izmantots SQLAlchemy rÄ«ku komplekts. Tas izmanto Python dinamiskās iespējas, kuras PEP 484 tipi nespēj tieÅ”i modelēt. Mēs saskaņā ar PEP 561 izveidojām atbilstoÅ”o stub failu un uzrakstÄ«jām spraudni mypy (atvērtais avots), kas uzlabo SQLAlchemy atbalstu.

Grūtības, ar kurām saskārāmies

CeļŔ uz 4 miljoniem ierakstÄ«ta koda rindiņu mums ne vienmēr ir bijis viegls. Å ajā ceļā mēs sastapāmies ar daudzām bedrēm un pieļāvām vairākas kļūdas. Å Ä«s ir dažas no problēmām, ar kurām mēs saskārāmies. Mēs ceram, ka stāstÄ«Å”ana par tām palÄ«dzēs citiem izvairÄ«ties no lÄ«dzÄ«gām problēmām.

TrÅ«kst failu. Mēs sākām darbu, pārbaudot tikai nelielu failu daudzumu. Nekas, kas nav iekļauts Å”ajos failos, netika pārbaudÄ«ts. Faili tika pievienoti skenÄ“Å”anas sarakstam, kad tajos parādÄ«jās pirmās anotācijas. Ja kaut kas tika importēts no moduļa, kas atrodas ārpus verifikācijas jomas, tad mēs runājām par darbu ar tādām vērtÄ«bām kā Any, kas vispār netika pārbaudÄ«ti. Tas izraisÄ«ja ievērojamu rakstÄ«Å”anas precizitātes zudumu, Ä«paÅ”i migrācijas sākumposmā. Å Ä« pieeja lÄ«dz Å”im ir strādājusi pārsteidzoÅ”i labi, lai gan tipiska situācija ir tāda, ka failu pievienoÅ”ana pārskatÄ«Å”anas jomai atklāj problēmas citās kodu bāzes daļās. Sliktākajā gadÄ«jumā, kad tika apvienoti divi izolēti koda apgabali, kuros neatkarÄ«gi viens no otra jau tika pārbaudÄ«ti tipi, izrādÄ«jās, ka Å”o apgabalu veidi nav savstarpēji savienojami. Tas radÄ«ja nepiecieÅ”amÄ«bu veikt daudzas izmaiņas anotācijās. Atskatoties tagad, mēs saprotam, ka mums vajadzēja ātrāk pievienot galvenos bibliotēkas moduļus mypy tipa pārbaudes apgabalam. Tas padarÄ«tu mÅ«su darbu daudz paredzamāku.

Vecā koda anotÄ“Å”ana. Kad mēs sākām, mums bija aptuveni 4 miljoni esoŔā Python koda rindu. Bija skaidrs, ka visa Ŕī koda anotÄ“Å”ana nebija viegls uzdevums. Mēs esam izveidojuÅ”i rÄ«ku PyAnnotate, kas var apkopot tipa informāciju testu laikā un var pievienot tipa anotācijas jÅ«su kodam, pamatojoties uz savākto informāciju. Tomēr mēs neesam pamanÄ«juÅ”i Ä«paÅ”i plaÅ”u Ŕī rÄ«ka ievieÅ”anu. Veida informācijas vākÅ”ana bija lēna, un automātiski Ä£enerētās anotācijas bieži vien bija jāveic manuāli. Mēs domājām par Ŕī rÄ«ka automātisku palaiÅ”anu ikreiz, kad pārskatām kodu, vai apkopojām veidu informāciju, pamatojoties uz nelielu faktisko tÄ«kla pieprasÄ«jumu skaita analÄ«zi, taču nolēmām to nedarÄ«t, jo abas pieejas bija pārāk riskantas.

Rezultātā var atzÄ«mēt, ka lielāko daļu koda manuāli anotēja tā Ä«paÅ”nieki. Lai virzÄ«tu Å”o procesu pareizajā virzienā, mēs sagatavojam atskaites par Ä«paÅ”i svarÄ«giem moduļiem un funkcijām, kuras ir jāanotē. Piemēram, ir svarÄ«gi nodroÅ”ināt tipa anotācijas bibliotēkas modulim, kas tiek izmantots simtiem vietu. Bet vecs pakalpojums, kas tiek aizstāts ar jaunu, vairs nav tik svarÄ«gs, lai komentētu. Mēs arÄ« eksperimentējam ar statiskās analÄ«zes izmantoÅ”anu, lai Ä£enerētu tipa anotācijas mantotajam kodam.

Ciklisks imports. IepriekÅ” es runāju par ciklisko importu (ā€œatkarÄ«bas samezglojumiemā€), kuru esamÄ«ba apgrÅ«tināja mypy paātrināŔanu. Mums bija arÄ« smagi jāstrādā, lai mypy atbalstÄ«tu visa veida idiomas, ko izraisa Å”is cikliskais imports. Mēs nesen pabeidzām lielu sistēmas pārprojektÄ“Å”anas projektu, kas atrisināja lielāko daļu mypy problēmu saistÄ«bā ar cirkulāro importu. Å Ä«s problēmas patiesÄ«bā radās projekta pirmajās dienās, sākot no Alore, izglÄ«tojoŔās valodas, uz kuru sākotnēji tika vērsts projekts mypy. Alore sintakse atvieglo problēmu risināŔanu ar cikliskām importÄ“Å”anas komandām. MÅ«sdienu mypy ir mantojis dažus ierobežojumus no tās agrākās, vienkārŔās ievieÅ”anas (kas bija lieliski piemērota Alore). Python apgrÅ«tina darbu ar apļveida importÄ“Å”anu, galvenokārt tāpēc, ka izteiksmes ir neskaidras. Piemēram, pieŔķirÅ”anas darbÄ«ba faktiski var definēt tipa aizstājvārdu. Mypy ne vienmēr spēj noteikt Ŕādas lietas, kamēr lielākā daļa importÄ“Å”anas cilpas nav apstrādāta. Alorē tādas neskaidrÄ«bas nebija. Slikti lēmumi, kas pieņemti sistēmas izstrādes sākumposmā, programmētājam var sagādāt nepatÄ«kamu pārsteigumu daudzus gadus vēlāk.

Rezultāti: ceļŔ uz 5 miljoniem koda rindu un jauniem apvārŔņiem

Mypy projekts ir nogājis garu ceļu ā€” no agrÄ«niem prototipiem lÄ«dz sistēmai, kas kontrolē 4 miljonus ražoÅ”anas kodu veidu rindu. AttÄ«stoties mypy, Python tipa padomi tika standartizēti. MÅ«sdienās Python koda ievadÄ«Å”anai ir izveidojusies spēcÄ«ga ekosistēma. Tajā ir vieta bibliotēku atbalstam, tajā ir IDE un redaktoru palÄ«grÄ«ki, ir vairākas tipa vadÄ«bas sistēmas, no kurām katrai ir savi plusi un mÄ«nusi.

Lai gan Dropbox tipa pārbaude jau ir noteikta, es uzskatu, ka mēs joprojām esam Python koda ievadÄ«Å”anas sākumā. Es domāju, ka tipa pārbaudes tehnoloÄ£ijas turpinās attÄ«stÄ«ties un uzlaboties.

Ja savā lielapjoma Python projektā vēl neesat izmantojis tipa pārbaudi, ziniet, ka tagad ir ļoti piemērots brÄ«dis, lai sāktu pāriet uz statisko rakstÄ«Å”anu. Esmu runājis ar tiem, kuri ir veikuÅ”i lÄ«dzÄ«gu pāreju. Neviens no viņiem to nenožēloja. Tipa pārbaude padara Python par valodu, kas ir daudz labāk piemērota lielu projektu izstrādei nekā ā€œparastais Pythonā€.

Cienījamie lasītāji! Vai savos Python projektos izmantojat tipa pārbaudi?

CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa
CeļŔ uz tipa pārbaudi 4 miljonos Python koda rindiņu. 3. daļa

Avots: www.habr.com

Pievieno komentāru