ما بخش سوم ترجمه مطالب را در مورد مسیری که دراپ باکس هنگام پیاده سازی یک سیستم بررسی نوع برای کد پایتون طی کرد، به شما ارائه می کنیم.
← قسمت های قبلی: и
رسیدن به 4 میلیون خط کد تایپ شده
یکی دیگر از چالش های اصلی (و دومین نگرانی رایج در میان کسانی که در داخل مورد بررسی قرار گرفتند) افزایش مقدار کد تحت پوشش بررسی نوع در Dropbox بود. ما چندین رویکرد را برای حل این مشکل امتحان کرده‌ایم، از رشد طبیعی اندازه پایگاه کد تایپ‌شده تا تمرکز تلاش‌های تیم mypy بر استنتاج نوع خودکار استاتیک و پویا. در پایان، به نظر می رسید که هیچ استراتژی ساده ای برای برنده شدن وجود ندارد، اما ما توانستیم با ترکیب بسیاری از رویکردها، به رشد سریع در حجم کدهای حاشیه نویسی دست یابیم.
در نتیجه، بزرگترین مخزن پایتون ما (با کد پشتیبان) نزدیک به 4 میلیون خط کد مشروح دارد. کار روی تایپ کد ایستا در حدود سه سال تکمیل شد. اکنون Mypy از انواع گزارش های پوشش کد پشتیبانی می کند که نظارت بر پیشرفت تایپ را آسان تر می کند. به طور خاص، می‌توانیم گزارش‌هایی درباره کد با ابهامات در انواع، مانند استفاده صریح از یک نوع تولید کنیم. Any در حاشیه نویسی هایی که قابل تأیید نیستند، یا با مواردی مانند وارد کردن کتابخانه های شخص ثالث که حاشیه نویسی نوع ندارند. به عنوان بخشی از پروژه ای برای بهبود دقت بررسی نوع در Dropbox، ما به بهبود تعاریف نوع (به اصطلاح فایل های خرد) برای برخی از کتابخانه های منبع باز محبوب در یک مخزن مرکزی پایتون کمک کردیم. .
ما ویژگی‌های جدید سیستم نوع را پیاده‌سازی کردیم (و در PEPهای بعدی استانداردسازی کردیم) که انواع دقیق‌تر را برای برخی از الگوهای پایتون خاص امکان‌پذیر می‌سازد. یک مثال قابل توجه در این مورد است TypeDict، که انواعی را برای دیکشنری های JSON مانند ارائه می دهد که دارای مجموعه ای ثابت از کلیدهای رشته ای هستند که هر کدام دارای مقداری از نوع خاص خود هستند. ما به گسترش سیستم نوع ادامه خواهیم داد. قدم بعدی ما احتمالاً بهبود پشتیبانی از قابلیت‌های عددی پایتون خواهد بود.
تعداد خطوط کد مشروح: سرور
تعداد خطوط کد مشروح: مشتری
تعداد کل خطوط کد مشروح
در اینجا مروری بر ویژگی‌های اصلی کارهایی است که برای افزایش میزان کدهای حاشیه‌نویسی در Dropbox انجام دادیم:
دقت حاشیه نویسی ما به تدریج الزامات مربوط به حاشیه نویسی کد جدید را افزایش دادیم. ما با نکاتی شروع کردیم که پیشنهاد می‌کردند حاشیه‌نویسی را به فایل‌هایی که قبلاً دارای حاشیه‌نویسی بودند اضافه کنید. ما اکنون به یادداشت‌های نوع در فایل‌های پایتون جدید و در اکثر فایل‌های موجود نیاز داریم.
تایپ گزارش ها ما گزارش‌های هفتگی تیم‌ها را در مورد سطح تایپ کد آنها ارسال می‌کنیم و در مورد آنچه که باید ابتدا حاشیه‌نویسی شود، توصیه می‌کنیم.
رواج mypy. ما در مورد mypy در رویدادها صحبت می کنیم و با تیم ها صحبت می کنیم تا به آنها کمک کنیم تا با حاشیه نویسی تایپ شروع کنند.
نظرسنجی ها ما نظرسنجی های دوره ای از کاربران را برای شناسایی مشکلات عمده انجام می دهیم. ما آماده ایم تا در حل این مشکلات بسیار دور برویم (حتی ایجاد یک زبان جدید برای سرعت بخشیدن به mypy!).
کارایی. ما با استفاده از daemon و mypyc عملکرد mypy را بسیار بهبود بخشیده ایم. این کار برای رفع ناراحتی هایی که در طول فرآیند حاشیه نویسی ایجاد می شود و برای اینکه بتوانیم با مقادیر زیادی کد کار کنیم، انجام شد.
ادغام با ویراستاران ما ابزارهایی برای پشتیبانی از اجرای mypy در ویرایشگرهایی که در Dropbox محبوب هستند ساخته ایم. این شامل PyCharm، Vim و VS Code است. این فرآیند حاشیه نویسی کد و بررسی عملکرد آن را بسیار ساده کرد. این نوع اقدامات هنگام حاشیه نویسی کد موجود رایج هستند.
تجزیه و تحلیل استاتیک. ما ابزاری برای استنباط امضای تابع با استفاده از ابزارهای تحلیل استاتیک ایجاد کردیم. این ابزار فقط در شرایط نسبتاً ساده می تواند کار کند، اما به ما کمک کرد پوشش نوع کد خود را بدون تلاش زیاد افزایش دهیم.
پشتیبانی از کتابخانه های شخص ثالث بسیاری از پروژه های ما از جعبه ابزار SQLAlchemy استفاده می کنند. از قابلیت‌های دینامیکی پایتون استفاده می‌کند که انواع PEP 484 قادر به مدل‌سازی مستقیم آن نیستند. ما مطابق با PEP 561، فایل خرد مربوطه را ایجاد کردیم و یک افزونه برای mypy نوشتیم () که پشتیبانی SQLAlchemy را بهبود می بخشد.
مشکلاتی که با آن مواجه شدیم
مسیر رسیدن به 4 میلیون خط کد تایپ شده همیشه برای ما آسان نبوده است. در این مسیر با چاله های زیادی مواجه شدیم و چندین اشتباه مرتکب شدیم. اینها برخی از مشکلاتی است که ما با آن مواجه شدیم. ما امیدواریم که گفتن در مورد آنها به دیگران کمک کند تا از مشکلات مشابه جلوگیری کنند.
فایل های از دست رفته ما کار خود را با بررسی تعداد کمی از فایل ها شروع کردیم. هر چیزی که در این فایل ها گنجانده نشده بود بررسی نشد. هنگامی که اولین حاشیه نویسی در آنها ظاهر شد، فایل ها به لیست اسکن اضافه شدند. اگر چیزی از یک ماژول خارج از محدوده تأیید وارد شده باشد، در این صورت ما در مورد کار با مقادیری مانند Any، که اصلا تست نشدند. این امر منجر به کاهش قابل توجه دقت تایپ، به ویژه در مراحل اولیه مهاجرت شد. این رویکرد تاکنون به طرز شگفت‌آوری خوب کار کرده است، اگرچه یک وضعیت معمولی این است که افزودن فایل‌ها به محدوده بررسی مشکلاتی را در بخش‌های دیگر پایگاه کد آشکار می‌کند. در بدترین حالت، هنگامی که دو ناحیه ایزوله کد ادغام شدند، که در آنها، به طور مستقل از یکدیگر، انواع قبلاً بررسی شده بودند، مشخص شد که انواع این مناطق با یکدیگر ناسازگار هستند. این امر منجر به نیاز به ایجاد تغییرات زیادی در حاشیه نویسی شد. اکنون که به گذشته نگاه می کنیم، متوجه می شویم که باید ماژول های کتابخانه اصلی را زودتر به منطقه بررسی نوع mypy اضافه می کردیم. این کار ما را بسیار قابل پیش بینی تر می کند.
حاشیه نویسی کدهای قدیمی وقتی شروع کردیم، حدود 4 میلیون خط کد پایتون موجود داشتیم. واضح بود که حاشیه نویسی این همه کد کار آسانی نیست. ما ابزاری به نام PyAnnotate ایجاد کرده‌ایم که می‌تواند اطلاعات نوع را در حین انجام آزمایش جمع‌آوری کند و بر اساس اطلاعات جمع‌آوری‌شده، یادداشت‌های نوع را به کد شما اضافه کند. با این حال، ما متوجه پذیرش گسترده ای از این ابزار نشده ایم. جمع‌آوری اطلاعات نوع آهسته بود و حاشیه‌نویسی‌هایی که به‌طور خودکار تولید می‌شدند اغلب به ویرایش‌های دستی زیادی نیاز داشتند. هر بار که کد را بررسی می‌کنیم یا اطلاعات نوع را بر اساس تجزیه و تحلیل حجم کمی از درخواست‌های شبکه جمع‌آوری می‌کنیم، به این فکر می‌کردیم که این ابزار را به طور خودکار اجرا کنیم، اما تصمیم گرفتیم این کار را نکنیم زیرا هر دو روش بسیار خطرناک بود.
در نتیجه، می توان اشاره کرد که اکثر کدها به صورت دستی توسط صاحبان آن حاشیه نویسی شده است. به منظور هدایت این فرآیند در جهت درست، ما گزارش هایی را در مورد ماژول ها و عملکردهای مهمی که نیاز به حاشیه نویسی دارند، آماده می کنیم. به عنوان مثال، ارائه حاشیه نویسی نوع برای یک ماژول کتابخانه که در صدها مکان استفاده می شود، مهم است. اما سرویس قدیمی که با سرویس جدید جایگزین می‌شود، دیگر اهمیتی برای حاشیه‌نویسی ندارد. ما همچنین در حال آزمایش با استفاده از تجزیه و تحلیل استاتیک برای ایجاد حاشیه نویسی نوع برای کدهای قدیمی هستیم.
واردات چرخه ای در بالا، من در مورد واردات چرخه ای صحبت کردم ("درهم و برهم وابستگی") که وجود آنها سرعت بخشیدن به mypy را دشوار می کرد. ما همچنین باید سخت کار می‌کردیم تا mypy از انواع اصطلاحاتی که توسط این واردات چرخه‌ای ایجاد می‌شوند پشتیبانی کند. ما اخیراً یک پروژه بزرگ طراحی مجدد سیستم را تکمیل کردیم که بسیاری از مشکلات mypy را در مورد واردات دایره ای برطرف کرد. این مشکلات در واقع از همان روزهای اولیه پروژه، بازگشت از Alore، زبان آموزشی که پروژه mypy در ابتدا روی آن متمرکز بود، سرچشمه می‌گیرد. نحو Alore حل مشکلات با دستورات وارد کردن چرخه ای را آسان می کند. mypy مدرن برخی از محدودیت‌ها را از اجرای ساده‌اندیشانه قبلی خود (که برای Alore مناسب بود) به ارث برده است. پایتون کار با واردات دایره ای را دشوار می کند، عمدتاً به این دلیل که عبارات مبهم هستند. به عنوان مثال، یک عملیات انتساب ممکن است در واقع یک نوع مستعار را تعریف کند. Mypy همیشه قادر به شناسایی مواردی مانند این نیست تا زمانی که بیشتر حلقه واردات پردازش شود. در Alore چنین ابهاماتی وجود نداشت. تصمیمات ضعیف اتخاذ شده در مراحل اولیه توسعه سیستم می تواند سال ها بعد یک شگفتی ناخوشایند برای برنامه نویس ایجاد کند.
نتایج: مسیر 5 میلیون خط کد و افق های جدید
پروژه mypy راه طولانی را طی کرده است - از نمونه های اولیه تا سیستمی که 4 میلیون خط از انواع کدهای تولید را کنترل می کند. همانطور که mypy تکامل یافت، نکات نوع پایتون استاندارد شد. این روزها، یک اکوسیستم قدرتمند در مورد تایپ کد پایتون توسعه یافته است. دارای مکانی برای پشتیبانی از کتابخانه است، حاوی ابزارهای کمکی برای IDE ها و ویرایشگرها است، چندین سیستم کنترل نوع دارد که هر کدام مزایا و معایب خاص خود را دارند.
با وجود اینکه چک کردن تایپ از قبل در Dropbox داده شده است، من معتقدم که ما هنوز در روزهای اولیه تایپ کد پایتون هستیم. من فکر می کنم فن آوری های بررسی نوع به تکامل و بهبود ادامه خواهند داد.
اگر قبلاً از بررسی نوع در پروژه بزرگ پایتون خود استفاده نکرده اید، بدانید که اکنون زمان بسیار خوبی برای شروع به تایپ استاتیک است. من با کسانی که انتقال مشابهی انجام داده اند صحبت کرده ام. هیچ کدام پشیمان نشدند. بررسی نوع، پایتون را به زبانی تبدیل می‌کند که برای توسعه پروژه‌های بزرگ بسیار مناسب‌تر از «پایتون معمولی» است.
خوانندگان عزیز! آیا از بررسی نوع در پروژه های پایتون خود استفاده می کنید؟
منبع: www.habr.com