تحية! اسمي نيكولاي Izhikov. في هذا المنشور أريد أن أتحدث عن عنصر واحد مهم من عناصر التفاعل الذي نواجهه في عملية تطوير البرمجيات ، وخاصة في المصادر المفتوحة. هذا هو تجول ومراجعة التعليمات البرمجية.
سأقدم نصائح
ضارة حول كيفية جعل ميزة بلدي وإحضارها إلى دمجها في معالج مشروع مفتوح المصدر في سياق الاختلافات الثقافية والزمنية والمفاهيمية وغيرها بين أفراد المجتمع. عادة ما يكون هذا سؤالًا صعبًا ، خاصة بالنسبة لأولئك الذين بدأوا للتو في المصدر المفتوح.
لنبدأ بمقدمة صغيرة. عند التواصل مع الأشخاص ، خاصةً في الدردشة أو عبر البريد ، وخاصة باللغة الإنجليزية ، ضع في اعتبارك دائمًا أنه يمكن اعتبار رسالتك مختلفة تمامًا عن توقعاتك. الذي سوف يقرأ الرسالة غير معروف. يمكن أن يكون هندوسيًا أو رجلًا إنجليزيًا أو مجرد شخص نعسان. ستكون هناك دائمًا اختلافات في فهم كلمات معينة ، ودون الخوض في التفاصيل الفنية ، سوف أخبرك بكيفية تقليلها.
تحذير: القصة تحتوي على سخرية.
نصائح سيئة للمساهم
لا تناقش ميزة جديدة مع أي شخص
إذا كنت ترغب في تطبيق ميزة جديدة ، فلا تناقش في أي حال المراجعة الخاصة بك مع أي شخص. يمكن للشخص التنصت والقيام بذلك قبل! أو بعد سماع التفاصيل ، قد يخبرك أنك لم تفهم شيئًا ما - لانتقاد فكرتك. النقد يضر كثيرا. ربما تمت مناقشة ميزة مثل خاصتك بالفعل ، وتحتاج إلى ميزة أخرى ... بشكل عام ، لا تخبر أحداً بأي حال ما تريد القيام به. أبدا.
لا تفعل الوثائق التقنية
ملتزمون والرجال ذوي الخبرة من المجتمع مولعا جدا لفهم رمز التصحيح تلقى. لذلك ، في أي حال من الأحوال لا تفعل الوثائق التقنية. ويكي ، جيرا ، مناقشة قائمة البريد - كل هذا هراء كامل. وهراء ليس لك!
عندما ترسل تصحيحًا إلى [+5000 ، -3500] مع وصف للتحسينات في شكل "تحسينات على أساليب المصنع وبعض التحسينات الأخرى" ، فإن الجميع سوف يكتشفون ذلك بنفسهم ، وفي نفس الوقت سوف يفهمون مدى جودتك.
أبدا تشغيل الاختبارات
أي اختبارات خطيرة لأنها يمكن أن تكسر شيئًا ما. إذا كنت لا تزال قادرًا على إجراء الاختبارات ، فلا تُظهر نتائجها. أخطاء في النتائج يمكن أن تؤدي إلى رفض التصحيح! وبالتأكيد لا تكتب اختبارات جديدة. تشغيل الكل سيكون أطول ، سيزيد استهلاك وحدة المعالجة المركزية. على أي حال ، يكتب المطورون الجيدون الكود بدون أخطاء - أي زميل من ذوي الخبرة سوف ينظر إلى تصحيحاتك ويفهم أنه لا توجد أخطاء هناك.
لا تقرأ أبدًا الكيفية
عند الدخول في مشروع مفتوح المصدر ، لا تقرأ أبدًا أي طريقة. هي مكتوبة لالحمقى ، أليس كذلك؟
صمم الكود بطريقتك الخاصة. وإلا ، كيف سيفهم الجميع أنك مطور جيد وشخص مبدع متنوع ولديه حس متطور من الجمال؟
إرسال بقع كما هو مناسب لك. على سبيل المثال ، يرتبط المشروع بالبنية التحتية لـ GitHub - أرسله أثناء إرساله إلى linux kernel ، مباشرة في الخطاب. لا يمكنك حتى في المرفق ، ولكن مباشرة في النص. بعد كل شيء ، لن ينصح Linus Torvalds سيئة! وإذا تم تبني المشروع بطريقة مختلفة ، فهذه هي مشاكل المشروع.
لا تتردد في تعقيد واجهة برمجة التطبيقات العامة
عند تطوير واجهة برمجة التطبيقات العامة الجديدة ، حاول أن تجعلها مجردة ومعقدة قدر الإمكان. يمكن دائمًا الرد على أي أسئلة للمستخدم حول السلوك غير الواضح لواجهة برمجة التطبيقات: "هل لم تقرأ الدليل؟ صفحة 42 ، كل شيء مكتوب بوضوح! اقرأها مرة أخرى! في المشاريع الجادة ، يجب أن يكون كل شيء معقدًا. لدينا مشروع خطير؟
لا تنصح أو تتحدث عن المشاكل
لا تتشاور مع أي شخص ولا تخبر أحداً عن المشاكل التي واجهتها في التطوير. إنه أكثر متعة لفهم شيء واحد. على أي حال ، فإن المطورين الجيدين ينجحون دائمًا في المرة الأولى ، وليس لديهم أي مشاكل. إذا تعرف الآخرون على مشاكلك ، فسيصبحون أكثر ذكاءً ويكتبون الكود أسرع منك. هذا لا ينبغي أن يسمح. وبالفعل ليس من المعتاد التحدث عن مشاكل المرء.
القيود المفروضة على القرار النهائي هي أيضا لا تستحق الذكر. بعد كل شيء ، قد يتم طلب الحل للانتهاء. من يهتم بالقيود؟ عندما يبدأ المستخدم في إدخال المنتج الخاص بك في قيود المنتج ويواجهه ، سيكون أكثر اهتمامًا وأكثر متعة. سوف يأتي إليك ويطلب منك الانتهاء منه. وحتى هذه اللحظة ، لا تخبره بأي حال عن القيود - ماذا لو قرر عدم تنفيذ أي شيء؟
سيجد المراجع الجيد حقًا كل شيء وسيسألك عن التفاصيل. في أي حال من الأحوال لا تخبره عن أي شيء.
إذا كانت لديك أسئلة ، فاكتب إلى قائمة التطوير
هذه الحافة تكمل السابقة. من الأفضل ليس فقط عدم إخبار أي شخص بأي شيء ، بل أيضًا طرح أي أسئلة في قائمة التطوير.
فيما يلي أمثلة للأسئلة التي يحب الجميع الإجابة عليها. إذا كنت تكتب نوعًا من الاختبار ، فتأكد من السؤال "هل تحتاج إلى التحقق من عدم وجود هذه المجموعة؟". ليس عليك معرفة ذلك بمفردك ، يمكنك دائمًا السؤال على ورقة مطور البرامج. بعد كل شيء ، هناك الكثير من الناس الذين ينتظرون فقط لطرح مثل هذا السؤال. وسوف تسعى للرد بشكل أسرع على ذلك.
"كيف أفعل المهمة؟" - سؤال عظيم آخر. لا تشير بأي حال من الأحوال إلى أي تفاصيل: سيكون معرف المهمة كافيًا. جميع الذين يحتاجون إليها سوف يرون بأنفسهم.
"أي إطار للاستخدام؟" - أيضا سؤال جيد جدا. من المثير للاهتمام دائمًا الإجابة عليه ، ويمكنك المناقشة.
إصلاح جميع مشاكل المشروع في طلب سحب واحد
هذه هي نصيحتي المفضلة. قم بإصلاح جميع مشاكل المشروع في طلب سحب واحد ، خاصة إذا كنت تعمل في مؤسسة. لم يكن هناك سوى الحمقى في المشروع قبل أن يكتبوا الرمز بشكل سيء. وأنت تكتب جيدا. وفقًا لذلك ، يجب عليك ببساطة:
- Refactor جميع التعليمات البرمجية الموجودة التي لا تفهمها ؛
- إعادة تسمية الكل ، في رأيك ، المتغيرات المسماة بشكل غير صحيح ؛
- إصلاح جميع تعليقات javadoc الموجودة.
بشكل عام ، يمكنك أخذ بعض الفئات والمصانع وإخراجها ، وإجراء تحويلات أخرى حتى يكون الرمز أفضل. سيبدو هذا مثيرًا للإعجاب بشكل خاص في المناطق التي لا تتعلق بمهمتك. حتى تتمكن من الكشف بشكل كامل عن إمكاناتك. إلى مجد OOP! آمين!
طلب مراجعة الكود مقدما
عند القيام بمهمة ، ثم إرسال طلب لمراجعة الكود ، قد تستغرق العملية بعض الوقت. جميع الخبراء مشغولون عادة. استفد من الخدعة: عندما تنتهي مهمتك ، كما يبدو لك ، قريبًا ، اطلب المراجعة مقدمًا. بعد كل شيء ، لن يبدوا في الحال - حتى تصل يديك إليك ، يمكنك فقط إنهاء كل شيء.
حسنًا ، إذا كان للمراجع فجأة وقت ، في حين أن المهمة لم تكتمل بعد ، فقد كان سيئ الحظ. اشرح الموقف ، قل إن كل شيء سيكون جاهزًا غدًا. وبهذه الطريقة يمكنك تسريع العملية (على الأقل عن طريق المراجعة) والحصول على دمج أسرع.
تعبت من المهمة - تسقطها
كل من يعمل في المصادر المفتوحة لديه الكثير من الوقت. لا حاجة لإنهاء أي شيء. مرت مراجعة الكود ، التعليقات المستلمة. ولماذا تحرير وتقديم شيء لدمج؟ خذ اللغز التالي وقم به. هذه هي طريق النجاح! المراجع لديه الكثير من الوقت ، وسوف ننظر التصحيح التالي دون نتيجة!
المعلق هو عدوك
وماذا اسم الشخص الذي يقف بينك وبين ارتكاب سيد؟ انتقاد الكود هو انتقاد شخصي لك! من هو الذي يعتقد أنه؟ في التواصل الشخصي ، "قنبلة" قدر الإمكان! خلاف ذلك ، كيف يعرف المراجع أنك تهتم؟ هذه هي القاعدة الأساسية للتنمية!
أوصي هذه النصيحة في التنمية اليومية. هذا يساعد على تحقيق النتيجة والقيام بذلك بشكل صحيح.
نصيحة سيئة للمراجع
لا أتمتة الاختبارات الروتينية
إذا وصلت إلى المستوى في المشروع عندما يتم بالفعل إرسال تصحيحات للمراجعة إليك ، فلا تقم بأي حال من الأحوال بأتمتة عمليات الفحص الروتينية! من الممتع أكثر قضاء بضع دورات مراجعة على استكشاف الأخطاء وإصلاحها والمناقشة:
- تنسيق الكود ؛
- تسمية متغير
- يتحقق ما إذا كانت هذه المتغيرات محددة نهائيًا ، والتي يمكن تمييزها بها ؛
- ... وكل شيء آخر.
في أي حال من الأحوال ينبغي أن يكون آليا الشيكات الروتينية. نعم ، واختبارات القيادة إلى لا شيء.
لا تكشف أبداً عن قواعد اللعبة حتى النهاية.
لتكون في المقدمة ، تحتاج دائمًا إلى الحفاظ على زوج من ارسالا ساحقا. لا تخبر أحداً عن الحاجة إلى التوافق مع الإصدارات السابقة. من الأفضل أن نقول قبل الالتزام: "هنا ، وفقًا لقواعدنا ، يجب ضمان التوافق مع الإصدارات السابقة. يرجى تصحيح ". سيكون هذا فعالًا بشكل خاص إذا كنت قد راجعت بالفعل خمس مرات. فيما يتعلق بالسادس ، لا يزال بإمكانك أن يقول: "لست خبيراً ، لذا عليك الانتظار لمراجعة السيد X ، الذي سيبحث مرة أخرى."
مثل هذه التعليقات ، وخاصة في المرحلة الأخيرة من المراجعة ، تضيف دائمًا الدافع للمساهمين.
العواطف والسلطات وليس شكرا
تتداخل هذه النصيحة مع آخر نصيحة للمساهمين. اكتب التعليقات على طلب السحب عاطفيا قدر الإمكان. إذا لم يتم تحديد مكان ما في مكان فارغ أو لم يتم تسمية المتغير بهذه الطريقة ، فأضف العاطفة إلى تعليقاتك. دعهم يرون أنك تهتم.
إذا نشأ نزاع ، فلن تقدم حجج تقنية بأي حال من الأحوال. باستخدام الحجج التقنية ، قد يتضح أنك مخطئ. الرجوع إلى السلطات - هذه هي أفضل حجة في النزاع ، وسوف تفوز دائما.
إذا مر شخص ما بمراجعتك ، يجب ألا تقل شكراً لك. لا يزالون يريدون الالتزام بفتح المصدر! في أي حال من الأحوال لا يجب أن أشكر ، وبالتالي سوف يأتي مرة أخرى!
الآن بجدية: ما الذي يجب أن تفكر فيه عند إعداد وإجراء مراجعة الكود؟
آمل أن يفهم الجميع كيفية إجراء المراجعة واجتيازها؟ في كل من هذه النصائح ، بالإضافة إلى السخرية ، هناك ألم يحدث غالبًا في الممارسة.
سوف أكون قائد الدليل وأخبرك بما تحتاج حقًا إلى التفكير فيه عند إعداد مراجعة الكود وإجرائها. تنطبق الاعتبارات كذلك على كلٍّ من الذي يطور الميزة ، وعلى تلك التي ستراجعها. لا يزال ، هذه وجهان لعملة واحدة.
توافق الآراء في التواصل ، أولاً ، قابل للتحقيق ، وثانيًا ، من الضروري للمشروع أن يتحرك إلى الأمام. حاليا ، يمكن تطوير عدد قليل من المنتجات وحدها. عادة هذا هو العمل الجماعي.
استخدام الحس السليم
هذه هي النصيحة الأكثر أهمية. استخدام الحس السليم ، ويوجه. يبدو لي أن هذه النصيحة تنطبق على جميع مواقف الحياة. إذا كنت تفعل شيئًا ما ، فكر في ما إذا كان هذا يلبي القاعدة المنطقية البسيطة؟
افترض ...
هذا عن الثقافة. لقد كنت في مجتمع كبير مفتوح المصدر. لا أعرف ما إذا كان هذا جزءًا من العقلية الروسية ، ولكن غالبًا ما يُنظر إلى الشخص الذي يمكن اعتباره مدربًا على أنه شخص وقع في مكانه بالصدفة. من المعتقد أنه يريدك شيئًا سيئًا ، وهناك شكوك حول كفاءته المهنية. لذلك ، من المهم للغاية في أي عمل أن نفترض لثانية واحدة على الأقل ما يلي:
- المراجع (المساهم ، رئيسك أو زميلك) ليس عدوك . إنه لا يريدك أن تكون سيئًا. هذا افتراض بسيط ، ولكن في كثير من الأحيان لا يتم صنعه. أنصحه أن يفعل كل ذلك.
- الشخص الذي يكتب لك تعليقات هو أيضا مهندس جيد. أنت ، بالطبع ، جيد ، لقد صنعت هذه الميزة. ولكن هناك العديد من المهندسين الجيدين في العالم. الشخص الذي أرسل تعليقاتك ينطبق عليهم أيضًا.
- يريد هذا الشخص أيضًا إنجاز مهمتك.
عندما يسأل عن شيء ما ، لديه نوع من الحافز. يفعل ذلك لسبب ما. خاصة إذا كان هذا الشخص ليس اليوم الأول في المشروع. بالتأكيد هناك سبب ما. يمكنك أن تسأل عن هذا السبب: لماذا تحتاج إلى القيام بذلك؟ لماذا هناك حاجة للتوافق مع الإصدارات السابقة هنا؟ إذا قمت بطرح أسئلة بسيطة بهدوء ومعقول واستمع إلى الإجابات ، يمكنك تحقيق المزيد.
ما القيمة التي سيجلبها المنتج؟
الاستعراض ليس فقط تصحيحات جاهزة ، ولكن أيضا تحسينات المشروع ، التصحيحات. في الواقع ، تبدأ مراجعة الشفرة في الوقت الذي تناقش فيه مراجعتك. في هذه المرحلة ، اسأل نفسك: ما القيمة التي سيجلبها المنتج للمنتج؟
- هل ستكون ميزة جديدة؟
- هل هذا تحسن قائم؟
- تمديد ميزة موجودة؟
- هل سيكون إعادة بناء الكود؟ لا حرج في ذلك. البعض ينتقد إعادة البناء ، لكنه ضروري. وتحتاج إلى أن تدرك أنك تفعل ذلك ، وليس ميزة جديدة أو أي شيء آخر.
- هل تسريع العملية ، وتحسين الأداء؟
- هل هذا إصلاح الخلل؟
هناك خيارات أخرى. في أي حال ، البدء في تطوير شيء ما ، لحل مشكلة ، يجب أن تفهم القيمة التي ستضيفها إلى المشروع.
لماذا المراجعة (الميزة) مثل هذا؟
هناك عدد من الأسئلة المفيدة التي يجب طرحها.
لماذا جعل ميزة؟ لماذا هذه الميزة مطلوبة؟ الجواب على هذا السؤال مهم.
أين هي بداية العمل؟ في ممارستي ، حدث أنه طُلب مني إعادة تقديم طلب معين. هناك تطبيق A ، تحتاج إلى تقديم تطبيق B ، والذي يفعل الشيء نفسه تقريبًا مع التغييرات الطفيفة. أبدأ في القيام بالعمل واتضح أن A لا يعمل بشكل أساسي. في الواقع ، يتم استخدامه في مكان ما في الإنتاج باستخدام واجهة الإنسان والآلة - أي شخص يجلس ويعيد تشغيل البرنامج باستمرار ، مع إصلاح استثناء المؤشر الخالي حرفيًا على الهواء. أين هي بداية العمل؟ في هذه الحالة ، سيكون في تحديد البرنامج A بحيث يعمل بثبات ، ثم في كتابة البرنامج B.
أين هو الانتهاء الكامل من العمل؟ كيف ينبغي أن يكون العمل المنجز مثاليًا؟ من المهم أن تصاغ من البداية إلى أين أنت ذاهب.
أين هي نهاية المرحلة الحالية؟ من الواضح أنه لا يمكنك تناول فيل على الفور ومن الأفضل تقسيم العمل إلى مراحل. من المهم أن نفهم مكان نهاية المرحلة الحالية. غالبًا ما يتم تضخيم المشاريع ولا تنتهي فقط لأن نطاق المشروع يصبح كبيرًا بشكل لا نهائي.
لماذا يتم تقسيم الميزة بدقة في مثل هذه المراحل؟ هذا هو حول MVP وكل ذلك. يرجى التفكير في هذا أيضا.
الآن حول API العامة
هناك العديد من المقالات حول خصائص واجهة برمجة التطبيقات العامة. اقرأه قبل تنفيذه. كمثال جيد ، أستطيع أن أذكر إطار JQuery ، Spring في Java. هناك أيضا أمثلة سلبية. أولئك الذين كانوا يقومون بالبرمجة في Java لسنوات ، ربما يتذكرون فقط الرهيب من وجهة نظر Public API EJB 2.1. قد تكون الوظيفة جيدة ، لكن إذا كانت واجهة برمجة التطبيقات العامة سيئة ، فلا يمكن لأحد إقناع المستخدمين باستخدام المنتج.
واجهة برمجة التطبيقات العامة ليست مجرد أداة لمستخدمي الطرف الثالث. هذا وواجهة برمجة التطبيقات للمكونات الداخلية التي تعيد استخدامها بنفسك فيما بينها. الخصائص المهمة لواجهة برمجة التطبيقات العامة:
- البساطة.
- الأدلة.
- الإعدادات الافتراضية الصحيحة. يجدر التفكير فيها ، على سبيل المثال ، إذا قمت بإنشاء 500 مؤشر ترابط ، كما هو الحال في الإنتاج ، في بيئة اختبار. أو العكس ، في الإنتاج بشكل افتراضي هناك 3 مؤشرات ترابط ، كما هو الحال في بيئة اختبار.
- مسح رسائل الخطأ. هذه هي آفة الكثير من المنتجات. عندما يقع شيء ما داخل النظام ، فمن غير الواضح ما هو الخطأ. عملت أمس ، اليوم استثناء مؤشر فارغة. ما الخطأ الذي قمت به بالضبط وكيفية إصلاحه غير واضح من رسالة الخطأ.
- من الصعب ارتكاب خطأ. هناك الكثير من التوصيات بشأن هذه النتيجة. تعد عمليات التحقق من وقت الترجمة دائمًا أفضل من عمليات فحص وقت التشغيل ، إلخ.
- سجلات واضحة وكافية. هذا مهم بشكل خاص عند كتابة التعليمات البرمجية التي سيتم إعادة استخدامها ونشرها في مكان ما على الخادم.
- القدرة على مراقبة. يجب أن تفهم أن السجلات والمراقبة هي أيضًا جزء من واجهة برمجة التطبيقات العامة. عند تحليل الأخطاء ، سيرى المستخدمون كيف تتصرف المقاييس التي تبصقها في المراقبة.
تغييرات النظام الفرعي
عندما تأتي إلى مراجعة التعليمات البرمجية ، من المهم أن يكون لديك في رأسك قائمة كاملة من الأنظمة والأنظمة الفرعية لمنتج كبير تقوم بتغييره. في مشاريع المؤسسة ، قد لا يكون الأمر واضحًا: ما إذا كان مخطط قاعدة بيانات أو وحدة تحكم أو عرضًا تقديميًا أو نوعًا ما من أنظمة التقارير أو عمليات التحميل أو التنزيلات ، إلخ
عند العمل مع منتج محاصر ، من المهم أن تسأل نفسك السؤال التالي: كيف تؤثر التغييرات على العمليات الحالية في النظام؟ هل هناك توافق للخلف؟ هل يؤثر على الأداء؟ إذا كان يؤثر ، ثم أداء ماذا؟ كيف يؤثر هذا على تجربة المستخدم؟
عمليات النظام القياسية
يحتوي كل نظام عمل على عمليات قياسية: البدء ، التثبيت ، بعض قائمة العمليات. كيف سوف تتدفق الآن؟ قبل مراجعة الكود ، من المهم فهم ذلك. يجب أن تذهب من خلال التعليمات البرمجية التي تنفذ هذه العمليات. في حالة Ignite ، هذا هو:
- بدء / إيقاف العقدة (الخادم / العميل ، المنسق / العادي) - بدء أو إيقاف عقدة أو بدء خادم أو عقدة عميل أو بدء منسق أو عقدة عادية
- الانضمام إلى العقدة - من حيث عقدة / منسق / خادم / عميل جديد
- تنشيط الكتلة (وإلغاء تنشيط)
- تغيير المنسق
- إنشاء / حذف ذاكرة التخزين المؤقت
- الثبات / BLT / MVCC
من الواضح أن مجموعة هذه العمليات كبيرة جدًا. من المهم أن نفهم أن هذه العمليات موجودة وكيف تتغير.
الحالات الزاوية
في تطبيق عملك ، يمكن أن يحدث الاسترداد بعد عطل فادح والتهيئة الأولية للنظام وإغلاق العقدة وإعادة التشغيل وتحديث التطبيق وما شابه. في حالة Ignite ، لدينا الحالات الزاوية التالية:
- تغيير المنسق
- انخفاض العقدة
- مشاكل الشبكة - عندما لا تصل رسائل الشبكة ؛
- ملفات مكسورة.
يجب علينا التحقق من هذه الأشياء والتحقق من صحتها.
ميزات رمز جيد
لذلك وصلنا إلى الكود. أنصحك بأن لا تكون كسولًا وأن تسعى إليه:
- البساطة،
- المدودية قابلى المد
- قابلية الاختبار،
- دقة
- سرعة عالية في العمل.
التزامن
تتمتع Java بخصائصها الخاصة عند كتابة رمز التزامن. إذا كان لديك نظام أعمال ، وكان هناك القليل من التزامن ، فلن تحتاج إلى مراعاة هذه الميزات. ومع ذلك ، عادة ما يمر بعض التزامن عبر قاعدة البيانات. في أشياء مثل Ignite ، هذا أكثر تعقيدًا بقليل. وهنا ، ليس فقط مهمة الكود مهمة ، ولكن أيضا خصائصه:
- ما مدى صعوبة فهم نموذج التزامن الخاص بك؟
- بنية البيانات المشتركة - كيف يتم ضمان سلامتها؟
- أقفال - ماذا ولماذا؟
- المواضيع - التي تستخدم حمامات؟ لماذا؟
- ضمانات رؤية التغييرات - ما الذي تنص عليه؟
يجب طرح هذه الأسئلة قبل مراجعة رمز التزامن. من الواضح أن هذه القائمة يمكن أن تستمر لفترة طويلة جدًا.
اختبارات الأداء. المعايير
إذا كنت تقوم بتطوير نوع من النظام ، فإنه يحتوي على عملاء ومنشآت ، ومن الواضح أنه يعمل مع بعض الأداء. في عالم اليوم ، من المستحيل زيادة طاقة الأجهزة إلى أجل غير مسمى. نحن بحاجة إلى اختبارات ومراقبة الأداء. عند إجراء مراجعة الكود ، من المهم فهم:
- هل اختبار الأداء ضروري على الإطلاق؟ ربما هذا هو نوع من التحسين الذي لا يحتاج إلى اختبارات الأداء؟
- إذا لزم الأمر ، أي واحد؟ هناك العديد من تقنيات وطرق القياس ، إلخ.
- أين ، ماذا يحتاج إلى قياس؟
- ما هي المؤشرات الإرشادية؟ عدد العقد؟ الحديد؟ اشعال التكوين؟ طبيعة الحمل؟
في المجموع
عموما ، مراجعة الكود هي ممارسة مجزية للغاية. آمل أن يكون جميع المطورين (بما في ذلك منتجات المؤسسات) قد قاموا بالفعل بتطبيقه في المنزل. إذا لم يكن كذلك ، يرجى تنفيذها في أقرب وقت ممكن. سأكون سعيدًا لمناقشة ممارسات مراجعة التعليمات البرمجية معك في التعليقات.
فيديو المحاضرة:العرض التقديمي متاح هنا .