هل تتمتع العديد من مكتبات بايثون بجودة تعليمات برمجية منخفضة نسبيًا؟

https://stackoverflow.com/questions/602096

03-07-2019
|

سؤال

يحرر: منذ طرح هذا السؤال، حدث الكثير من التحسن في مكتبات بايثون العلمية القياسية (التي كانت المنطقة المستهدفة).على سبيل المثال، بذل مشروع numpy جهدًا كبيرًا لتحسين سلاسل المستندات.لا يزال بإمكان المرء أن يجادل حول ما إذا كان من الممكن معالجة هذه القضايا بشكل مستمر منذ البداية.

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

بعض الأسباب التي تجعلني أشعر بأن الجودة مفقودة:

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

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

المحلول

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

أ) قم بالتعليق على الكود الخاص بك!لا يوجد شيء اسمه كود التوثيق الذاتي!

ب) إنفاق ما لا يقل عن 25% من ميزانية وقت المشروع على وثائق المستخدم النهائي.

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

نصائح أخرى

وبدلاً من ذلك، يبدو أن كلًا من المؤلفين يتبع تقليده المجيد.وفي بعض الأحيان لا تتوافق الاتفاقيات مع نفس ملف المكتبة

مرحبًا بك في الكود الرائع للعالم الحقيقي!

كود FWIW Python الذي التقيت به ليس أفضل أو أسوأ من ذلك في أي لغة أخرى.

(حسنًا، من الواضح أنه أفضل من متوسط مشروع PHP، لكن هذا ليس عادلاً حقًا.)

أول شيء عليك أن تدركه هو أن بايثون لم تنبثق بشكل كامل من رأس جيدو في وقت ما حول الإصدار 2.x.لقد نمت على مدار العشرين عامًا الماضية.

في الواقع، عدد من الأشياء التي ذكرتها (unittest، على سبيل المثال، وPEP-8)، لم تكن موجودة حتى عندما تمت كتابة بعض المكتبات القياسية لأول مرة.

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

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

هذا لا يعني أنه لا توجد أشياء يمكن تحسينها في مكتبات بايثون - فهي موجودة!ولكن هناك دائمًا مقايضة بين الكمال وإنجاز الأمور.وهذا أحد الأسباب التي تجعلهم يقولون "التطبيق العملي يتفوق على النقاء".

وذلك لأن لغة Python غير مدعومة من قبل عالم الشركات مثل Java أو .Net.

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

كما أن معظم مطوري Python هم من C++ وC وJava و.Net وما إلى ذلك.ويبدأون في كتابة كود الإنتاج منذ اليوم الأول.بفضل سهولة بايثون.وتستمر الحلقة المفرغة.

حتى أنني استغرقت شهرًا للقدوم إلى PEP8 وإعادة صياغة الكود الخاص بي.

لقد تغير PEP 8 بمرور الوقت.تتبع بعض الوحدات التوصيات القديمة.يمكنك أن ترى ذلك مع PIL، الذي يستخدم وحدات مثل "Image" حيث تحتوي الوحدة على فئة رئيسية واحدة، بدلاً من الأحرف الصغيرة الموصى بها لأسماء الوحدات، وفي امتدادات C التي تستخدم البادئة "c"، بدلاً من البادئة الأكثر حداثة " _" بادئة.

تم تطوير بعض المكتبات من قبل أشخاص متأثرين بشدة بالتقاليد في مجالات أخرى، مثل Java وC++.غالبًا ما يستخدم هؤلاء الأشخاص CamelCase بدلاً من الأحرف الصغيرة الموصى بها من قبل PEP 8.

الإجابات هنا لن تكون كاملة دون الإشارة إلى قانون سمك الحفش:"تسعون بالمائة من كل شيء هراء."

تسعون بالمائة من [مكتبات بايثون] بدائية، لكن تسعين بالمائة من كل شيء بدائية

- قانون سمك الحفش (معاد صياغته)

يبدو أنك وجدت أن جودة التعليمات البرمجية لا تلبي التوقعات التي كنت على استعداد لتوقعها.ربما من المدرسة، أو كتب أفضل الممارسات أو كبار المطورين.

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

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

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

أما بالنسبة لـ matplotlib، فهناك مشروع لتحسين "pythoness" الخاص به - http://www.scipy.org/PyLab

إن ما يميز المكتبات العلمية هو أنها مكتوبة بواسطة علماء، وليس بواسطة مطوري برمجيات محترفين.علاوة على ذلك، هؤلاء العلماء معتادون على كتابة فورتران.السؤال هو - هل تفضل الحصول على كود فعال أم كود جميل؟

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

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

على محمل الجد، لماذا تهتم حقًا بما هو الكود المصدري له matplotlib يبدو، طالما أنه يفعل ما هو المقصود منه القيام به؟

وأنا أتفق معك في المفقودين docstrings (بافتراض أنها عناصر عامة وليست عناصر داخلية) ولكن هذه ليست الطريقة الوحيدة لتوثيق المكتبة.

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

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

قد يكون الحل هو أن يكون لدى مستودعات مكتبة Python (مثل PyPI) قواعد أكثر صرامة حول قبول الحزم المساهمة - التعامل مع هذا من خلال عملية مراجعة تهدف إلى ضمان الجودة - بنفس الطريقة التي تخضع بها توزيعات Linux الرئيسية لعملية مراجعة قبل إضافة حزمة إلى مستودعاتهم.

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

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

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

ماذا عن مجموعة من الأمثلة على البرامج الجيدة؟
قد تؤدي الأمثلة الجيدة إلى التحسن العام بشكل أسرع قليلاً من المشي العشوائي.
يمكن تقسيم المجموعة إلى فئات مثل:
مستند مضمّن / صفحة مساعدة / برنامج تعليمي / دليل مرجعي، صفحة ويب / ورق، صور / لا شيء.
يجب أن يحتوي كل إدخال على بضع كلمات لماذا يجده المراجع جيدًا.
(أين:زاوية من تدفق المكدس؟)

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

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

هذه واحدة من الجماليات العديدة للمصادر المفتوحة.

غالبًا ما يكون من غير المنطقي كتابة الكثير من الوثائق والأكواد "الجيدة" إذا كنت لا تعرف ما إذا كان المشروع سيستمر أم لا.سيكون ذلك مجرد مضيعة للوقت.

يحرر:بالطبع كتابة كود جيد لن تؤذي أبدًا في المرة الأولى بالرغم من ذلك...ولكن ربما يكون مجرد "إنجاز المهمة" أمرًا جيدًا بما فيه الكفاية في كثير من الحالات.أعتقد أنه بخلاف ذلك لن نتمتع بالكم الهائل من الخيارات عندما يتعلق الأمر بـ OSS.

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

جودة الكود * عدد التعليقات * الوقت = ثابت

اختر اثنان !

لم أواجه أي مشكلة في استخدام matplotlib؛لا أستطيع أن أقول إنني نظرت إلى الكود كثيرًا - إنها مكتبة جيدة.يفعل ما يفترض القيام به (مجانا!)

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow