كيف يؤثر افتقار بيثون إلى الكتابة الثابتة على قابلية الصيانة والتوسيع في المشاريع الأكبر؟

Question

بعد القراءة هذا السؤال بالمعلومات (وإن كان جدليًا إلى حد ما) أود أن أعرف تجربتك في برمجة المشاريع الكبيرة مع بيثون. هل تصبح الأمور غير قابلة للإدارة لأن المشروع يصبح أكبر؟ هذا القلق هو شيء واحد يبقيني مرتبطًا بجافا. لذلك سأكون مهتمًا بشكل خاص اطلاع مقارنات من قابلية الصيانة والتمديد من Java و Python للمشاريع الكبيرة.

Answer 1

أنا أعمل على منتج تجاري واسع النطاق يتم في بيثون. أعطي تقديرًا تقريبيًا جدًا لـ 5000 ملف × 500 خط. هذا حوالي 2.5 ملايين سطر من الثعبان. ضع في اعتبارك أن تعقيد هذا المشروع ربما يعادل 10 مللي+ خطوط رمز بلغات أخرى. لم أسمع من مهندس واحد/هندسة/مدير يشكو من أن كود بيثون لا يمكن صيانته. من ما رأيته من تعقب الأخطاء لدينا ، لا أرى أي مشكلة منهجية يمكن تجنبها عن طريق التحقق من النوع الثابت. في الواقع ، هناك عدد قليل جدًا من الأخطاء التي تفرخ من الاستخدام غير الصحيح لنوع الكائن على الإطلاق.

أعتقد أن هذا هو موضوع أكاديمي جيد للغاية لدراسة تجريبيا لماذا لا يبدو أن اللغة الثابتة القائمة على الطبقة هي أمر بالغ الأهمية كما يعتقد المرء.

وحول قابلية التوسيع. لقد أضفنا للتو قاعدة بيانات 2 أعلى قاعدة البيانات 1 في منتجنا ، وكلاهما غير SQL. لا توجد مشكلة تتعلق بالتحقق من النوع. بادئ ذي بدء ، قمنا بتصميم واجهة برمجة تطبيقات مرنة بما يكفي لتوقع التنفيذ الأساسي المختلفة. أعتقد أن اللغة الديناميكية تساعد وليس عائقًا في هذا الصدد. عندما تابعنا عبارة الاختبار وإصلاح الأخطاء ، كنا نعمل على نوع الأخطاء التي يعمل الأشخاص الذين يعملون على أي لغة. على سبيل المثال ، مشكلات استخدام الذاكرة ، وقضايا الاتساق والتكامل المرجعية ، وقضايا معالجة الأخطاء. لا أرى فحص النوع الثابت لديه الكثير من المساعدة في أي من هذه التحديات. من ناحية أخرى ، استفدنا بشكل كبير من اللغة الديناميكية من خلال القدرة على حقن الرمز في منتصف الرحلة أو بعد الترقيع البسيط. ونحن قادرون على اختبار فرضيتنا وإظهار إصلاحاتنا بسرعة.

من الآمن أن نقول إن معظم أكثر من أكثر من المهندسين سعداء ومنتجين باستخدام Python. ربما لا يمكن تصوره بالنسبة لنا لبناء نفس المنتج باستخدام لغة مطبوعة ثابتة بنفس القدر من الوقت بنفس الجودة.

Answer 2

من تجربتي ، قد يكون من الصعب الحفاظ على لغتي المكتوبة بشكل ثابت. على سبيل المثال ، دعنا نقول أن لديك وظيفة الأداة المساعدة تقبل فئة مخصصة كمعلمة. إذا كانت على الطريق ، فأنت تتبنى اتفاقية تسمية جديدة أكثر من اسم هذه الفئة ، فسيتعين عليها تغييرها ، ثم يجب أن تتغير جميع وظائف الأداة المساعدة أيضًا. بلغة مثل Python لا يهم طالما تنفذ الفصل نفس الأساليب.

أنا شخصياً أحتقر لغة تعترض طريقي. سرعة التعبير عن أفكارك هي القيمة ، وهذه هي ميزة Python على Java.

Answer 3

قد تكون قاعدة رمز كبيرة في بيثون دون تغطية اختبار جيدة مشكلة. ولكن هذا مجرد جزء واحد من الصورة. الأمر كله يتعلق بالأشخاص والمناهج المناسبة للقيام بهذه المهمة.

بدون

• التحكم في المصدر
• تتبع الأخطاء
• اختبارات الوحدة
• فريق ملتزم

قد تفشل مع أي نوع من اللغة.

Answer 4

أتذكر الأيام التي سبقت وبعد ابتكار فكرة Intellij. هناك اختلافات كبيرة. من قبل ، كانت الكتابة الثابتة فقط للتجميع ، ويعامل التطوير بشكل أساسي رمز المصدر كملفات نصية. بعد ذلك ، يكون رمز المصدر هو معلومات منظمة ، والعديد من مهام التطوير يجب أن تكون أسهل ، وذلك بفضل الكتابة الثابتة.

