პითონის კოდის 4 მილიონი ხაზის აკრეფის გზა. Ნაწილი 3

თქვენს ყურადღებას წარმოგიდგენთ მასალის თარგმანის მესამე ნაწილს იმ გზის შესახებ, რომელიც Dropbox-მა გაიარა პითონის კოდისთვის ტიპის შემოწმების სისტემის დანერგვისას.

→ წინა ნაწილები: პირველი и მეორე

აკრეფილი კოდის 4 მილიონი ხაზის მიღწევა

კიდევ ერთი მთავარი გამოწვევა (და მეორე ყველაზე გავრცელებული საზრუნავი შიდა გამოკითხულთა შორის) იყო Dropbox-ში ტიპის შემოწმებით დაფარული კოდის რაოდენობის გაზრდა. ჩვენ ვცადეთ რამდენიმე მიდგომა ამ პრობლემის გადასაჭრელად, დაწყებული აკრეფილი კოდების ბაზის ზომის ბუნებრივად გაზრდიდან დაწყებული mypy გუნდის ძალისხმევის ფოკუსირებამდე სტატიკურ და დინამიურ ავტომატიზირებულ ტიპის დასკვნაზე. საბოლოო ჯამში, როგორც ჩანს, არ არსებობდა მარტივი გამარჯვების სტრატეგია, მაგრამ ჩვენ შევძელით ანოტაციური კოდის მოცულობის სწრაფი ზრდის მიღწევა მრავალი მიდგომის კომბინაციით.

შედეგად, ჩვენს უდიდეს Python-ის საცავში (backend კოდით) აქვს ანოტაციური კოდის თითქმის 4 მილიონი ხაზი. სტატიკური კოდის აკრეფაზე მუშაობა დაახლოებით სამ წელიწადში დასრულდა. Mypy ახლა მხარს უჭერს სხვადასხვა ტიპის კოდის დაფარვის ანგარიშებს, რაც აადვილებს აკრეფის პროგრესის მონიტორინგს. კერძოდ, ჩვენ შეგვიძლია შევქმნათ ანგარიშები კოდის შესახებ გაურკვევლობის ტიპებში, როგორიცაა, მაგალითად, ტიპის აშკარა გამოყენება. Any ანოტაციებში, რომელთა გადამოწმება შეუძლებელია, ან ისეთი რამ, როგორიცაა მესამე მხარის ბიბლიოთეკების იმპორტი, რომლებსაც არ აქვთ ტიპის ანოტაციები. როგორც Dropbox-ში ტიპის შემოწმების სიზუსტის გაუმჯობესების პროექტის ნაწილი, ჩვენ წვლილი შევიტანეთ პითონის ცენტრალიზებულ საცავში ზოგიერთი პოპულარული ღია კოდის ბიბლიოთეკისთვის ტიპების განმარტებების (ე.წ. stub ფაილების) გაუმჯობესებაში. აკრეფილი.

ჩვენ განვახორციელეთ (და სტანდარტიზებული იქნა მომდევნო PEP-ებში) ტიპის სისტემის ახალი ფუნქციები, რომლებიც უფრო ზუსტი ტიპების საშუალებას იძლევა ზოგიერთი კონკრეტული პითონის შაბლონისთვის. ამის თვალსაჩინო მაგალითია TypeDict, რომელიც გთავაზობთ ტიპებს JSON-ის მსგავსი ლექსიკონებისთვის, რომლებსაც აქვთ სტრიქონების ღილაკების ფიქსირებული ნაკრები, თითოეულს თავისი ტიპის მნიშვნელობით. ჩვენ გავაგრძელებთ ტიპის სისტემის გაფართოებას. ჩვენი შემდეგი ნაბიჯი სავარაუდოდ იქნება პითონის რიცხვითი შესაძლებლობების მხარდაჭერის გაუმჯობესება.

ანოტირებული კოდის ხაზების რაოდენობა: სერვერი

ანოტირებული კოდის ხაზების რაოდენობა: კლიენტი

ანოტირებული კოდის სტრიქონების საერთო რაოდენობა

აქ მოცემულია ძირითადი მახასიათებლების მიმოხილვა, რაც ჩვენ გავაკეთეთ Dropbox-ში ანოტირებული კოდის რაოდენობის გასაზრდელად:

