كيف يمكن استخدام بايثون على نطاق واسع التنمية ؟

Question

وأود أن تكون مهتمة لمعرفة المزيد عن التنمية واسعة النطاق في بيثون وخاصة في كيف يمكنك الحفاظ على رمز كبير القاعدة ؟

• عندما كنت جعل التعارض تغييرات على التوقيع على طريقة كيف يمكنك أن تجد جميع الأماكن حيث أن الأسلوب يسمى.في C++/Java المترجم سوف تجد لك ، كيف يمكنك أن تفعل ذلك في الثعبان ؟

• عند إجراء تغييرات عميقة داخل الكود, كيف يمكنك معرفة ما العمليات مثيل يوفر, منذ لم يكن لديك نوع ثابت إلى البحث ؟

• كيف يمكنك التعامل مع/منع أخطاء الكتابة (المطبعية)?

• هي UnitTest تستخدم كبديل عن ثابت نوع فحص?

كما يمكنك تخمين انا تقريبا عملت فقط مع كتابتها بشكل ثابت لغة (C++/Java), ولكن أود أن محاولة يدي في بيثون أكبر البرامج.ولكن كان لي تجربة سيئة جدا, منذ وقت طويل, مع المقص (قديمه) لغة ، الذي كان أيضا كتابة حيوي.

Answer 1

نظرًا لأنه لم يشر أحد إلى أدوات pychecker وpylint والأدوات المشابهة، فسوف أقوم بما يلي:pychecker و pylint عبارة عن أدوات يمكن أن تساعدك في العثور على افتراضات غير صحيحة (حول توقيعات الوظائف، وسمات الكائن، وما إلى ذلك). لن يعثروا على كل ما قد يجده المترجم في لغة مكتوبة بشكل ثابت - ولكن يمكنهم العثور على المشكلات التي قد يجدها هؤلاء المترجمون لا يمكن العثور على مثل هذه اللغات أيضًا.

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

Answer 2

لا تستخدم سائق المسمار كما مطرقة

الثعبان ليس ثابت كتابة اللغة ، لذلك لا تحاول استخدام هذا الطريق.

عند استخدام أداة معينة, يمكنك استخدام ما تم بناؤه.لبيثون, يعني:

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

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

أنت لا تكتب Java, C++, Python, PHP, إرلانج مهما كان بنفس الطريقة.فهي جيدة الأسباب التي تجعل هناك مجالا لكل من العديد من لغات مختلفة ، فإنها لا تفعل نفس الأشياء.

وحدة الاختبارات ليست بديلا

وحدة الاختبارات يجب أن يؤديها مع أي لغة.الأكثر شهرة اختبار وحدة المكتبة (JUnit) هو من جافا العالم!

هذا لا علاقة له أنواع.يمكنك التحقق من السلوكيات مرة أخرى.يمكنك تجنب المتاعب مع الانحدار.يمكنك التأكد من العميل الخاص بك كنت على المسارات.

بايثون على نطاق واسع المشاريع

اللغات والمكتبات الأطر لا الحجم.أبنية القيام به.

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

بيثون هو مناسبة خاصة للمشاريع الكبيرة لأنه يفرض بعض الممارسات الجيدة و لديه الكثير من المعتاد أنماط التصميم المدمج في.ولكن مرة أخرى, لا تستخدم الأمر على ما هو عليه ولا تصميم.E. g :بايثون ليست تقنية وحدة المعالجة المركزية مكثفة المهام.

في مشروع ضخم ، هل من المرجح أن استخدام عدة تقنيات مختلفة على أي حال.كما SGBD (الفرنسية DBMS) و النموذجيه اللغة أو آخر.بيثون هو استثناء.

ربما كنت سوف ترغب في استخدام C/C++ الجزء من التعليمات البرمجية الخاصة بك تحتاج إلى أن تكون سريعة.أو جافا لتناسب في هر البيئة.لا أعرف, لا يهمني.بيثون يمكن أن تلعب بشكل جيد مع هذه.

وختاما

جوابي قد يشعر قليلا وقحا ولكن لا تفهموني خطأ:هذا سؤال جيد جدا.

الكثير من الناس يأتون إلى بيثون مع العادات القديمة.لقد أفسدت نفسي أحاول كود جافا مثل الثعبان.يمكنك, لكن لن تحصل على أفضل من ذلك.

إذا كنت قد لعبت / تريد أن تلعب مع الثعبان, انه لشيء رائع!إنها أداة رائعة.ولكن مجرد أداة ، حقا.

Answer 3

كان لدي بعض الخبرة في تعديل "Frets On Fire"، وهو نسخة مفتوحة المصدر من لغة بايثون "Guitar Hero".

كما أرى، فإن لغة بايثون ليست مناسبة حقًا لمشروع واسع النطاق.

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

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

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

Answer 4

