Пут до провере типова 4 милиона линија Питхон кода. Део 3

Представљамо Вашој пажњи трећи део превода материјала о путу којим је Дропбок ишао приликом имплементације система за проверу типа за Питхон код.

→ Претходни делови: прво и Други

Достизање 4 милиона редова откуцаног кода

Још један велики изазов (и други најчешћи проблем међу онима који су интерно анкетирани) био је повећање количине кода покривеног провером типа у Дропбок-у. Испробали смо неколико приступа да решимо овај проблем, од природног повећања величине укуцане кодне базе до фокусирања напора мипи тима на статичко и динамичко аутоматско закључивање типа. На крају се чинило да не постоји једноставна победничка стратегија, али смо успели да постигнемо брз раст обима кода са коментарима комбиновањем многих приступа.

Као резултат тога, наше највеће Питхон спремиште (са позадинским кодом) има скоро 4 милиона линија кода са коментарима. Рад на статичком куцању кода завршен је за отприлике три године. Мипи сада подржава различите типове извештаја о покривености кода који олакшавају праћење напретка куцања. Конкретно, можемо да генеришемо извештаје о коду са нејасноћама у типовима, као што је, на пример, експлицитна употреба типа Any у напоменама које се не могу верификовати или са стварима као што је увоз библиотека трећих страна које немају напомене о типу. Као део пројекта за побољшање тачности провере типа у Дропбок-у, допринели смо побољшању дефиниција типова (тзв. стуб фајлова) за неке популарне библиотеке отвореног кода у централизованом Питхон спремишту откуцана.

Имплементирали смо (и стандардизовали у наредним ПЕП-овима) нове карактеристике система типова које омогућавају прецизније типове за неке специфичне Питхон обрасце. Значајан пример за то је TypeDict, који обезбеђује типове за речнике сличне ЈСОН-у који имају фиксни скуп стринг кључева, сваки са вредношћу сопственог типа. Наставићемо да ширимо систем типова. Наш следећи корак ће вероватно бити побољшање подршке за Питхон-ове нумеричке могућности.

Број редова означеног кода: сервер

Број редова означеног кода: клијент

Укупан број редова означеног кода

Ево прегледа главних карактеристика ствари које смо урадили да повећамо количину означеног кода у Дропбок-у:

Ригорност напомене. Постепено смо повећавали захтеве за ригорозност означавања новог кода. Почели смо са саветима за линтер који су предложили додавање напомена датотекама које већ имају неке напомене. Сада су нам потребне напомене типа у новим Питхон датотекама и у већини постојећих датотека.

Куцање извештаја. Тимовима шаљемо недељне извештаје о нивоу куцања њиховог кода и дајемо савете шта прво треба да се анотира.

Популаризација мипи. Разговарамо о мипи-ју на догађајима и разговарамо са тимовима како бисмо им помогли да почну са напоменама типа.

Анкете. Вршимо периодичне анкете корисника да бисмо идентификовали главне проблеме. Спремни смо да одемо прилично далеко у решавању ових проблема (чак и креирамо нови језик да бисмо убрзали мипи!).

Перформансе. Увелико смо побољшали перформансе мипи-ја коришћењем демона и мипиц-а. Ово је урађено да би се изгладиле непријатности које настају током процеса обележавања и да би се могао радити са великим количинама кода.

Интеграција са уредницима. Направили смо алате за подршку покретању мипи-ја у уређивачима који су популарни на Дропбок-у. Ово укључује ПиЦхарм, Вим и ВС Цоде. Ово је у великој мери поједноставило процес означавања кода и провере његове функционалности. Ове врсте радњи су уобичајене када се означава постојећи код.

Статичка анализа. Направили смо алат за закључивање потписа функција помоћу алата за статичку анализу. Овај алат може да ради само у релативно једноставним ситуацијама, али нам је помогао да повећамо покривеност типа кода без много напора.

Подршка за библиотеке трећих страна. Многи од наших пројеката користе СКЛАлцхеми алат. Користи динамичке могућности Питхон-а које типови ПЕП 484 не могу директно моделирати. Ми смо, у складу са ПЕП 561, креирали одговарајући стуб фајл и написали додатак за мипи (отвореног кода), што побољшава подршку за СКЛАлцхеми.

Потешкоће на које смо наишли

Пут до 4 милиона редова откуцаног кода није нам увек био лак. На овој стази наишли смо на много рупа и направили неколико грешака. Ово су неки од проблема на које смо наишли. Надамо се да ће причање о њима помоћи другима да избегну сличне проблеме.

