عشية موسكو Python Conf ++ ، تحدثنا مع Nikita Sobolev ، CTO من شركة We Make Services ، حول المشكلة العالمية لإدارة تعقيد التعليمات البرمجية في سياق تطوير لغات البرمجة. وأيضًا عن السبب هنا بمرور الوقت ، يزداد الوضع سوءًا. بالإضافة إلى أنهم سألوا لماذا يحتاج إلى إنشاء اللبيدة الخاصة به.
- أخبرنا ببضع كلمات عن نفسك وعملك.أنا المدير الفني لـ "نحن نقدم الخدمات". بالحديث عن اسم الشركة ، أسأل عادةً السؤال: "ما رأيك ، ماذا نفعل؟". في الواقع ، نحن متخصصون في تطوير الويب: الواجهة الأمامية والخلفية للعملاء من الشركات. ونعمل وفقًا لمنهجية خاصة بنا ، والتي نقوم بتحسينها بالتوازي مع تطور الشركة - عملية تطوير البرمجيات المتكررة (RSDP).
- في Moscow Python Conf ++ ، ستتحدث ، بما في ذلك عن اللنتر الخاص بك. كيف يرتبط عملك بالتدقيق وإدارة تعقيد التعليمات البرمجية؟بشكل عام ، لدينا مجالان رئيسيان: التطوير نفسه وكل شيء حوله: الاستشارات ، ووضع المتطلبات ، وعلى وجه الخصوص ، المراجعة ، والتي أرى خلالها الكثير من التعليمات البرمجية لأشخاص آخرين. الرمز مختلف تمامًا: الذي هو الآن قيد التطوير ، والإرث ، الذي لن يصلحه أحد ؛ والرمز الذي يكتبه متخصصو العميل ، والرمز الذي طلبوه على الجانب. وفي جميع إصدارات الشفرة ، هناك الكثير من المشاكل: نفس المشكلة ومختلفة.
- ستتحدث إلى المطورين على وجه التحديد في Python. هل تمتلك Python أي ميزات فيما يتعلق بإدارة تعقيد التعليمات البرمجية؟بالطبع!
أولاً ، تعاني جميع اللغات ذات الكتابة الديناميكية بدرجة أكبر من التعقيد غير المبرر ، على الأقل بسبب عدم وجود سياق إضافي عند قراءة التعليمات البرمجية. ويسمح لك بمزيد من الأوساخ.
ثانيًا ، تتطور Python بنشاط. يحتوي على عناصر بناء جديدة ومفاهيم ووحدات جديدة في المكتبات القياسية التي تحطم كل ما كان من قبل.
- ما مدى سوء كل شيء في بيثون؟ بعد كل شيء ، هناك لغات أخرى نشطة بنشاط ، على سبيل المثال ، JavaScript ، والتي غالبًا ما يتم انتقادها لذلك. هل JavaScript أفضل؟لا. أود أن أقول أنه من حيث التعقيد ، فإن Python جيدة جدًا فيما يتعلق باللغات الأخرى. جافا سكريبت سيئة حقًا لسبب واحد بسيط: في كود مشروع JS ، يتم خلط العديد من الكيانات التي لا ترتبط باللغة نفسها في وقت واحد - المكونات الإضافية والمكتبات الخارجية التي يتم استخدامها لبناء المشروع. على سبيل المثال ، إذا كنت تستخدم Webpack ، يمكنك كتابة الوظيفة `import ()` ، التي تقوم بتحميل الوحدات بشكل غير متزامن. اتضح أن المجمع يقوم بدفع بعض من داخله إلى لغة البرمجة الخاصة بك ، وفي النهاية يكون من غير الواضح بشكل عام ما يحدث.
إدارة التعقيد أمر صعب عندما تتغير اللغة من تثبيت Babel أو مكوناته الإضافية. ومن أجل فهم كيفية عملهم ، تحتاج إلى اتباع معايير اللغة والتنفيذ المحدد وما إلى ذلك.
في بايثون ، الوضع أفضل بكثير. تتطور اللغة بشكل منهجي تمامًا ، وهذا التطور له معالم مفهومة. في ذلك ، لا يمكنك تغيير البنية جذريًا مع سطرين في التكوين. ولا تزال هذه خلفية ، لقد اعتدنا على تقديم مطالب أعلى من الواجهة الأمامية. ومع ذلك ، في رأيي ، توجد في Python بعض التغييرات الجديدة التي تكسر ما كان عليه من قبل ، مما يجلب فوائد مشكوك فيها.
- أي ، مع تطور اللغة ، يصبح كل شيء أسوأ؟إذا كنت تتذكر أن AsyncIO ظهرت - لغة ثانية بشكل أساسي داخل Python - بالطبع ، فقد ازداد التعقيد كثيرًا. في الواقع ، هناك الآن لغتان برمجة مستقلتان تمامًا مع بنية مماثلة: Python و Python + AsyncIO. أي أن Python ككيان أصبح أكثر تعقيدًا مرتين ، لأن لديه نسلان منفصلان يعملان وفقًا لقواعد مختلفة.
الرأي القائل بأن هذه لغات برمجة مختلفة ليست شائعة. ومع ذلك ، عندما تطلب من معارضي هذا الرأي ، على سبيل المثال ، تشغيل وظيفة غير متزامنة من رمز متزامن ، فإنهم يفشلون. تختلف المكتبات أيضًا تمامًا. تريد استخدام مكتبة متزامنة للعمل مع قاعدة البيانات - من فضلك. وتريد غير متزامن - ليس كذلك.
ولكن في Python ، التي تمت كتابتها قبل خمس سنوات ، لم يتغير شيء حقًا ، وحتى العكس ، ظهرت أدوات تبسط الشفرة ، على سبيل المثال ، التعليقات التوضيحية وفحص النوع.
- هل تؤثر إدارة التعقيد على حقيقة أنه في البرمجة يوجد الآن الكثير من الأشخاص الذين لديهم قاعدة تقنية ضعيفة؟بالطبع. لمثل هؤلاء الناس ، توصلوا حتى إلى لغة برمجة خاصة. يطلق عليه الذهاب. أنا لا أمزح. في الواقع ، كان الهدف من إنشاء لغة Go هو محاولة لإشراك طلاب Google والمتدربين الذين لا يمكنهم تعلم لغة C ++ في كتابة التعليمات البرمجية. لم تكن Python مناسبة لهم في الأداء ، فقد احتاجوا إلى شيء آخر ، وابتكرت Google Go. كما اتضح ، الكثير من الناس على استعداد للكتابة عليها ، لأنها بسيطة للغاية. ولكن بأي ثمن تم تحقيق هذه البساطة؟ إنهم لا يعطوننا لغة برمجة عادية ، ولكن نسختها المقتطعة جدًا - لا توجد مفاهيم معقدة بالتصميم عمليًا. لا توجد أدوية عامة ، ولا يوجد شيء مثل الاستثناءات ، إلخ. وهناك العديد من محبي هذا النهج.
ولكن هناك مطورين آخرين ، والمشكلة بالنسبة لهم هي أن هناك لغات لا يوجد بها توازن: يمكنك القيام بأشياء بسيطة ببساطة ، ولا يمكنك القيام بأشياء معقدة على الإطلاق. أو على الأقل من خلال الألم - يجب أن تقاتل بأداة للقيام بشيء ما. هنا ، يبدو لي ، هي مشكلة إدارة التعقيد.
- ما هي المشاكل النموذجية لرمز شخص آخر؟عادة ما يتم تقسيمها إلى قسمين.
الأول هو المشاكل المرتبطة بحقيقة أن الناس لا يمكنهم الاتفاق على مكان وضع فواصل شرطية. تقرأ رمزًا واحدًا وترى الفواصل في مكان واحد ، وتحول إلى ملف آخر - وترى الفواصل في مكان آخر. هذا يعقد الإدراك ، كما لو أن قراءة كتاب مطبوع في مكان واحد بخط غامق وفي آخر بخط مائل. هذا يصرف الانتباه عن المحتوى ، لأنه يجب على الدماغ أن يدرك أنها طريقة مختلفة لكتابة نفس الشيء.
عند تصحيح بناء الجملة ، تبدأ في الانتباه إلى دلالات ، لأن الناس يكتبون بشكل مختلف من الناحية المفاهيمية. لسوء الحظ ، لا توجد طريقة للاتفاق على هذا المستوى - من المستحيل التوصل إلى اتفاق أننا نحل مثل هذه المشاكل بهذه الطريقة ، ولكن هذه هي مثل هذه. لا يمكن تغطية جميع الحالات في البداية. تحدث هذه العملية أثناء مراجعة التعليمات البرمجية لمهمة فورية: عندما يتم شرح المطور لماذا لا يمكن اتخاذ قراره. إذا تم تطبيق ممارسة مراجعة الكود وكان المراجعون جيدين ، فإنهم يقطعون منحنيات الحل ولا توجد مشاكل في الكود. ولكن عادة ما نأتي إلى المراجعة حيث لم يتم تأسيس مثل هذه العملية. ومشاكل الدلالات والهندسة المعمارية أكثر صعوبة في الحل ، لأنه يصعب في بعض الأحيان صياغتها وتعريفها لأنفسهم.
- وما هو شكلها العملي؟على سبيل المثال ، يمكن للأشخاص حل نفس المشكلة في النماذج أو طرق العرض أو النماذج. ولا يوجد فهم مقبول بشكل عام حيث يجب حل هذه المهمة بالضبط: لا توجد وثائق أو أنماط قابلة للتطبيق بشكل خاص على هذا المشروع (على سبيل المثال ، هنا نستخدم نماذج سميكة ونضع كل المنطق فيها ، ولكن هنا نستخدم نماذج رقيقة ؛ جيدة أو سيئة ، الآن لا يهم ، لكننا اتفقنا على ذلك).
"ما الذي ترى أنه السبب الرئيسي لوجود هذه المشاكل؟"جميع الناس لا يعرفون كيفية كتابة التعليمات البرمجية.
تم حل هذه الأطروحة على النحو التالي: المشكلة أننا شعب. وبشكل عام ، يصعب علينا كتابة شيء منظم ومنطقي. وهنا لدينا أيضًا نوعان مختلفان من المتلقين. أولاً ، هذا هو الشخص الذي سيقرأ هذا الرمز ، وثانيًا ، هذا هو الجهاز الذي يجب تنفيذه. يجب إنشاء رمز الجهاز وفقًا لمعايير الأداء واستهلاك الذاكرة ووقت وحدة المعالجة المركزية ، ويجب أن يعتمد رمز الشخص على مبادئ قابلية القراءة والوضوح وما إلى ذلك. هاتان مهمتان معاكستان. والشخص الذي ، في الواقع ، لا يستطيع أن يحل بشكل كامل حتى واحد منهم ، يضطر إلى حل كلتا المهام المتناقضة في نفس الوقت.
"لكن استخدام أنماط برمجة مختلفة هو في الأساس بحث هندسي؟" هل هي حقا سيئة؟بالطبع ، البحث الهندسي مهم وضروري. ولكن يجب أن يكون قابلاً للإدارة أيضًا. قبل كل مهمة من هذا القبيل ، من الضروري وضع معايير وقيود واضحة: وفقًا للوقت المستغرق ، على متطلبات العمل ، على الممارسات والأدوات الهندسية.
من المرجح أن ألاحظ عمليات البحث الإبداعية. لا توجد مثل هذه القيود ، والتحقق من صحة النتائج التي تم الحصول عليها سواء. الجودة - كما في الفن المعاصر - لا يمكن قياسها.
يعاني جميع العملاء الذين يلجأون إلينا تقريبًا للتدقيق من موقف نموذجي: قام شخص ما بشيء لهم ، ووظف مطورًا لتطوير حل بطريقة ما ، لكنه جاء وبسط يديه: "لا أعرف على الإطلاق هنا للقيام بذلك ، لنعيد كتابة كل شيء. " هل سيكون من الجيد إعادة الكتابة؟ لن يكون. عندما تقرر إعادة الكتابة ، فأنت تخطو نفس المدمة تمامًا: أنت تكلف المهمة بمطور آخر يرتكب أخطاء أخرى ، ولكن في النهاية يتحول كل شيء إلى نفس الشيء تمامًا.
- هل تحتاج إلى نهج آخر؟نعم أثناء المراجعة ، نحاول العثور على سبب المشاكل المتعلقة بالكود: لماذا لم يأخذ شخص ما الوحدة ويضخمها لدرجة أنه سيكون من الصعب التمرير خلالها ، ولماذا تم اتخاذ القرار الخاطئ في البداية. ونحن نحاول أتمتة أو تبسيط القرارات الصحيحة قدر الإمكان في حدود معينة.
سأقدم القليل من الداخل للتقرير. الجميع يفهم أن الكود يتكون من خطوط - وهذا هو أبسط كيان يمكن أن يتكون منه. يمكن كتابة كل سطر باسم
x = 1أو ربما مثل
x = Math.median(forecast_data) if forecast_data else compute_probability(default_model) .
هناك فرق كبير بين هذين الخطين ، لأنك تفهم الأول بسهولة ، ويتركز الكثير من المنطق في الثاني. من الضروري تنفيذه في الرأس بالتوازي مع المترجم. لذلك ، تحتاج إلى بدء التحكم في كيفية كتابة التعليمات البرمجية ، مع التحكم في سطر واحد من التعليمات البرمجية. علاوة على ذلك ، يتحول الخط إلى مفاهيم أكثر تعقيدًا - الوظائف والفئات والوحدات وما إلى ذلك. لكن القواعد التي تقبلها يجب أن تكون واحدة.
نتيجة لذلك ، نحن لا نحظر القيام بأشياء كثيرة. لأن الإدارة عن المحظورات المفروضة.
- هل صادفت أي أشياء مضحكة في رمز شخص آخر؟بالطبع. لدي
مستودع حيث أقوم بجمع أمثلة التعليمات البرمجية هذه.
أوضح مثال مرعب رأيته أنه داخل حلقة من مائة تكرار ، يمكنك تحديد دالة. لأكون صادقًا ، عندما نظرت إليه ، انكسر داخل المترجم. خمنت ، لكن لم أكن أعلم أنه ممكن.
كانت هناك حالة عندما رأينا الكثير من التعليقات المضحكة في الكود. شخص اشتكى من الحياة ، عن العمل ، كان هناك من كتب: "أنا أفهم أنني أكتب هراء ، لكن الزبون يجبرني على ذلك." ومع ذلك ، لا يجبرك العملاء عادةً على كتابة رمز تالف. يطلبون حل مشكلتهم ، وما هو الرمز الذي تكتبه هناك ، ولا يهمهم.
- Linter ، مراجعة الكود - لا تحفظ؟لدي إجابتين. نعم ، إنهم يفعلون. لا ، إنهم لا يحفظون. من المفيد إذا اتبعت بدقة القواعد واللوائح التي أعطاها لك lanters المبطنة (أولئك الذين يقومون بالكثير من العمل الشاق نيابة عنك: تحقق من وظائف التعقيد ، دلالات التعليمات البرمجية ، إلخ). يجب حظر هذا العنصر. لا يمكنك فقط تشغيل اللتر في بعض الأحيان لإلقاء نظرة على النتيجة. إذا فشلت في هذه القواعد ، فلا يجب عليك إطلاق الشفرة في الإنتاج على الإطلاق.
ولكن في الواقع - لا يحفظون. لأن تلك المشاريع التي تستخدمها نادرة.
بالمناسبة ، يسألوني غالبًا: كيف أعرض هذا؟ وأجيب: الأمر بسيط للغاية ، لقد قمت بوضع سطر في CI - تحقق من الكود الخاص بي - وإذا تعطل ، فهذا كل ما في الأمر أنك قمت بتطبيقه. يبقى فقط لإعادة بناء كل شيء. لحسن الحظ ، هناك الآن تنسيقات تلقائية والقدرة على إعادة بناء ملف التعليمات البرمجية عن طريق ملف. السؤال التالي تقليدي: كيف نفسر للأعمال أن هذا مهم؟
- هل هناك إجابة عامة على هذا السؤال؟لكل حالة ، تختلف الإجابات ، لذلك في الحالة العامة يصعب صياغتها (تحتاج إلى التفكير في ذلك ، حول هذا ...). ولكن عادة ما تأتي الشركات التي تتعامل مع هذه المشكلة من الجانب التقني. على سبيل المثال يسألنا التقنيون ، كأشخاص يعرفون كيف يتحدثون عن الأعمال التجارية ، وعن التكنولوجيا يفهمون كيفية شرح ذلك للأعمال التجارية في حالتهم الخاصة. مع بيان المشكلة هذا ، يعمل هذا ببساطة شديدة. عندما تأتي ، كل شيء سيئ بالفعل ، والجميع يفهم هذا. تبدأ محادثة مع رجال الأعمال على النحو التالي: "ربما تعتقد أن المبرمجين يجلسون ولا يفعلون شيئًا؟" وإيماءات الأعمال. وأنت تقول أن هذه ليست النقطة. المبرمجون رجال رائعون يحاولون حل مشاكلك. ولكن بدون نهج متكامل لإدارة المشاريع ، كل شيء يقع في حالة من الفوضى ، وهذا أمر طبيعي.
ونقترح وضع قواعد لتجنب بعض المشكلات. نعتبر تكلفة إدخال قطع مختلفة ، ثم نقوم بتقييم الخسائر الحقيقية (المنجزة) من حقيقة أنه لا توجد مثل هذه القطع حتى الآن. على سبيل المثال ، يعمل المبرمجون على إصلاح خطأ لمدة شهر غير موجود أو يمكن العثور عليه في 30 ثانية ، إذا كنت تستخدم نهجًا وأداة محددين. الأرقام تقنع بشكل جيد.
- في النهاية ، هل هذه مشكلة إدارية؟بالطبع. أنا مقتنع بأن المبرمجين يريدون كتابة كود جيد. ولكن هناك عقبات مختلفة. شخص لا يعرف كيف بسبب قلة الخبرة. فقد شخص الدافع ، لأن الجميع لا يبالون. شخص ما لا يعرف بالضبط ما هو الرمز الجيد للسبب ، على سبيل المثال ، الرمي الإبداعي. يضغطون على شخص ما - يريد ويستطيع الكتابة ، لكنهم يقولون له إنه يجب أن يكون غدًا. وبدلاً من بناء شراكات مع الأعمال التجارية وشرح سبب عدم حدوث ذلك غدًا (أو إذا حدث ذلك ، فسيكون من الضروري الحكم لمدة ثلاثة أيام أخرى) ، على أي حال. ومثل هذه الشراكات مثيرة للاهتمام للعمل نفسه. كما أنه بحاجة إلى جعلها تعمل لفترة طويلة وأن تكون رخيصة الصيانة.
أي أن جميع القضايا يتم حلها هنا: لا توجد تناقضات غير قابلة للحل.
- هناك نمط رمز - PEP 8. لا يساعد على فهم ما هو جيد بسرعة؟من حيث الفواصل ، فإنه يساعد. ولكن ما هي النقطة إذا وضعت الفواصل بشكل صحيح وكل شيء آخر سيئ؟
- هل تفتقد بعض الأشياء عالية المستوى المعروفة؟من الناحية النظرية ، هناك بعض أفضل الممارسات الهندسية. لكنهم إما غير معروفين أو متجاهلين. عندما تسأل لماذا لم يتبع المطور هذه الممارسة ، قال إنه سمع أن هذا موضوع جيد ، لكن الشفرة تعمل بهذه الطريقة. عندما يتوقف الرمز عن العمل ، تسأل عما إذا كان يفهم من أين جاءت أفضل الممارسات المقابلة ولماذا تتبعه؟ لا ، لا أفهم ذلك. يعتقد أنه كان مخطئا ببساطة.
من الصعب أن تشرح للشخص أن ارتكاب الأخطاء أمر طبيعي. الجميع مخطئون ، كلنا بشر. ولكن تم اختراع أفضل ممارسة هندسية للتو لإنقاذك من خطأ أو حمايتك من العواقب. على سبيل المثال إنها أداة أمان ، كما هو الحال في الشركات. إنها لا تكتب فقط بالدم ، ولكن بالوقت والمال المتخلفين.
بشكل عام ، مهمتنا العالمية التي لا يمكن تحقيقها هي أتمتة مراجعة التعليمات البرمجية بحيث تعرف بايثون نفسها (إذا كنا نتحدث عن قضيتنا) كيفية كتابتها. يجب أن يكون هذا أداة لا توفر فرصًا فحسب ، بل أيضًا قيودًا للمطورين.
- لماذا حتى تطوير اللتر؟ هل من الممكن استخدام (أو تطوير) الموجودة؟في الواقع ، نحن نفعل ذلك. اللنتر لدينا في الواقع هو البرنامج المساعد ل Flake8. نحن ببساطة نضعها كأداة كاملة وليست مجرد مكون إضافي.
لماذا Flake8 وليس Pylint؟ يقوم Pylint بالكثير مما لا يجب أن يفعله اللتر. على سبيل المثال ، تقوم بتنفيذ عدد كبير جدًا من عمليات التحقق من النوع ، على الرغم من أن مدقق النوع يجب أن يتعامل مع الأنواع. بالإضافة إلى ذلك ، فإنه ينتج عددًا كبيرًا جدًا من الأخطاء ، وهي ليست كذلك في الواقع. ولا يعجبني توثيقه ، وأخشى تنفيذه من أست. من الصعب تكوين. من خلال تمكين التكوين ، فأنت تسمح للأشخاص بالقيام بالخيارات الخاطئة. لذلك ، مهمتنا هي إنشاء أداة لا يمكن تكوينها. إذاً أنت تضعها - هذا كل شيء.
- ما هي الأدلة التي شكلت أساس هذا اللنتر؟ أم أنها فقط تجربتك الخاصة هنا؟الآن يعتمد على القواعد التي قمنا بصياغتها لأنفسنا في مراجعة الكود لسنوات عديدة. تم نقل بعض القواعد من الوبر الأخرى: ESLint و Pylint و SonarQube و Credo. لقد تم أخذ الكثير من العمل الممتاز
في CognitiveComplexity . نظرت دائمًا إلى محفظة Miller. قواعد منفصلة - هذه هي رؤيتي ، والتي ظهرت بعد تقييم عدد كبير من كود الآخرين. أي أنها في هذه المرحلة "خليط".
- ما الذي ستتحدث عنه في موسكو Python Conf ++؟بادئ ذي
بدء ، حول
إدارة التعقيد . هذا الموضوع قريب ومفهوم لجميع المطورين. سنلقي نظرة على مقاييس مختلفة ، حول طرق نقل التعقيد من أبسط كود المكون - الخطوط - إلى الوحدة الأكثر تعقيدًا. ثم سنتحدث عن الجزء الجامع ، حيث سأقدم رؤيتي لكيفية أو عدم الكتابة في Python ، وأطلب من المستخدمين التصويت على ما يحبونه وما لا يحبونه. بالنسبة للعديد من المطورين ، فإن القيود (القيام بـ A ، ولكن عدم القيام بـ B) هي محاولة على مساحتهم الإبداعية ، لذلك يتفاعلون بعنف مع هذا. وهنا فقط يمكنك بدء مناقشة مثيرة للاهتمام.
- على من يركز التقرير؟أعتقد أن هؤلاء لا يزالون مطورين راسخين ، لأن المبرمجين المبتدئين لم يشكلوا رأيهم الواضح بعد. على الرغم من أنه سيكون من المثير للاهتمام بالنسبة لهم الاستماع والتحدث بصراحة. هم بالتأكيد مستخدمونا.
, ,
Moscow Python Conf++ . . ,
.