من مترجم: اليوم ننشر مقالًا لك عن طريق اختبار gamedev ذو الخبرة ريتشارد تايلور. ستكون المقالة مفيدة لكل من المبتدئين والمطورين ذوي الخبرة - هناك بالتأكيد شيء للنقاش هنا.
لقد خلقت العديد من الألعاب. عادة ما تكون المرحلة الأخيرة من التطور مؤلمة للغاية. بعد كل شيء ، في النهاية نواجه أخطاء ، وفقط بعد ذلك يمكننا إحضار اللمعان إلى المنتج تمامًا. يزداد الموقف سوءًا عندما يكون لدى المطور حد أدنى من الوقت لإكمال المشروع. عليك أن تعمل بسرعة ، والبق في هذه الحالة من الضيوف الدائمين. كيف يمكنني التعامل معهم؟ الأمر بسيط للغاية: ارتكاب أخطاء أقل ، هذا كل شيء (هذه هي مفارقة الكاتب - ملاحظة المترجم).
توصي Skillbox بما يلي: دورة تدريبية لمدة عامين "أنا مطور ويب للمحترفين" .
نذكرك: لجميع قراء "Habr" - خصم بقيمة 10،000 روبل عند التسجيل في أي دورة تدريبية في Skillbox باستخدام الرمز الترويجي "Habr".
تقليل عدد الأخطاء
نظرًا لأن جميع الأخطاء موجودة في الكود ، فربما يكفي أن تطلب من فريق التطوير أن يرتكب أخطاء أقل؟
إذا كنت مضحكا في هذا المكان ، فلن يفاجأ. وبالفعل ، لأنه لا يوجد أحد (حسنًا ، أو لا أحد تقريبًا) يفعلها بمحض إرادته. إذن ما الذي يمكن أن تقدمه للفريق لارتكاب أخطاء أقل في الكود بحيث لا توجد أخطاء فيه؟
نبدأ مشروع جديد. الخطوة الأولى - لا تكرر الأخطاء السابقة
لقد عمل فريقنا على العديد من مشاريع AAA. قبل البدء في إحداها ، قررنا طرح الأفكار حول موضوع "كيفية ارتكاب أقل عدد ممكن من الأخطاء". لم يرغب أي منا في قضاء الشهرين الماضيين في العمل في مشروع يبحث عن الأخطاء وإلغاء تحديد الكود. واحدة من المهام الرئيسية هي توزيع المسؤوليات والمسؤوليات. كل نوع من العمل تم تعيين كبير.
الخطوة الأولى هي أن تقرر لماذا كل هذا ضروري. يتم شرح "السبب" في المستوى العلوي ببساطة: نريد تقليل مقدار الوقت اللازم للتخلص من الأخطاء وتحسين التكاليف وتحسين الجودة الإجمالية للمشروع.
يتعلق الأمر بتوفير وقت لأداء المهام المهمة ، تلك التي تتيح لك الاستيقاظ في الصباح بسعادة والاستمرار في تنفيذ المهمة. هذا هو ما جعلنا جميع المطورين - فرصة لاستخدام وقتنا لأشياء رائعة حقًا!
بالمناسبة ، حتى لو كانت هناك مهمة واضحة لإنشاء عدد أقل من الأخطاء ، فمن الشائع للغاية أن تكون ببساطة بلا معنى. هذا هو بيان النوايا الذي يجب توضيحه وتقسيمه إلى سلسلة من المهام الواضحة الموجهة إلى أعضاء الفريق الفردي.
عند الإجابة على سؤال حول كيفية القيام بذلك ، من الضروري اتباع أساسيات الطريقة العلمية: الملاحظة ، الفرضية ، الاختبار ، التكرار.
الملاحظة
التصنيفافتح قاعدة بيانات الأخطاء الخاصة بأحدث مشروع وعرضه. هناك العديد من أنواع الأخطاء ، لذلك أقول فقط: عدد أقل من الأخطاء هو ببساطة عديمة الفائدة.
من أجل فهم المشكلة بشكل أفضل ، تحتاج إلى تحديد التفاصيل. بادئ ذي بدء ، من الضروري تقليل عدد هذه المشكلات ، التي يتطلب اكتشافها وحلها حدوث تقدم في الوقت.
تحليلبعد تجميع قائمة بأكثر الأخطاء التي تستغرق وقتًا ، فإن الخطوة التالية هي محاولة لإيجاد أرضية مشتركة في هذه الأخطاء ، وكذلك لفهم سبب ظهورها. تحليل وتفسير!
سبب المشكلةفي النهاية ، أنشأنا عددًا من القوالب للبحث عن أخطاء معينة ، مما جعل من الممكن فهم السبب في أن البحث والقضاء يستغرقان وقتًا طويلاً. بعد ذلك ، كنا مستعدين للذهاب إلى الكود المصدري للعثور على السبب الجذري للمشكلة.
بالعمل مع الأخصائيين الفنيين ، اكتشفنا المزيد من تغييرات الإصلاح. ثم قمنا بتجميع قوائم جديدة للأنظمة والملفات وخطوط التعليمات البرمجية المرتبطة بالأخطاء الرئيسية. في النهاية ، قمنا بعمل قائمة بالتغييرات الضرورية في الكود والتي يمكن مناقشتها مع فريق التطوير.
قلنا لك ذلك!ثم التقينا المبرمجين لمناقشة النتائج التي توصلنا إليها. كما اتضح فيما بعد ، كان الرجال على دراية بمعظم مناطق المشكلات في الكود. لكن إذا كان الأمر كذلك ، فما الهدف من عقد اجتماع؟
الإجابة: تمكنا من رسم موازٍ بين أماكن محددة في الكود وضياع الوقت المرتبط بهذه المشاكل. وهذا بدوره ، جعل من الممكن إجراء تقييم موضوعي لأي اقتراح لصيانة الكود.
وبالتالي ، قمنا بمراجعة أقسام الكود التي يمكن تسميتها سيئة. عندما قمنا بتقييمها من خلال أفضل ممارساتنا ، اتضح أننا نحتاج إلى إعادة البناء. في الوقت نفسه ، كان الفريق الهندسي قد تخلى عنها سابقًا لأن "هناك الكثير من العمل" أو "إنه ببساطة مستحيل".
في الواقع ، كانت العديد من المشاكل منهجية. أدت العديد من الجوانب "غير المرئية" إلى سلسلة من الأحداث التي تسببت في ظهور خطأ. بالمناسبة ، كانت أسباب المشاكل منهجية لدرجة أن المشروع كان يجب أن يبدأ من نقطة الصفر.
نتيجة لذلك ، جمعنا نتائج كافية من الملاحظات والتحليلات التجريبية من أجل تشكيل فرضيات. شارك الفريق بأكمله في هذه العملية.
الفرضيات
الفرضية 1. من المحتمل أن تؤدي أنماط الترميز المحددة إلى ظهور أخطاء في مشروع برنامج كبير.
الفرضية 2. يمكن تقليل الوقت اللازم لتصحيح الأخطاء في المشروع عن طريق تجنب أنماط السلوك المحددة في الفرضية الأولى.
دعنا نقرر ما هو المشروع الكبير. هذا هو حوالي 25 المبرمجين ، 12 شهرا من التنمية. العبارات التالية صحيحة بالنسبة له:
ج. أي رمز سوف يعيش لفترة كافية ، وبالتالي فإن تكلفة الصيانة سوف تتجاوز في نهاية المطاف تكلفة التطوير نفسه.
ب. تعقيد توصيل أنظمة المشروع الفردية أعلى من تعقيد نظام معين.
لماذا هذا مهم جدا؟ في المشروعات الصغيرة ، يمكنك التعامل مع كل شيء تقريبًا ، هنا هيكل البرنامج ليس مهمًا جدًا. الكود كله تحت تصرفك.
إذا كان المشروع كبيرًا ، فسيتغير كل شيء. يمكنك العمل باستخدام رمز لا تفهم غرضه ، وقد لا تعرف حتى أي جزء من المشروع ينتمي إليه موقع معين.
بعد مناقشتنا ، حصلنا على بيان النتائج هذا: "تشير البيانات إلى أن أنماط البرمجة المحددة هذه كانت عاملاً شائعًا يرتبط بمختلف الأخطاء / المشكلات. نعتقد أنه بتجنب هذه الأنماط ، يمكننا تقليل الوقت الذي يستغرقه إصلاح الأخطاء وفي نفس الوقت تحسين الجودة. "
الآن نبدأ في التنفيذ العملي.
اختبار
عند إنشاء مشروع جديد ، يجب تجنب أنماط الأخطاء المحددة. كان لدينا ذلك:
- المشغل التحميل الزائد وتسمية سيئة.
- السيارات ، وميزات متعددة الأشكال وإهمال سلامة النوع.
- زيادة تعقيد التعليمات البرمجية عن طريق ، على سبيل المثال ، حقن التبعيات وعمليات الاسترجاعات.
- باستخدام المزامير ، الإشارات ، وما شابه ذلك في رمز رفيع المستوى.
ما التالي؟
ثم أتيحت لنا الفرصة لبدء مشروع جديد ، وتطوير لعبة جديدة. تمكنا من إنشاء محرك ألعاب من البداية واستكمال كل شيء في الوقت المحدد ، مع فريق صغير نسبيا من المبرمجين. كان هناك عدد قليل من الأخطاء ، ولكن تبين أن الشفرة جيدة. في الوقت نفسه ، استغرق الأمر بعض الوقت لخدمة ذلك.
أصبح كل هذا ممكنًا لأننا لم نستخدم أنماطًا إشكالية ، كما لو أنها لم تعد موجودة. لقد حصلنا على شعار "تعقيد ظهور خطأ".
كان الفريق بأكمله سعيدًا بمثل هذه النتائج ، فقد أصبح العمل أكثر إثارة للاهتمام ، لأنه أصبح من الممكن مرة أخرى قضاء بعض الوقت في ما تحب.
توصي Skillbox بما يلي: