نقدم انتباهكم إلى الجزء الثالث من ترجمة المادة على المسار الذي سلكه Dropbox ، مع تقديم نظام للتحقق من أنواع شفرة Python.
→ الأجزاء السابقة:
الأولى والثانيةالوصول إلى 4 ملايين سطر من الكود المكتوب
مهمة أخرى مهمة (كانت هذه ثاني أكثر المشكلات التي تقلق أولئك الذين شاركوا في استطلاعات الرأي الداخلية) وهي زيادة حجم الكود في Dropbox المغطى بفحوصات النوع. لقد جربنا عدة طرق لحل هذه المشكلة - بدءًا من النمو الطبيعي لحجم قاعدة الكود المكتوب إلى تركيز جهود فريق mypy على الاستدلال النوعي الثابت والديناميكي. نتيجة لذلك ، يبدو أنه لا توجد استراتيجية رابحة بسيطة ، لكننا تمكنا من تحقيق نمو سريع في حجم الشفرة المشروحة من خلال الجمع بين العديد من الأساليب.
نتيجة لذلك ، بلغ عدد أسطر الكود المشروح في أكبر مستودع بيثون (مع الكود الخلفي) ما يقرب من 4 ملايين. تم العمل على الكتابة الثابتة للرمز في حوالي ثلاث سنوات. يدعم Mypy الآن أنواعًا مختلفة من تقارير تغطية الأكواد التي تسهل مراقبة تقدم الكتابة. على وجه الخصوص ، يمكننا إنشاء تقارير حول الكود مع عدم اليقين في الأنواع ، على سبيل المثال ، الاستخدام الصريح
Any نوع في التعليقات التوضيحية التي لا يمكن التحقق منها ، أو من خلال استيراد مكتبات الجهات الخارجية التي لا تحتوي على تعليقات توضيحية للنوع. كجزء من مشروع لزيادة دقة التحقق من الكتابة في Dropbox ، ساهمنا في تحسين تعريفات الأنواع (ما يسمى ملفات كعب الروتين) لبعض مكتبات المصادر المفتوحة الشعبية في مستودع Python المركزي المصنف.
لقد قمنا بتطبيق (وتوحيد معايير PEPs اللاحقة) على ميزات جديدة لنظام الكتابة ، والتي تسمح لنا باستخدام أنواع أكثر دقة لبعض أنماط بيثون المحددة. أحد الأمثلة البارزة على ذلك هو
TypeDict ، الذي يوفر أنواعًا من القواميس المشابهة لـ JSON والتي تحتوي على مجموعة ثابتة من مفاتيح السلسلة ، لكل منها قيمة من نوعه. سوف نستمر في توسيع نظام الكتابة. ربما ستكون خطوتنا التالية هي تحسين الدعم لقدرة بيثون على العمل مع الأرقام.
عدد أسطر الكود المشروح: الخادمعدد أسطر الكود المشروح: العميلاجمالي عدد سطور الكود المشروحفيما يلي نظرة عامة على الميزات الرئيسية للإجراءات التي قمنا بها لزيادة حجم الشفرة المشروحة في Dropbox:
صرامة الشرح. لقد قمنا تدريجياً بزيادة متطلبات دقة التعليق التوضيحي للشفرة الجديدة. لقد بدأنا بنصائح linter التي اقترحت إضافة التعليقات التوضيحية إلى الملفات التي تحتوي بالفعل على بعض التعليقات التوضيحية. نطلب الآن كتابة تعليقات توضيحية في ملفات Python الجديدة وفي معظم الملفات الموجودة.
كتابة التقارير. نرسل تقارير أسبوعية إلى الفرق حول مستوى كتابة التعليمات البرمجية الخاصة بهم ونقدم نصائح حول ما ينبغي شرحه في المقام الأول.
تعميم mypy. نتحدث عن mypy في الأحداث المختلفة ونتواصل مع الفرق لمساعدتهم على البدء في استخدام التعليقات التوضيحية.
استطلاعات الرأي. نجري استطلاعات دورية للمستخدمين لتحديد المشكلات الرئيسية. نحن على استعداد للذهاب إلى أبعد من ذلك لحل هذه المشكلات (حتى إنشاء لغة جديدة من أجل تسريع الغموض!).
الأداء. لقد قمنا بتحسين أداء mypy بشكل كبير من خلال استخدام البرنامج الخفي و mypyc. تم القيام بذلك لتخفيف المضايقات التي تحدث أثناء عملية التعليق التوضيحي ، ولكي تتمكن من العمل بكميات كبيرة من التعليمات البرمجية.
التكامل مع المحررين. لقد أنشأنا أدوات لدعم إطلاق 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 دائمًا اكتشاف مثل هذه الأشياء حتى تتم معالجة معظم دورة الاستيراد. ألور لم يكن لديه مثل هذا الغموض. يمكن أن تمثل القرارات غير الناجحة المتخذة في المراحل المبكرة من تطوير النظام مفاجأة غير سارة للمبرمج بعد عدة سنوات.
ملخص: الطريق إلى 5 ملايين سطر من الكود وآفاق جديدة
لقد قطع مشروع mypy شوطًا طويلًا - بدءًا من النماذج الأولية المبكرة إلى نظام يتحكم في أنواع كود الإنتاج بحجم 4 ملايين خط. كما تقدم mypy ، كانت تلميحات الكتابة موحدة في بيثون. تطور نظام بيئي قوي حول كتابة كود Python هذه الأيام. وجد مكانًا لدعم المكتبات ، ويحتوي على أدوات مساعدة لـ IDEs والمحررين ، ولديه العديد من أنظمة التحكم في النوع ، لكل منها إيجابيات وسلبيات.
على الرغم من أن التحقق من النوع يعتبر بالفعل أمرا مفروغا منه في Dropbox ، أنا متأكد من أننا لا نزال نعيش في فجر كتابة شفرة Python. أعتقد أن تقنيات فحص النوع ستستمر في التطور والتحسن.
إذا لم تكن قد استخدمت اختبارات الكتابة في مشروع Python الواسع النطاق ، فعليك أن تعلم أن الوقت مناسب لبدء الانتقال إلى الكتابة الثابتة. لقد تحدثت مع أولئك الذين قاموا بمرحلة انتقالية مماثلة. لم يندم أحد منهم. يحول التحكم في الكتابة Python إلى لغة أفضل بكثير من "Python العادي" لتطوير المشاريع الكبيرة.
أعزائي القراء! هل تستخدم التحكم في الكتابة في مشاريع بايثون الخاصة بك؟