ومع ذلك ، ليس الأمر كما لو كانت الأيام الخوالي جحيمًا. أخذنا الأمر كما هو ، نفعل كل ما هو ضروري ، استخدم الأدوات المتاحة حتى الآن ، الحصول على النظام المبني ، والرضا. لم يكن هناك الكثير من الذكريات التعيس. ربما هذا ما يشعر به مبرمجي الكتابة الديناميكية الآن. انها ليست بهذا السوء.

بالطبع ، لن أعود إلى الأيام الخوالي. إذا كنت ممنوعًا من استخدام مثل هذه IDE ، أعتقد أنني سأعطينا البرمجة معًا.

Answer 5

حاول تتبع مصدر كائن مشوه على ما يبدو في إطار كبير من النوع الديناميكي مع الكثير من أنماط التصميم IOC أو غيرها من أنماط التصميم حيث لا يمكن تتبع الكائن مباشرة إلى أعلى المكدس.

حاول الآن القيام بذلك بلغة ثابتة.

ما لم يتم توثيق نوع الكائن بالقرب من موقع الاستخدام (على سبيل المثال عبر التعليقات التوضيحية نوعًا ، يمكن أن يكون من المستحيل فعليًا مكتبة A-La Python) أو في مكان ما على المكدس ، حيث يمكن أن يكون من المستحيل تقريبًا. أتحدث من التجربة ، بعد أن حاولت تصحيح أجزاء من إطار BuildBot. تضمنت كمية هائلة من النص الخام الذي يبحث عن الإطار ، حتى باستخدام IDEs الفاخرة مثل Pydev و Komodo و Wingware.

لا أشك في أنه من الممكن فرض بعض القيود على اللغات الديناميكية ، ولكن يبدو أن عدم وجود أي توحيد في هذا الأمر هو عائق أمام أي شخص يحاول تصحيح جزء من إطار كبير موجود.

تحرير: منذ عام 2014 ، أضاف Guido Pep484 و MyPy ووحدة الكتابة. وقد جعل هذا تجربتي أفضل بكثير من حيث الحفاظ على المشاريع الكبيرة.

Answer 6

في تجربتي ، يعتمد الصيانة على الاقتران المنخفض ، والتوثيق الجيد ، وعملية التطوير الجيدة ، واختبار ممتاز. الكتابة الثابتة لا علاقة لها بأي شيء من هذا.

الأخطاء التي ستقوم بها Java في وقت الترجمة ليست سوى مجموعة فرعية صغيرة من الأخطاء التي يمكن أن تحدث. كما أنها دائمًا ما تكون تافهة للاكتشاف عن طريق الاختبار ؛ لا توجد طريقة يمكنك من خلالها تفويت استدعاء طريقة على كائن من الفصل الخاطئ إذا كنت تختبر أن الكود الخاص بك ينتج الإجابة الصحيحة! في هذا الصدد ، يمكنك القول أن بيثون هو في الواقع أفضل لضمان الجودة ؛ بواسطة إجبار يمكنك اختبار ما لا يقل عن بعض الشيء لضمان خالية من الأخطاء المطبعية البسيطة ، فهو يضمن أنك بالفعل فعل اختبار قليلا على الأقل.

في الواقع ، فإن Java ليس مثالًا جيدًا جدًا على لغة ذات فحوصات ثابتة قوية لالتقاط الكثير من الأخطاء. حاول البرمجة في Haskell أو Mercury لمعرفة ما أعنيه ، أو من الأفضل أن تحاول البرمجة في Scala والتواصل مع مكتبات Java ؛ إن الفرق في مقدار "الصواب" الذي يمكن للمترجم قادرًا على ضمانك هو أن يكون ملفتة للنظر عند مقارنة رمز Scala Idiomatic العادي باستخدام مكتبات Scala إلى الكود الذي يجب أن يتعامل مع مكتبات Java (لقد قمت بذلك بالفعل ، لأنني قمت برمجة أ بت في Scala على Android).

قدرتك على كتابة رمز جيد للصيانة في قواعد التعليمات البرمجية الكبيرة التي عملت عليها العديد من المطورين على مدار فترات زمنية طويلة ، على الرغم من أوجه القصور في اكتشاف الأخطاء الثابتة لجافا مقارنة بلغات مثل Scala بالضبط نفس التقنيات يستخدم مبرمجي Python لفعل الشيء نفسه في قواعد الكود الكبيرة ، على الرغم من أوجه القصور في اكتشاف الأخطاء الثابتة لـ Python مقارنة بـ Java.

Answer 7

لقد استخدمت Python للعديد من المشاريع ، من بضع مئات من الخطوط إلى عدة آلاف الخطوط. تعد الكتابة الديناميكية بمثابة توفير وقت رائع ويجعل مفاهيم OO مثل تعدد الأشكال أسهل في الاستخدام. نظام النوع لا يجعل المشاريع غير قابلة للحماية. إذا كنت تواجه مشكلة في تخيل ذلك ، فحاول كتابة بعض الأشياء في بيثون وشاهد كيف يذهبون.