Ni prezentas al via atento la trian parton de la traduko de materialo pri la vojo, kiun Dropbox prenis dum efektivigo de tipkontrolsistemo por Python-kodo.
→ Antaŭaj partoj: и
Atingante 4 milionojn da linioj de tajpita kodo
Alia grava defio (kaj la dua plej ofta zorgo inter tiuj enketitaj interne) estis pliigi la kvanton de kodo kovrita per tipkontroloj en Dropbox. Ni provis plurajn alirojn por solvi ĉi tiun problemon, de nature kreskigi la grandecon de la tajpita kodbazo ĝis koncentri la klopodojn de la mypy-teamo sur statika kaj dinamika aŭtomatigita tipa inferenco. En la fino, ŝajnis, ke ne ekzistas simpla gajna strategio, sed ni povis atingi rapidan kreskon de la volumo de komentita kodo kombinante multajn alirojn.
Kiel rezulto, nia plej granda Python-deponejo (kun backend-kodo) havas preskaŭ 4 milionojn da linioj de komentita kodo. La laboro pri senmova kodtajpado estis kompletigita en proksimume tri jaroj. Mypy nun subtenas diversajn specojn de kodaj raportoj, kiuj faciligas kontroli la progreson de tajpado. Aparte, ni povas generi raportojn pri kodo kun ambiguecoj en tipoj, kiel ekzemple eksplicita uzo de tipo. Any en komentarioj, kiuj ne povas esti kontrolitaj, aŭ kun aferoj kiel importado de triaj bibliotekoj, kiuj ne havas tipajn komentadojn. Kiel parto de projekto por plibonigi la precizecon de tipo-kontrolado en Dropbox, ni kontribuis al plibonigo de la tipdifinoj (tiel nomataj stumbdosieroj) por iuj popularaj malfermkodaj bibliotekoj en centralizita Python-deponejo. .
Ni efektivigis (kaj normigis en postaj PEPs) novajn funkciojn de la tipsistemo, kiuj permesas pli precizajn tipojn por iuj specifaj Python-ŝablonoj. Rimarkinda ekzemplo de tio estas TypeDict, kiu provizas tipojn por JSON-similaj vortaroj kiuj havas fiksan aron de ŝnuroj, ĉiu kun valoro de sia propra tipo. Ni daŭre vastigos la tipsistemon. Nia sekva paŝo verŝajne estos plibonigi subtenon por la nombraj kapabloj de Python.
Nombro de linioj de komentita kodo: servilo
Nombro de linioj de komentita kodo: kliento
Suma nombro da linioj de komentita kodo
Jen superrigardo de la ĉefaj trajtoj de la aferoj, kiujn ni faris por pliigi la kvanton de komentita kodo en Dropbox:
Rigoreco de komentario. Ni iom post iom pliigis la postulojn por la rigoro de komentado de nova kodo. Ni komencis kun linter-konsiletoj, kiuj sugestis aldoni komentadojn al dosieroj, kiuj jam havis kelkajn komentadojn. Ni nun postulas tipajn komentadojn en novaj Python-dosieroj kaj en la plej multaj ekzistantaj dosieroj.
Tajpaj raportoj. Ni sendas al teamoj ĉiusemajnajn raportojn pri la nivelo de tajpado de ilia kodo kaj donas konsilojn pri kio unue komentu.
Popularigo de mypy. Ni parolas pri mypy ĉe eventoj kaj parolas kun teamoj por helpi ilin komenci kun tipaj komentarioj.
Enketoj. Ni faras periodajn uzantajn enketojn por identigi gravajn problemojn. Ni estas pretaj iri sufiĉe malproksimen solvi ĉi tiujn problemojn (eĉ krei novan lingvon por akceli mypy!).
Agado. Ni multe plibonigis la agadon de mypy uzante la demonon kaj mypyc. Ĉi tio estis farita por mildigi la malkomfortojn kiuj aperas dum la komentadprocezo, kaj por povi labori kun grandaj kvantoj da kodo.
Integriĝo kun redaktoroj. Ni konstruis ilojn por subteni ruladon de mypy en redaktiloj, kiuj estas popularaj ĉe Dropbox. Ĉi tio inkluzivas PyCharm, Vim kaj VS Code. Ĉi tio multe simpligis la procezon de komentado de la kodo kaj kontrolado de ĝia funkcieco. Ĉi tiuj specoj de agoj estas oftaj dum komentado de ekzistanta kodo.
Statika analizo. Ni kreis ilon por konkludi funkciojn per senmovaj analiziloj. Ĉi tiu ilo povas funkcii nur en relative simplaj situacioj, sed ĝi helpis nin pliigi nian kodspecan kovradon sen multe da peno.
Subteno por triaj bibliotekoj. Multaj el niaj projektoj uzas la ilaron SQLAlchemy. Ĝi utiligas la dinamikajn kapablojn de Python, kiujn PEP 484-tipoj ne kapablas modeli rekte. Ni, laŭ PEP 561, kreis la respondan stumbdosieron kaj skribis kromprogramon por mypy (), kiu plibonigas SQLAlchemy-subtenon.
Malfacilaĵoj, kiujn ni renkontis
La vojo al 4 milionoj da linioj de tajpita kodo ne ĉiam estis facila por ni. Sur ĉi tiu vojo ni renkontis multajn truojn kaj faris plurajn erarojn. Ĉi tiuj estas kelkaj el la problemoj, kiujn ni renkontis. Ni esperas, ke rakonti pri ili helpos aliajn eviti similajn problemojn.
Mankas dosieroj. Ni komencis nian laboron kontrolante nur malgrandan kvanton da dosieroj. Io ajn ne inkluzivita en ĉi tiuj dosieroj ne estis kontrolita. Dosieroj estis aldonitaj al la skana listo kiam la unuaj komentarioj aperis en ili. Se io estis importita de modulo situanta ekster la amplekso de konfirmo, tiam ni parolis pri labori kun valoroj kiel Any, kiuj tute ne estis provitaj. Tio kaŭzis signifan perdon de tajpa precizeco, precipe en la fruaj stadioj de migrado. Ĉi tiu aliro funkciis surprize bone ĝis nun, kvankam tipa situacio estas, ke aldoni dosierojn al la amplekso de la revizio malkaŝas problemojn en aliaj partoj de la kodbazo. En la plej malbona kazo, kiam du izolitaj areoj de kodo estis kunfanditaj, en kiuj, sendepende unu de la alia, la tipoj jam estis kontrolitaj, montriĝis, ke la tipoj de ĉi tiuj areoj estis malkongruaj unu kun la alia. Ĉi tio kondukis al la bezono fari multajn ŝanĝojn al la komentarioj. Rerigardante nun, ni rimarkas, ke ni devus aldoni kernbibliotekaj moduloj al la tipkontrola areo de mypy pli frue. Ĉi tio farus nian laboron multe pli antaŭvidebla.
Komentante malnovan kodon. Kiam ni komencis, ni havis ĉirkaŭ 4 milionojn da linioj de ekzistanta Python-kodo. Estis klare, ke komenti ĉi tiun tutan kodon ne estis facila tasko. Ni kreis ilon nomatan PyAnnotate, kiu povas kolekti tipajn informojn dum testoj funkcias kaj povas aldoni tipajn komentadojn al via kodo surbaze de la kolektitaj informoj. Tamen ni ne rimarkis precipe vastan adopton de ĉi tiu ilo. Kolekti tipinformojn estis malrapida, kaj aŭtomate generitaj komentarioj ofte postulis multajn manajn redaktojn. Ni pensis pri aŭtomate ruli ĉi tiun ilon ĉiufoje kiam ni revizias kodon, aŭ pri kolektado de tipinformoj surbaze de analizo de iom da malgranda volumo de realaj retaj petoj, sed decidis ne fari ĉar ambaŭ aliroj estis tro riskaj.
Kiel rezulto, oni povas rimarki, ke la plej granda parto de la kodo estis mane komentita de siaj posedantoj. Por gvidi ĉi tiun procezon en la ĝusta direkto, ni preparas raportojn pri aparte gravaj moduloj kaj funkcioj, kiuj devas esti komentitaj. Ekzemple, estas grave provizi tipkotadojn por biblioteka modulo, kiu estas uzata en centoj da lokoj. Sed malnova servo, kiu estas anstataŭigita per nova, ne plu tiom gravas komentari. Ni ankaŭ eksperimentas uzi statikan analizon por generi tipajn komentadojn por hereda kodo.
Ciklaj importoj. Supre, mi parolis pri ciklaj importadoj (la "dependecaj implikaĵoj"), kies ekzisto malfaciligis rapidigi mypy. Ni ankaŭ devis multe labori por ke mypy subtenu ĉiajn idiomojn, kiuj estas kaŭzitaj de ĉi tiuj ciklaj importadoj. Ni lastatempe kompletigis gravan sisteman restrukturan projekton, kiu riparis la plej multajn problemojn de mypy rilate cirkulajn importadojn. Ĉi tiuj problemoj fakte devenis de la tre fruaj tagoj de la projekto, reen de Alore, la eduka lingvo sur kiu la mypy projekto estis origine koncentrita. Alore-sintakso faciligas solvi problemojn kun ciklaj importkomandoj. Moderna mypy heredis kelkajn limigojn de ĝia pli frua, simplanima efektivigo (kiu estis bonega por Alore). Python malfaciligas labori kun cirklaj importadoj, ĉefe ĉar esprimoj estas ambiguaj. Ekzemple, asigno operacio povas fakte difini tipa kaŝnomo. Mypy ne ĉiam kapablas detekti tiajn aferojn ĝis la plej granda parto de la importa buklo estas prilaborita. Ne estis tiaj ambiguecoj en Alore. Malbonaj decidoj faritaj en la fruaj stadioj de sistema evoluado povas prezenti malagrablan surprizon al la programisto multajn jarojn poste.
Rezultoj: la vojo al 5 milionoj da linioj de kodo kaj novaj horizontoj
La mypy-projekto venis longan vojon - de fruaj prototipoj ĝis sistemo kiu kontrolas 4 milionojn da linioj de produktaj kodspecoj. Ĉar mypy evoluis, la tipsugestoj de Python estis normigitaj. Nuntempe, potenca ekosistemo formiĝis ĉirkaŭ tajpado de Python-kodo. Ĝi havas lokon por biblioteka subteno, ĝi enhavas helpajn ilojn por IDEoj kaj redaktiloj, ĝi havas plurajn tipajn kontrolsistemojn, ĉiu el kiuj havas siajn proprajn avantaĝojn kaj malavantaĝojn.
Kvankam tajpa kontrolo jam estas donita ĉe Dropbox, mi kredas, ke ni ankoraŭ estas en la fruaj tagoj de tajpado de Python-kodo. Mi pensas, ke tipkontrolaj teknologioj daŭre evoluos kaj pliboniĝos.
Se vi ne jam uzis tajpkontroladon en via grandskala Python-projekto, tiam sciu, ke nun estas tre bona tempo por komenci moviĝi al senmova tajpado. Mi parolis kun tiuj, kiuj faris similan transiron. Neniu el ili bedaŭris tion. Tipkontrolado faras Python lingvo kiu multe pli taŭgas por disvolvi grandajn projektojn ol "ordinara Python".
Karaj legantoj! Ĉu vi uzas tajpkontroladon en viaj Python-projektoj?
fonto: www.habr.com