التقرير التالي من محادثات Pixonic DevGAMM ، الذي قمنا بفك تشفيره ، هو فلسفي قليلاً - هذا خطاب كونستانتين غلاديسشيف. كان مبرمجًا للعبة الرائدة في 1C Game Studios وتحدث عن مبدأ إدارة تعقيد التطوير في سياق المنتج بأكمله ، بدلاً من الميزات الفردية. ومع الأمثلة ، أظهر لماذا الشيء الرئيسي في التنمية هو تحديد ما لا يجب القيام به. لتقارير أخرى ، يرجى قراءة الروابط في نهاية المقالة.
كنت أرغب في الحديث عن الشمال ، لكنني قررت إعداد تقرير فلسفي حول ما يجب القيام به بشكل أسهل. لقد عملت على Postal III و Indestructible و War Robots وأعمل حاليًا Caliber ، وهي جلسة إطلاق نار على الإنترنت من 1C و Wargaming.
لماذا قررنا التحدث عن KISS (اجعلها بسيطة ، غبية)؟ لأنه حتى كبار السن الذين لديهم 20 عامًا من الخبرة أو CTO غالبًا ما يستمرون في نحت وابتكار شيء ما. ولكن عليك أن تفعل ذلك بسهولة. في الواقع ، هناك المزيد عن YAGNI (لن تحتاجها) وقليلاً من الفلسفة.
يجب أن أقول على الفور أننا لا نتحدث عن حلول غبية تمامًا ، مثل "find x" ، نحن نتحدث عن حلول بسيطة أكثر أو أقل.
لماذا يكون الأمر صعبًا في بعض الأحيان؟ كل شيء يبدأ بنوايا حسنة ، وكما تعلمون ، تؤدي إلى الجحيم. هنا شريط فكاهي عن هذا.
أسباب ذلك هي نفسها تقريبًا ، لكنني اتصلت بها بشكل مختلف:
- حلول عالمية . هناك نوع من الميزات ونقوم على الفور بإنشاء مكتبة منها ، مليون حالة إضافية. ثم فجأة سيتحول مطلق النار لدينا إلى مزرعة؟ أو "في المرة القادمة سأقوم بعمل نفس مطلق النار بالضبط." من غير المحتمل أن يتغير ذلك بالنسبة لك.
- دليل المستقبل . تقريبا نفس الشيء - هذه مشاكل غير موجودة. "وإذا كان لدي مليون مستخدم على الفور ، فهل أحتاج إلى تحمل 22 خادمًا وسيطًا؟" الخ. لبدء الربح ، يكفي خادم واحد.
- استخدام الأدوات الخاطئة . عندما تستخدم أدوات لا تناسبك وتستمر في الوهم.
- والجميع يعرفون التحسين المبكر .
كان لدينا مثال عندما صنعوا عيار. قرر الرجال الذين كانوا يساعدوننا في ذلك أن يقوموا على الفور بعمل حلقة فاصلة في أحدث إصدار من C ++.
ونتيجة لذلك ، لم يعمل على النحو المطلوب ، كان من غير المناسب إرسال حالة جزئية ، لأن القوالب لا تفهم حقًا المكان الذي تكون فيه ضرورية ، أو حيث لا تكون كذلك ، أو إذا قمت بعمل بعض العلامات. الخلل التي كانت في هذا الرمز المعياري ، حتى المؤلف لم يفهم بمرور الوقت.
ثم قام أحد المبرمجين في ساعتين فقط بإعادة كتابة كل هذه الأشياء على صفحة واحدة من كود C ، والتي فعلت ما نحتاجه في ذلك الوقت. وعملت بشكل رائع.
مثال آخر. كان لدينا البريد الثالث وتم إجراؤه على محرك المصدر. هناك مثل هذا العالم المفتوح ، يمكنك المشي بين الخرائط ، وكاميرا من منظور شخص ثالث ، والعديد من المنازل ذات الطابق الواحد ذات الطراز الأمريكي مع النوافذ ، ويمكن للسير الآلي الجري والفتح على الأبواب. ونتيجة لذلك ، لم يعمل BSP بأكمله. تم النظر فيه لفترة طويلة جدًا ، نظرًا لأن النوافذ تحولت إلى مليون قطاع ولم تفعل شيئًا بعد. استهلك الكثير من الذاكرة وتحميلها لفترة طويلة.
Half-Life ، التي تم صنع المحرك من أجلها ، هي مطلق النار من منظور شخص أول ، ومن الثالثة كان من غير المناسب القيام ببعض الأشياء. كل شيء مفيد من Half-Life لم يناسبنا على الإطلاق. كان من المفترض أيضًا تنفيذ كمية كبيرة من الرسوم المتحركة ، لأنه من شخص ثالث تحتاج إلى التسلق ، إلخ. كان من الضروري تغيير المحرك ، ولكن بعد ذلك لم يكن هناك خيار.
ماذا تفعل عندما يكون كل شيء سيئًا وصعبًا ، لكنهم يدفعوننا؟ أولاً ، تنفيذ الميزات بالترتيب الصحيح ، لأن التحسين مقدمًا يمثل إحدى المشكلات. يبدأ البعض في لصق ستراسيك قبل أن يخيطوا الثوب ، ثم لا يمكنهم الخياطة ، لأن الأشرطة تتدخل.
أولاً ، قم بعمل أبسط رقاقة بحيث تعمل فقط ، ثم تستقر ، ثم تحسن. بهذا الترتيب كل شيء آخر خاطئ.
من خلال التصور ، نفهم أنه يعمل في الحد الأدنى ، أي أفضل منتج قابل للتطبيق.
ثم تقيم إمكاناتها. لنفترض أن مصممي الألعاب قد توصلوا إلى الميزات ، والمنتج المبرمج يقول "سأبلي بلاءً حسناً ، ولن أفعل سيئًا ، لذلك ارسم فورًا تصميمًا غير تقليدي للعبة". لكن كيف يعرف؟ لم يلعب ، لم يكن يعرف ما إذا كان جيدًا أم سيئًا. لذلك ، من الناحية المثالية ، يمكنك إنشاء ميزة ، واللعب ، إذا كان ذلك طبيعيًا ، ثم القيام بذلك. ليس طبيعيا - طرد ، وليس شفقة.
قبل ألف سنة ، قال سون تزو إن الفوز بـ 100 معركة ليس الذروة ، فالقمة هي الفوز بدون معركة. على سبيل المثال لا تفعل ما لا تستطيع فعله.
الاستقرار. لقد قمت بعمل الميزات واستقرارها دون إضافات غير ضرورية. هل تحتاج لعجلة على شجرة على حبل؟ إنها معلقة. لا أكثر.
وفقًا لذلك ، إذا اكتشف فجأة (بدون أي دليل مستقبلي) أن الميزة يجب أن تتغير - ابدأ مرة أخرى. مجرد نموذج أولي واستقرار ولا تحاول تخمين المستقبل. لا تزال لا تخمن.
حسنًا ، التحسين المبكر. هذا أمر سيئ دائمًا. تحتاج إلى التحسين في النهاية ، عندما تعرف على وجه اليقين أن هذه الميزة مهمة ، يجب تحسينها ولن تتغير جذريًا في المستقبل القريب.
لأن التحسين هو مجموعة من الحالات الخاصة. تزداد قراءة الرمز سوءًا ، كما تتعطل التجريد وقابلية النقل ، كقاعدة عامة ، إلى حد كبير.
هذه شريحة استفزازية ، لأن العكازات سيئة حقًا. ولكن هنا يظهر الموقف عندما يكون هناك مجموعة من الميزات والنماذج الباهتة ، وكل شيء سيئ ، ويبدو أن كل شيء سينهار. لكن الأمر ليس كذلك. انظر - هذا هو القوالب ، ويتم صب الخرسانة فيه ، ويتم دعم "العكازات" أثناء تجفيفها. على سبيل المثال الوضع طبيعي تمامًا ، سيتم بعد ذلك إزالة "العكازات" ، ولكن ليس على الفور بدون ذعر.
باختصار حول الفلسفة. لا توجد حلول صالحة عالميا. لا تحاول إنشاء إطار عمل لمدة 100 عام مقدمًا أو لجميع المناسبات.
من الأفضل صنع الكثير من القطع الصغيرة التي تؤدي وظيفتها بشكل جيد. تخلص من ما هو غير ضروري في أقرب وقت ممكن ، لا تحاول دعمه. وعند كتابة التعليمات البرمجية ، اجعلها صريحة. في بعض الأحيان ، من الأفضل كتابة رمز صريح تقوم بتسلسله بيديك ، بدلاً من التفكير أو أي شيء آخر. استخدام إجراء التبعية عندما لا تكون بحاجة إليه هو أيضًا فكرة سيئة. من الصعب جدًا قراءة نصف الأخطاء في وقت التشغيل. صريح أفضل من ضمني. واجعل الأمر بسيطًا قدر الإمكان لتجنب الأخطاء عندما لا يفهم شخص ما شيئًا أو حتى ينسى تمامًا.
كما قال بروس لي ، البساطة هي أعلى درجة من الفن. ذات مرة سأله ممثل قام بتدريسه جيت جيت كون دو: "ما هو جوهر فنك القتالي جيت جيت كون دو؟" في تلك اللحظة ، أسقط بروس لي محفظته ، التقطها الممثل وقال بروس لي: "كما ترون ، لقد انحنيت للتو والتقطت المحفظة ، وإذا وقفت في وضع متسابق ، صنعت كاتا ، لما رفعتها أبدًا."
أسئلة من الجمهور
"لقد قلت أن التحسين المبكر أمر شرير." هل يستحق كتابة اختبارات مبكرة عندما يبدأ المشروع للتو؟- حسب فهمي ، كل شيء سابق لأوانه ضار. في الاختبارات ، لست قويًا جدًا ، لأنه في تطوير اللعبة (في كثير من الحالات) ، تكون الاختبارات أقرب إلى نهاية التطوير. في البداية ، يتغير كل شيء بسرعة كبيرة لدرجة أنه أثناء كتابة الاختبار ، سيغير مصمم اللعبة كل شيء بالفعل. أعتقد أنه من السيئ إنفاق الطاقة على اختبار لما سيتغير خلال ساعتين. يجب أن يتم ذلك في مرحلة الاستقرار. ولكن ليس في مرحلة النموذج الأولي. ولكن إذا تمكن الفريق من كتابة الاختبارات بسرعة ، فربما يكون ذلك جيدًا. إذا لم يكن كذلك ، فلا.
- ذكرت أنه سيتم إزالة العكازات ، ولكن هناك أطروحة رائعة - لا يوجد شيء أكثر ديمومة من المؤقت. كلنا نعمل في تطوير اللعبة ، ولدينا مواعيد نهائية ، ومنتجون ، ثم ميزة جديدة وما إلى ذلك. كم مرة رأيت فيها حالة كنت تنظف العكازات؟ وهل أخذوها إلى الصفر؟- ربما ليس عند الصفر. إذا كان المشروع مباشرًا ، فستجد دائمًا بعض العكازات. كل شيء يعمل إذا تم تنظيفها بشكل منهجي. على سبيل المثال قمت بعمل ميزة - سجلت على الفور.
- على سبيل المثال هل يجب بناء عملية معينة في الشركة؟ نوع مرحلة تنظيف العكاز الرسمية؟- نعم ، أعتقد أنه يجب تضمين هذا في المهمة. على سبيل المثال إذا كنت بحاجة إلى إعادة بناء في المهمة - أنت إعادة بناء. بشكل تقريبي ، حتى كلمة إعادة البيع ليست كذلك - إنها داخل المهمة.
- هل تنجح في القيام بذلك عمليا؟ أتيت إلى المنتج وتقول بشأن التخطيط لتكرار جديد نحتاجه أسبوعين للتنظيف وإعادة البناء وما إلى ذلك. ويقول أن قيمة العمل هي صفر ، والآن نقوم بتمييز س ، ثم ستقوم بتنظيفها في وقت لاحق في المساء بعد العمل. كيف تكون في هذا الموقف؟- نجحنا. يدرك المنتج أن هناك بعض الديون التي تقوم بتصحيحها ، ولكن في الوقت المناسب. ليس الأمر أن لديك إصدارًا جديدًا ، وليس به ميزة جديدة واحدة ، ولكن إليك نوعًا من إعادة الهيكلة. ما عليك سوى اختيار المنتج المناسب.
مع الخبرة ، يأتي الفهم ، كلما كان ذلك أبسط كلما كان ذلك أفضل. " لكن المبرمجين المبتدئين يحاولون إنشاء أنظمة معقدة ومخيفة وكبيرة وضخمة. السؤال: كيف تمنعهم من ذلك ، باستثناء "لا" الثابت؟- أعتقد أن هذه مشكلة تعليمية. من الضروري أن نوضح في أقرب وقت ممكن الحلول التي تعمل ، والتي لا تعمل ، ولماذا. عندما تكون لديك خبرة ويمكنك أن توضح لماذا لا تحتاج إلى القيام بذلك ، يمكنك فقط تقديم الكثير من الأمثلة وهو يعمل جيدًا بالفعل. إظهار ومراقبة بمثالك الخاص بحيث يكون كل شيء بسيطًا. ارتدي نماذج أولية بحيث تتم إعادة كتابتها كثيرًا - عندما تعيد الكتابة كثيرًا ، لا تشعر بالرغبة في الكتابة كثيرًا والكتابة ببساطة أكثر.
- إذا كان هناك بالفعل شيء معقد للغاية يستخدم في العديد من المشاريع ، وهذا التعقيد لم يعد يساعد بعد الآن ، بل يتدخل - ما مدى سهولة التحول إلى حلول بسيطة؟- في رأيي ، فقط ابدأ في فعل ذلك مرة أخرى. من الناحية المثالية ، فريق منفصل ، من الصفر. على الأرجح ستستعيد 80٪ من الوظائف بسرعة كبيرة. في مكتبة جديدة ونظيفة. ثم ستلحق بالركب.
- على سبيل المثال ، هناك بعض المتسلسلات القوية ومحرر منطق اللعبة ، والآن أصبح قديمًا جدًا ...- هذه هي نفس الأدوات غير الملائمة. خذ الراحة. الوحدة ، على سبيل المثال.
- قل لي ، ما هو تخطيطك في الكود ، ما مدى تفصيله؟ هل المبرمج الرئيسي يحل جميع القضايا الصغيرة ، كل المهام؟- لدينا مثل هذه الفوضى ، وهي بنية مسطحة إلى حد ما ، وليس الكثير من الناس. نحن نثق في الجميع ونوزع ببساطة من سيأخذ النموذج الأولي ومن لن يفعل. يمكن أن يكون أي شخص تعسفي.
المزيد من المحادثات مع محادثات Pixonic DevGAMM