Фајлови који недостају. Почели смо наш рад провером само мале количине датотека. Све што није укључено у ове датотеке није проверено. Датотеке су додате на листу за скенирање када су се у њима појавиле прве напомене. Ако је нешто увезено из модула који се налази изван обима верификације, онда смо говорили о раду са вредностима као што су Any, који уопште нису тестирани. То је довело до значајног губитка тачности куцања, посебно у раним фазама миграције. Овај приступ је до сада функционисао изненађујуће добро, иако је типична ситуација да додавање датотека у опсег прегледа открива проблеме у другим деловима кодне базе. У најгорем случају, када су спојене две изоловане области кода, у којима су, независно једна од друге, већ проверени типови, испоставило се да су типови ових области међусобно некомпатибилни. То је довело до потребе да се унесу многе измене у напомене. Гледајући сада уназад, схватамо да је требало раније да додамо модуле основне библиотеке у област за проверу типа мипи. То би наш рад учинило много предвидљивијим.

Анотирање старог кода. Када смо почели, имали смо око 4 милиона линија постојећег Питхон кода. Било је јасно да обележавање целог овог кода није био лак задатак. Направили смо алат под називом ПиАннотате који може да прикупља информације о типу док се тестови изводе и може да додаје напомене о типу вашем коду на основу прикупљених информација. Међутим, нисмо приметили посебно широко усвајање овог алата. Прикупљање информација о типу било је споро, а аутоматски генерисане напомене су често захтевале много ручних измена. Размишљали смо о аутоматском покретању ове алатке сваки пут када прегледамо код, или о прикупљању информација о типу на основу анализе малог обима стварних мрежних захтева, али смо одлучили да то не учинимо јер је оба приступа била превише ризична.

Као резултат тога, може се приметити да је већи део кода ручно обележен од стране његових власника. Да бисмо овај процес водили у правом смеру, припремамо извештаје о посебно важним модулима и функцијама које је потребно означити. На пример, важно је обезбедити напомене типа за модул библиотеке који се користи на стотинама места. Али стари сервис који се замењује новом више није толико важан за коментарисање. Такође експериментишемо са коришћењем статичке анализе за генерисање напомена типа за стари код.

Циклични увоз. Изнад сам говорио о цикличном увозу („замршености зависности“), чије постојање је отежавало убрзавање мипи-ја. Такође смо морали напорно да радимо на томе да мипи подржава све врсте идиома који су узроковани овим цикличним увозом. Недавно смо завршили велики пројекат редизајнирања система који је решио већину проблема са мипи-јем у вези са кружним увозом. Ови проблеми су заправо проистекли из раних дана пројекта, још из Алореа, образовног језика на који је пројекат мипи првобитно био фокусиран. Алоре синтакса олакшава решавање проблема са цикличним увозним командама. Савремени мипи је наследио нека ограничења од своје раније, простодушне имплементације (која је била одлична за Алоре). Питхон отежава рад са кружним увозом, углавном зато што су изрази двосмислени. На пример, операција доделе може заправо да дефинише псеудоним типа. Мипи није увек у стању да открије овакве ствари док се већина увозне петље не обради. У Алореу није било таквих нејасноћа. Лоше одлуке донете у раним фазама развоја система могу представљати непријатно изненађење за програмера много година касније.

Резултати: пут до 5 милиона линија кода и нови хоризонти

Мипи пројекат је прешао дуг пут - од раних прототипова до система који контролише 4 милиона линија типова производног кода. Како је мипи еволуирао, наговештаји типа Питхон-а су стандардизовани. Ових дана, моћан екосистем се развио око куцања Питхон кода. Има места за подршку библиотеке, садржи помоћне алате за ИДЕ и уреднике, има неколико система контроле типова, од којих сваки има своје предности и недостатке.

Иако је провера типа већ дата у Дропбок-у, верујем да смо још увек у раним данима куцања Питхон кода. Мислим да ће технологије за проверу типа наставити да се развијају и побољшавају.

Ако већ нисте користили проверу типа у свом великом Питхон пројекту, знајте да је сада веома добар тренутак да почнете да пређете на статичко куцање. Разговарао сам са онима који су направили сличну транзицију. Нико од њих није зажалио. Провера типа чини Питхон језиком који је много погоднији за развој великих пројеката од „обичног Питхона“.

Драги читаоци! Да ли користите проверу типа у својим Питхон пројектима?

Извор: ввв.хабр.цом