0.10 يورو:

لدي العديد من تطبيقات بايثون في حالة "الإنتاج".تستخدم شركتنا Java وC++ وPython.نحن نطور باستخدام Eclipse IDE (pydev for python)

Unittests هي الحل الرئيسي للمشكلة. (أيضًا لـ c++ وjava)

عالم "الكتابة الديناميكية" الأقل أمانًا سيجعلك أقل اهتمامًا بجودة التعليمات البرمجية الخاصة بك

بالمناسبة:

التطور واسع النطاق لا يعني أنك تستخدم لغة واحدة!

غالبًا ما يستخدم التطوير واسع النطاق حفنة من اللغات الخاصة بالمشكلة.

لذلك أنا أوافق على مشكلة المطرقة :-)

---

ملاحظة: الكتابة الثابتة والبايثون

Answer 5

فيما يلي بعض العناصر التي ساعدتني في الحفاظ على نظام كبير إلى حد ما في لغة بايثون.

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

• تعتبر الاختبارات أمرًا أساسيًا، فمن دون اختبارات الوحدة، من المحتمل أن ينتهي بك الأمر بقاعدة تعليمات برمجية غير قابلة للإدارة بشكل أسرع عدة مرات من اللغات الأخرى.ضع في اعتبارك أن اختبارات الوحدة غالبًا ما تكون غير كافية، وتأكد من وجود العديد من اختبارات التكامل/القبول التي يمكنك إجراؤها بسرعة بعد أي تغيير كبير.

• يستخدم اخفاق سريع مبدأ.أضف تأكيدات للحالات التي تشعر فيها بأن الكود الخاص بك قد يكون عرضة للخطر.

• احصل على معالجة قياسية للأخطاء/التسجيل والتي ستساعدك على الانتقال بسرعة إلى المشكلة

• استخدم IDE (يعمل pyDev لصالحي) الذي يوفر الكتابة المسبقة وتكامل pyLint/Checker لمساعدتك في اكتشاف الأخطاء المطبعية الشائعة على الفور وتعزيز بعض معايير الترميز

• كن حذرًا بشأن وارداتك، لا تقم أبدًا بإجراء استيراد من x * أو إجراء عمليات استيراد نسبية دون استخدام .

• قم بإعادة البناء، غالبًا ما تكون أداة البحث/الاستبدال بالتعبيرات العادية هي كل ما تحتاجه للقيام بإعادة بناء أساليب النقل/نوع الفئة.

Answer 6

تغييرات غير متوافقة على توقيع الطريقة. لا يحدث هذا كثيرًا في Python كما يحدث في Java وC++.

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

كيف يمكنك العثور على جميع الأماكن التي يتم فيها استدعاء هذه الطريقة؟ يعمل grep للغات الديناميكية.إذا كنت تريد معرفة كل مكان يتم استخدام إحدى الطرق فيه، فإن grep (أو ما يعادله من البحث المدعوم من IDE) يعمل بشكل رائع.

كيف يمكنك معرفة العمليات التي يوفرها المثيل، بما أنه ليس لديك نوع ثابت للبحث عنه؟

أ.انظر إلى المصدر.ليس لديك مشكلة Java/C++ الخاصة بمكتبات الكائنات وملفات jar التي يجب التعامل معها.لا تحتاج إلى كل الأدوات المساعدة والأدوات المعقدة التي تتطلبها تلك اللغات.

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

ج.في بايثون، غالبًا ما تعمل من خلال المترجم التفاعلي.على عكس Java وC++، يمكنك استكشاف مثيلاتك بشكل مباشر وتفاعلي.لا تحتاج إلى IDE متطور.

مثال:

  >>> x= SomeClass()
  >>> dir(x)

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

مثال:

class MyClass { }
class MyClassx extends MyClass { }

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

هل يتم استخدام UnitTest كبديل للتحقق من النوع الثابت؟ وهنا وجهة النظر الأخرى:يعد التحقق من النوع الثابت بديلاً للتصميم الواضح والبسيط.

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

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

Answer 7

القاعدة العامة التي أتبعها هي استخدام اللغات الديناميكية للمشاريع الصغيرة غير المهمة للمهام واللغات المكتوبة بشكل ثابت للمشاريع الكبيرة.أجد أن الكود المكتوب بلغة ديناميكية مثل لغة بايثون يصبح "متشابكًا" بسرعة أكبر.ويرجع ذلك جزئيًا إلى أنه من الأسرع بكثير كتابة التعليمات البرمجية بلغة ديناميكية، مما يؤدي إلى اختصارات وتصميم أسوأ، على الأقل في حالتي.يرجع ذلك جزئيًا إلى أنني أمتلك IntelliJ لإعادة البناء بسرعة وسهولة عندما أستخدم Java، وهو ما لا أمتلكه مع لغة python.

Answer 8

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

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