הנתיב לבדיקת סוג 4 מיליון שורות של קוד Python. חלק 3

אנו מציגים לתשומת לבכם את החלק השלישי של תרגום החומר על הנתיב שעברה Dropbox בעת הטמעת מערכת בדיקת סוגים עבור קוד Python.

← חלקים קודמים: הראשון и שני

מגיע ל-4 מיליון שורות של קוד מוקלד

אתגר מרכזי נוסף (והחשש השני בשכיחותו בקרב הנשאלים הפנימיים) היה הגדלת כמות הקוד המכוסה על ידי בדיקות סוג בדרופבוקס. ניסינו מספר גישות לפתרון בעיה זו, מהגדלה טבעית של גודל בסיס הקוד המוקלד וכלה במיקוד המאמצים של צוות mypy בהסקת סוגים אוטומטית סטטית ודינמית. בסופו של דבר, נראה היה שאין אסטרטגיה מנצחת פשוטה, אבל הצלחנו להשיג צמיחה מהירה בנפח הקוד המוער על ידי שילוב גישות רבות.

כתוצאה מכך, למאגר Python הגדול ביותר שלנו (עם קוד אחורי) יש כמעט 4 מיליון שורות של קוד מוער. העבודה על הקלדת קוד סטטית הסתיימה תוך כשלוש שנים. Mypy תומך כעת בסוגים שונים של דוחות כיסוי קוד המקלים על מעקב אחר התקדמות ההקלדה. בפרט, אנו יכולים להפיק דוחות על קוד עם אי בהירות בסוגים, כגון, למשל, שימוש מפורש בסוג Any בהערות שלא ניתן לאמת, או עם דברים כמו ייבוא ​​ספריות של צד שלישי שאין להן הערות סוג. כחלק מפרויקט לשיפור הדיוק של בדיקת סוגים בדרופבוקס, תרמנו לשיפור הגדרות הסוג (מה שנקרא קבצי stub) עבור מספר ספריות קוד פתוח פופולריות במאגר Python מרכזי. מדורגת.

הטמענו (ותקננו ב-PEPs עוקבים) תכונות חדשות של מערכת הסוג המאפשרות סוגים מדויקים יותר עבור כמה דפוסי Python ספציפיים. דוגמה בולטת לכך היא TypeDict, המספק סוגים למילונים דמויי JSON שיש להם קבוצה קבועה של מפתחות מחרוזת, שלכל אחד מהם ערך מסוגו. נמשיך להרחיב את מערכת הסוגים. הצעד הבא שלנו יהיה ככל הנראה שיפור התמיכה ביכולות המספריות של Python.

מספר שורות של קוד מוער: שרת

מספר שורות של קוד מוער: לקוח

המספר הכולל של שורות של קוד מוער

הנה סקירה כללית של המאפיינים העיקריים של הדברים שעשינו כדי להגדיל את כמות הקוד המוער בדרופבוקס:

הקפדה על הערות. הגדלנו בהדרגה את הדרישות לקפדנות של הערת קוד חדש. התחלנו עם טיפים בליטר שהציעו להוסיף הערות לקבצים שכבר היו להם כמה הערות. כעת אנו דורשים הערות הקלדה בקבצי Python חדשים וברוב הקבצים הקיימים.

הקלדת דוחות. אנו שולחים לצוותים דוחות שבועיים על רמת ההקלדה בקוד שלהם ונותנים עצות לגבי מה צריך להעיר קודם.

פופולריזציה של mypy. אנחנו מדברים על mypy באירועים ומדברים עם צוותים כדי לעזור להם להתחיל עם הערות סוג.

סקרים. אנו עורכים סקרי משתמשים תקופתיים כדי לזהות בעיות עיקריות. אנחנו מוכנים ללכת די רחוק בפתרון בעיות אלה (אפילו יצירת שפה חדשה כדי להאיץ את mypy!).