ანოტაციის სიმკაცრე. ჩვენ თანდათან გავზარდეთ მოთხოვნები ახალი კოდის ანოტაციის სიმკაცრის მიმართ. ჩვენ დავიწყეთ ლინტერის რჩევებით, რომლებიც გვთავაზობდა ანოტაციების დამატებას იმ ფაილებზე, რომლებსაც უკვე ჰქონდათ გარკვეული ანოტაციები. ახლა ჩვენ გვჭირდება ტიპის ანოტაციები პითონის ახალ ფაილებში და არსებულ ფაილებში.

აკრეფის ანგარიშები. ჩვენ ვუგზავნით გუნდებს ყოველკვირეულ ანგარიშებს მათი კოდის აკრეფის დონის შესახებ და ვაძლევთ რჩევებს იმის შესახებ, თუ რა უნდა იყოს პირველი ანოტაცია.

mypy-ის პოპულარიზაცია. ჩვენ ვსაუბრობთ mypy-ზე ღონისძიებებზე და ვესაუბრებით გუნდებს, რათა დავეხმაროთ მათ ტიპის ანოტაციების დაწყებაში.

გამოკითხვები. ჩვენ ვატარებთ მომხმარებელთა პერიოდულ გამოკითხვებს ძირითადი პრობლემების გამოსავლენად. ჩვენ მზად ვართ საკმაოდ შორს წავიდეთ ამ პრობლემების გადაჭრაში (თუნდაც შევქმნათ ახალი ენა mypy-ის დასაჩქარებლად!).

Შესრულება. ჩვენ მნიშვნელოვნად გავაუმჯობესეთ mypy-ის შესრულება დემონისა და mypyc-ის გამოყენებით. ეს გაკეთდა იმ უხერხულობის აღმოსაფხვრელად, რომლებიც წარმოიქმნება ანოტაციის პროცესში და იმისთვის, რომ შეგვეძლოს დიდი რაოდენობით კოდთან მუშაობა.

ინტეგრაცია რედაქტორებთან. ჩვენ შევქმენით ინსტრუმენტები, რომლებიც ხელს უწყობენ mypy-ის გაშვებას Dropbox-ში პოპულარულ რედაქტორებში. ეს მოიცავს PyCharm, Vim და VS კოდს. ამან მნიშვნელოვნად გაამარტივა კოდის ანოტაციის პროცესი და მისი ფუნქციონირების შემოწმება. ამ ტიპის მოქმედებები ხშირია არსებული კოდის ანოტაციისას.

სტატიკური ანალიზი. ჩვენ შევქმენით ინსტრუმენტი ფუნქციის ხელმოწერების დასადგენად სტატიკური ანალიზის ხელსაწყოების გამოყენებით. ამ ხელსაწყოს შეუძლია მუშაობა მხოლოდ შედარებით მარტივ სიტუაციებში, მაგრამ დაგვეხმარა გავზარდოთ ჩვენი კოდის ტიპის დაფარვა დიდი ძალისხმევის გარეშე.

მესამე მხარის ბიბლიოთეკების მხარდაჭერა. ჩვენი ბევრი პროექტი იყენებს SQLAlchemy ინსტრუმენტარიუმს. ის იყენებს პითონის დინამიურ შესაძლებლობებს, რომ PEP 484 ტიპებს არ შეუძლიათ პირდაპირ მოდელირება. ჩვენ, PEP 561-ის შესაბამისად, შევქმენით შესაბამისი stub ფაილი და დავწერეთ დანამატი mypy-სთვის (საჯარო წყარო), რომელიც აუმჯობესებს SQLAlchemy მხარდაჭერას.

სირთულეები, რომლებიც შეგვხვდა

აკრეფილი კოდის 4 მილიონი ხაზის გზა ჩვენთვის ყოველთვის ადვილი არ ყოფილა. ამ გზაზე ბევრი ხვრელი შეგვხვდა და რამდენიმე შეცდომა დავუშვით. ეს არის რამდენიმე პრობლემა, რომელიც ჩვენ შეგვხვდა. ვიმედოვნებთ, რომ მათ შესახებ საუბარი სხვებს დაეხმარება მსგავსი პრობლემების თავიდან აცილებაში.

ფაილები აკლია. ჩვენ დავიწყეთ მუშაობა მხოლოდ მცირე რაოდენობის ფაილების შემოწმებით. ყველაფერი, რაც არ შედის ამ ფაილებში, არ შემოწმდა. ფაილები დაემატა სკანირების სიას, როდესაც მათში პირველი ანოტაციები გამოჩნდა. თუ რამე იმპორტირებული იყო მოდულიდან, რომელიც მდებარეობს ვერიფიკაციის ფარგლებს გარეთ, მაშინ ჩვენ ვსაუბრობდით მნიშვნელობებთან მუშაობაზე, როგორიცაა Any, რომლებიც საერთოდ არ იყო გამოცდილი. ამან გამოიწვია აკრეფის სიზუსტის მნიშვნელოვანი დაკარგვა, განსაკუთრებით მიგრაციის ადრეულ ეტაპებზე. ეს მიდგომა აქამდე საოცრად კარგად მუშაობდა, თუმცა ტიპიური სიტუაციაა, რომ ფაილების მიმოხილვის ფარგლებს დაემატება პრობლემები კოდის ბაზის სხვა ნაწილებში. უარეს შემთხვევაში, როდესაც გაერთიანდა კოდის ორი იზოლირებული უბანი, რომლებშიც, ერთმანეთისგან დამოუკიდებლად, უკვე შემოწმდა ტიპები, აღმოჩნდა, რომ ამ უბნების ტიპები შეუთავსებელი იყო ერთმანეთთან. ამან გამოიწვია ანოტაციებში მრავალი ცვლილების შეტანის აუცილებლობა. ახლა რომ ვიხსენებთ, მივხვდებით, რომ უფრო ადრე უნდა დაგვემატებინა ბიბლიოთეკის ძირითადი მოდულები mypy-ის ტიპის შემოწმების ზონაში. ეს ჩვენს მუშაობას ბევრად უფრო პროგნოზირებადს გახდის.

ძველი კოდის ანოტაცია. როდესაც დავიწყეთ, გვქონდა დაახლოებით 4 მილიონი ხაზი არსებული პითონის კოდი. ცხადი იყო, რომ ამ ყველა კოდის ანოტირება ადვილი საქმე არ იყო. ჩვენ შევქმენით ინსტრუმენტი სახელწოდებით PyAnnotate, რომელსაც შეუძლია შეაგროვოს ტიპის ინფორმაცია ტესტების გაშვებისას და შეუძლია დაამატოთ ტიპის ანოტაციები თქვენს კოდში შეგროვებული ინფორმაციის საფუძველზე. თუმცა, ჩვენ ვერ შევამჩნიეთ ამ ინსტრუმენტის განსაკუთრებით ფართო გამოყენება. ტიპის ინფორმაციის შეგროვება ნელი იყო და ავტომატურად გენერირებული ანოტაციები ხშირად საჭიროებდა ბევრ ხელით რედაქტირებას. ჩვენ ვფიქრობდით ამ ხელსაწყოს ავტომატურად გაშვებაზე ყოველ ჯერზე, როცა კოდს განვიხილავთ, ან შეგვეგროვებინა ტიპის ინფორმაცია ფაქტობრივი ქსელის მოთხოვნების ზოგიერთი მცირე მოცულობის ანალიზის საფუძველზე, მაგრამ გადავწყვიტეთ, რომ არ გაგვეკეთებინა, რადგან ორივე მიდგომა ძალიან სარისკო იყო.

შედეგად, შეიძლება აღინიშნოს, რომ კოდის უმეტესი ნაწილი ხელით იყო ანოტირებული მისი მფლობელების მიერ. ამ პროცესის სწორი მიმართულებით წარმართვის მიზნით, ჩვენ ვამზადებთ ანგარიშებს განსაკუთრებით მნიშვნელოვან მოდულებსა და ფუნქციებზე, რომლებიც საჭიროებს ანოტაციას. მაგალითად, მნიშვნელოვანია ტიპის ანოტაციების მიწოდება ბიბლიოთეკის მოდულისთვის, რომელიც გამოიყენება ასობით ადგილას. მაგრამ ძველი სერვისი, რომელიც იცვლება ახლით, აღარ არის ისეთი მნიშვნელოვანი ანოტაციისთვის. ჩვენ ასევე ვცდილობთ სტატიკური ანალიზის გამოყენებას ძველი კოდისთვის ტიპის ანოტაციების შესაქმნელად.

ციკლური იმპორტი. ზემოთ მე ვისაუბრე ციკლურ იმპორტზე („დამოკიდებულების აურზაური“), რომლის არსებობამ გაართულა mypy-ის დაჩქარება. ჩვენ ასევე მოგვიწია დიდი შრომა, რათა mypy-მ მხარი დაუჭიროს ყველა სახის იდიომს, რომელიც გამოწვეულია ამ ციკლური იმპორტით. ჩვენ ახლახან დავასრულეთ სისტემის რედიზაინის მთავარი პროექტი, რომელმაც დააფიქსირა mypy-ის პრობლემების უმეტესი ნაწილი წრიულ იმპორტთან დაკავშირებით. ეს პრობლემები რეალურად წარმოიშვა პროექტის პირველივე დღეებიდან, დაბრუნებული Alore-დან, საგანმანათლებლო ენიდან, რომელზეც თავდაპირველად იყო ორიენტირებული mypy პროექტი. Alore სინტაქსი აადვილებს პრობლემების გადაჭრას ციკლური იმპორტის ბრძანებებით. თანამედროვე mypy-მ მემკვიდრეობით მიიღო გარკვეული შეზღუდვები მისი ადრინდელი, მარტივი განხორციელებისგან (რაც მშვენივრად შეეფერებოდა Alore-ს). პითონი ართულებს წრიულ იმპორტთან მუშაობას, ძირითადად იმიტომ, რომ გამონათქვამები ორაზროვანია. მაგალითად, დავალების ოპერაციამ შეიძლება რეალურად განსაზღვროს ტიპის ალიასი. Mypy ყოველთვის ვერ ახერხებს მსგავსი რამის ამოცნობას, სანამ იმპორტის ციკლის უმეტესი ნაწილი არ დამუშავდება. ალორეში ასეთი გაურკვევლობა არ იყო. სისტემის განვითარების ადრეულ ეტაპებზე მიღებულმა ცუდი გადაწყვეტილებები შეიძლება მრავალი წლის შემდეგ უსიამოვნო სიურპრიზი იყოს პროგრამისტისთვის.

შედეგები: გზა 5 მილიონი კოდის ხაზისა და ახალი ჰორიზონტებისკენ

mypy პროექტმა გრძელი გზა გაიარა - ადრეული პროტოტიპებიდან სისტემამდე, რომელიც აკონტროლებს საწარმოო კოდის ტიპების 4 მილიონ ხაზს. როგორც mypy განვითარდა, პითონის ტიპის მინიშნებები სტანდარტიზებული იყო. ამ დღეებში ძლიერი ეკოსისტემა განვითარდა პითონის კოდის აკრეფის გარშემო. მას აქვს ადგილი ბიბლიოთეკის მხარდაჭერისთვის, შეიცავს დამხმარე ინსტრუმენტებს IDE-ებისთვის და რედაქტორებისთვის, აქვს რამდენიმე ტიპის კონტროლის სისტემა, რომელთაგან თითოეულს აქვს თავისი დადებითი და უარყოფითი მხარეები.

მიუხედავად იმისა, რომ ტიპების შემოწმება უკვე მოცემულია Dropbox-ში, მე მჯერა, რომ ჯერ კიდევ პითონის კოდის აკრეფის პირველ დღეებში ვართ. ვფიქრობ, ტიპის შემოწმების ტექნოლოგიები გაგრძელდება განვითარებასა და გაუმჯობესებაში.

თუ თქვენ ჯერ არ გამოგიყენებიათ ტიპის შემოწმება თქვენს ფართომასშტაბიან Python პროექტში, მაშინ იცოდეთ, რომ ახლა ძალიან კარგი დროა სტატიკური აკრეფის დასაწყებად. მე ვესაუბრე მათ, ვინც მსგავსი გადასვლები განხორციელდა. არცერთ მათგანს არ ნანობდა. ტიპების შემოწმება პითონს აქცევს ენას, რომელიც ბევრად უფრო შესაფერისია დიდი პროექტების შემუშავებისთვის, ვიდრე „ჩვეულებრივი პითონი“.

ძვირფასო მკითხველს! იყენებთ თუ არა ტიპის შემოწმებას თქვენს პითონის პროექტებში?

წყარო: www.habr.com