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

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

Dropbox ბევრს წერს პითონში. ეს არის ენა, რომელსაც ჩვენ ვიყენებთ უკიდურესად ფართოდ - როგორც backend სერვისებისთვის, ასევე დესკტოპის კლიენტის აპლიკაციებისთვის. ჩვენ ასევე ბევრს ვიყენებთ Go, TypeScript და Rust, მაგრამ Python არის ჩვენი მთავარი ენა. ჩვენი მასშტაბის გათვალისწინებით და ჩვენ ვსაუბრობთ პითონის კოდის მილიონობით ხაზზე, აღმოჩნდა, რომ ასეთი კოდის დინამიურმა აკრეფამ ზედმეტად გაართულა მისი გაგება და დაიწყო სერიოზული გავლენა შრომის პროდუქტიულობაზე. ამ პრობლემის შესამსუბუქებლად, ჩვენ დავიწყეთ ჩვენი კოდის თანდათანობით გადაყვანა სტატიკური ტიპის შემოწმებაზე mypy-ის გამოყენებით. ეს არის ალბათ ყველაზე პოპულარული დამოუკიდებელი ტიპის შემოწმების სისტემა პითონისთვის. Mypy არის ღია კოდის პროექტი, მისი მთავარი დეველოპერები მუშაობენ Dropbox-ში.

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

→ წაიკითხეთ მეორე ნაწილი

რატომ არის საჭირო ტიპის შემოწმება?

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

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

• შეუძლია თუ არა ამ ფუნქციის დაბრუნება None?
• რა უნდა იყოს ეს არგუმენტი? items?
• რა არის ატრიბუტის ტიპი id: int ეს არის, str, ან იქნებ რაიმე სახის?
• უნდა იყოს ეს არგუმენტი სია? შესაძლებელია თუ არა მასში ტუპლის გადატანა?

თუ გადახედავთ შემდეგ ტიპის ანოტირებულ კოდის ნაწყვეტს და ცდილობთ უპასუხოთ მსგავს კითხვებს, აღმოჩნდება, რომ ეს მარტივი ამოცანაა:

class Resource:
    id: bytes
    ...
    def read_metadata(self, 
                      items: Sequence[str]) -> Dict[str, MetadataItem]:
        ...

• read_metadata არ ბრუნდება Noneრადგან დაბრუნების ტიპი არ არის Optional[…].
• კამათი items არის ხაზების თანმიმდევრობა. არ შეიძლება მისი გამეორება ნებისმიერი თანმიმდევრობით.
• ატრიბუტი id არის ბაიტების სტრიქონი.

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

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

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

ასეთი სისტემების გამოყენებას სხვა უპირატესობები აქვს და ისინი სრულიად არატრივიალურია:

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

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

Mypy ფონი

Mypy ისტორია დაიწყო დიდ ბრიტანეთში, კემბრიჯში, რამდენიმე წლით ადრე, სანამ Dropbox-ს შევუერთდებოდი. სადოქტორო კვლევის ფარგლებში ვმუშაობდი სტატიკურად აკრეფილი და დინამიური ენების გაერთიანების საკითხზე. მე შთაგონებული ვიყავი ჯერემი სიეკის და ვალიდ ტაჰის სტატიით ეტაპობრივი აკრეფის შესახებ, ასევე Typed Racket პროექტით. მე ვცდილობდი მეპოვა გზები, რომ გამომეყენებინა ერთი და იგივე პროგრამირების ენა სხვადასხვა პროექტებისთვის - პატარა სკრიპტებიდან დაწყებული, მრავალი მილიონი სტრიქონისგან შემდგარი კოდების ბაზებით. ამავდროულად, მინდოდა დავრწმუნებულიყავი, რომ ნებისმიერი მასშტაბის პროექტში არ მომიწევს ძალიან ბევრი კომპრომისის წასვლა. ამ ყველაფრის მნიშვნელოვანი ნაწილი იყო იდეა ეტაპობრივად გადასულიყო არატიპური პროტოტიპიდან სრულყოფილად შემოწმებულ, სტატიკურად აკრეფილ მზა პროდუქტზე. ეს იდეები დღესდღეობით ძირითადად მიჩნეულია, მაგრამ 2010 წელს ეს იყო საკითხი, რომელიც ჯერ კიდევ აქტიურად იკვლევდა.

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

def Fib(n as Int) as Int
  if n <= 1
    return n
  else
    return Fib(n - 1) + Fib(n - 2)
  end
end

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

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

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

ჯავისა და პითონის ნარევს ჰგავდა:

int fib(int n):
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

იმ დროს ჩემი ერთ-ერთი იდეა იყო ტიპის ანოტაციების გამოყენება მუშაობის გასაუმჯობესებლად პითონის ამ არომატის C-ში, ან შესაძლოა JVM ბაიტიკოდში შედგენით. პროტოტიპის შემდგენელის დაწერის ეტაპამდე მივედი, მაგრამ ეს იდეა მივატოვე, რადგან თავად ტიპის შემოწმება საკმაოდ სასარგებლო ჩანდა.

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

def fib(n: int) -> int:
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

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

products = []  # type: List[str]  # Eww

აკრიფეთ კომენტარები ასევე სასარგებლოა Python 2-ის მხარდასაჭერად, რომელსაც არ აქვს ჩაშენებული მხარდაჭერა ტიპის ანოტაციებისთვის:

f fib(n):
    # type: (int) -> int
    if n <= 1:
        return n
    else:
        return fib(n - 1) + fib(n - 2)

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

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

გაგრძელება იქნება ...

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

წყარო: www.habr.com