ביצועים. שיפרנו מאוד את הביצועים של mypy על ידי שימוש בדמון וב-mypyc. זה נעשה כדי להחליק את אי הנוחות המתעוררות במהלך תהליך ההערה, ועל מנת שניתן יהיה לעבוד עם כמויות גדולות של קוד.

אינטגרציה עם עורכים. בנינו כלים לתמיכה בהפעלת mypy בעורכים פופולריים ב-Dropbox. זה כולל PyCharm, Vim וקוד VS. זה פשט מאוד את תהליך הערת הקוד ובדיקת הפונקציונליות שלו. סוגים אלה של פעולות נפוצים בעת הערת קוד קיים.

ניתוח סטטי. יצרנו כלי להסקת חתימות פונקציות באמצעות כלי ניתוח סטטי. הכלי הזה יכול לעבוד רק במצבים פשוטים יחסית, אבל הוא עזר לנו להגדיל את כיסוי סוגי הקוד שלנו בלי הרבה מאמץ.

תמיכה בספריות צד שלישי. רבים מהפרויקטים שלנו משתמשים בערכת הכלים SQLAlchemy. הוא מנצל את היכולות הדינמיות של Python שסוגי PEP 484 אינם מסוגלים לדגמן ישירות. אנו, בהתאם ל-PEP 561, יצרנו את קובץ ה-stub המתאים וכתבנו תוסף עבור mypy (קוד פתוח), מה שמשפר את תמיכת SQLAlchemy.

קשיים שנתקלנו בהם

הדרך ל-4 מיליון שורות של קוד מוקלד לא תמיד הייתה קלה עבורנו. בשביל זה נתקלנו בבורות רבים ועשינו כמה טעויות. אלו חלק מהבעיות שנתקלנו בהן. אנו מקווים שספר עליהם יעזור לאחרים להימנע מבעיות דומות.

חסרים קבצים. התחלנו את עבודתנו בבדיקת כמות קטנה של קבצים בלבד. כל דבר שלא נכלל בקבצים האלה לא נבדק. קבצים נוספו לרשימת הסריקה כאשר הופיעו בהם ההערות הראשונות. אם משהו יובא ממודול שנמצא מחוץ לתחום האימות, אז דיברנו על עבודה עם ערכים כמו Any, שלא נבדקו כלל. זה הוביל לאובדן משמעותי של דיוק ההקלדה, במיוחד בשלבים הראשונים של ההגירה. גישה זו עבדה בצורה מפתיעה עד כה, אם כי מצב אופייני הוא שהוספת קבצים להיקף הסקירה חושפת בעיות בחלקים אחרים של בסיס הקוד. במקרה הרע, כאשר אוחדו שני אזורי קוד מבודדים, שבהם, ללא תלות זה בזה, כבר נבדקו טיפוסים, התברר שסוגי האזורים הללו אינם מתאימים זה לזה. זה הוביל לצורך לבצע שינויים רבים בהערות. במבט לאחור כעת, אנו מבינים שהיינו צריכים להוסיף מוקדם יותר מודולי ספריית ליבה לאזור בדיקת הסוג של mypy. זה יהפוך את העבודה שלנו להרבה יותר צפויה.

הערת קוד ישן. כשהתחלנו, היו לנו בערך 4 מיליון שורות של קוד Python קיים. היה ברור שהביאור לכל הקוד הזה הוא לא משימה קלה. יצרנו כלי בשם PyAnnotate שיכול לאסוף מידע על סוגים תוך כדי ריצות בדיקות ויכול להוסיף הערות סוג לקוד שלך על סמך המידע שנאסף. עם זאת, לא שמנו לב לאימוץ נרחב במיוחד של כלי זה. איסוף המידע היה איטי, והערות שנוצרו באופן אוטומטי דרשו לעתים קרובות עריכות ידניות רבות. חשבנו להפעיל את הכלי הזה באופן אוטומטי בכל פעם שאנחנו בודקים קוד, או לאסוף מידע על סוגים על סמך ניתוח כמות קטנה של בקשות רשת בפועל, אבל החלטנו שלא לעשות זאת מכיוון ששתי השיטות היו מסוכנות מדי.

כתוצאה מכך, ניתן לציין שרוב הקוד סומן באופן ידני על ידי בעליו. על מנת להנחות תהליך זה בכיוון הנכון, אנו מכינים דוחות על מודולים ופונקציות חשובות במיוחד שיש להעיר. לדוגמה, חשוב לספק הערות סוג עבור מודול ספרייה המשמש במאות מקומות. אבל שירות ישן שמוחלף בחדש כבר לא כל כך חשוב להעיר. אנחנו גם מתנסים בשימוש בניתוח סטטי כדי ליצור הערות סוג עבור קוד מדור קודם.

יבוא מחזורי. למעלה דיברתי על יבוא מחזורי ("סבכי התלות"), שקיומו הקשה על האצת mypy. היינו צריכים גם לעבוד קשה כדי לגרום ל-mypy לתמוך בכל מיני ניבים שנגרמים מהיבוא המחזורי הזה. לאחרונה השלמנו פרויקט תכנון מחדש של המערכת שתיקן את רוב הבעיות של mypy בנוגע לייבוא ​​מעגלי. הבעיות הללו נבעו למעשה מהימים הראשונים של הפרויקט, בחזרה מ-Alore, השפה החינוכית שבה התמקד פרויקט mypy במקור. תחביר Alore מקל על פתרון בעיות עם פקודות ייבוא ​​מחזוריות. mypy המודרנית ירש כמה מגבלות מהיישום הקדום והפשוט שלה (שהתאים מאוד לאלור). Python מקשה על העבודה עם יבוא מעגלי, בעיקר בגלל שהביטויים מעורפלים. לדוגמה, פעולת הקצאה עשויה למעשה להגדיר כינוי סוג. Mypy לא תמיד מסוגלת לזהות דברים כאלה עד שרוב לולאת הייבוא ​​עובדה. לא היו אי בהירות כאלה באלור. החלטות גרועות המתקבלות בשלבים הראשונים של פיתוח המערכת יכולות להוות הפתעה לא נעימה למתכנת שנים רבות לאחר מכן.

תוצאות: הדרך ל-5 מיליון שורות קוד ואופקים חדשים

פרויקט mypy עבר דרך ארוכה - מאבות טיפוס מוקדמים ועד למערכת השולטת ב-4 מיליון שורות של סוגי קוד ייצור. ככל שהתפתחה mypy, רמזי הסוג של Python היו סטנדרטיים. בימים אלה התפתחה מערכת אקולוגית רבת עוצמה סביב הקלדת קוד Python. יש לו מקום לתמיכה בספרייה, הוא מכיל כלי עזר ל-IDEs ולעורכים, יש לו כמה מערכות בקרת סוגים שלכל אחת מהן יתרונות וחסרונות משלה.

למרות שבדיקת סוגים כבר נתונה בדרופבוקס, אני מאמין שאנחנו עדיין בתחילת הדרך של הקלדת קוד Python. אני חושב שטכנולוגיות בדיקת סוגים ימשיכו להתפתח ולהשתפר.

אם עדיין לא השתמשת בבדיקת סוגים בפרויקט Python בקנה מידה גדול שלך, אז דע שעכשיו זה זמן טוב מאוד להתחיל לעבור להקלדה סטטית. דיברתי עם אלה שעשו מעבר דומה. איש מהם לא התחרט על כך. בדיקת סוגים הופכת את Python לשפה שמתאימה הרבה יותר לפיתוח פרויקטים גדולים מאשר "Python רגיל".

קוראים יקרים! האם אתה משתמש בבדיקת סוג בפרויקטים של Python שלך?

מקור: www.habr.com