के विकास में KISS सिद्धांत

Pixonic DevGAMM टॉक्स की अगली रिपोर्ट, जिसे हमने डिक्रिप्ड किया है, थोड़ा दार्शनिक है - यह कॉन्स्टेंटिन ग्लैडीशेव का एक भाषण है। वह 1 सी गेम स्टूडियो में लीड गेम प्रोग्रामर थे और व्यक्तिगत विशेषताओं के बजाय संपूर्ण उत्पाद के संदर्भ में विकास जटिलता के प्रबंधन के सिद्धांत के बारे में बात करते थे। और उदाहरण के साथ, उन्होंने दिखाया कि विकास में मुख्य बात यह निर्धारित करना है कि क्या नहीं किया जाना चाहिए। अन्य रिपोर्टों के लिए, कृपया लेख के अंत में लिंक पढ़ें।


मैं उत्तर के बारे में बात करना चाहता था, लेकिन जो आसान होना चाहिए उस पर एक दार्शनिक रिपोर्ट बनाने का फैसला किया। मैंने पोस्टल III, अविनाशी, युद्ध रोबोट पर काम किया और वर्तमान में 1 सी और वॉरमिंग से ऑनलाइन सत्र शूटर कैलिबर कर रहा हूं।



क्यों हम KISS (यह आसान बेवकूफ रखें,) के बारे में बात करने का फैसला किया? क्योंकि 20 साल के अनुभव या सीटीओ वाले वरिष्ठ भी अक्सर किसी चीज को गढ़ना और उसका आविष्कार करना जारी रखते हैं। लेकिन आपको इसे आसान करने की आवश्यकता है। वास्तव में, YAGNI (आपको इसकी आवश्यकता नहीं है) और दर्शन की थोड़ी बहुत जानकारी है।

मुझे तुरंत कहना होगा कि हम पूरी तरह से मूर्खतापूर्ण समाधानों के बारे में बात नहीं कर रहे हैं, जैसे कि "एक्स खोजें", हम अधिक सरल समाधानों के बारे में बात कर रहे हैं।



कभी-कभी यह बहुत मुश्किल क्यों होता है? यह सब अच्छे इरादों के साथ शुरू होता है, और वे, जैसा कि आप जानते हैं, नरक में ले जाते हैं। यहाँ इस बारे में एक कॉमिक स्ट्रिप है।



इसके कारण लगभग समान हैं, लेकिन मैंने उन्हें अलग तरह से बुलाया:

• सार्वभौमिक समाधान । किसी प्रकार की सुविधा है और हम तुरंत एक पुस्तकालय बनाते हैं, एक लाख अतिरिक्त मामले। और फिर अचानक हमारा शूटर खेत में बदल जाएगा? या "अगली बार मैं उसी शूटर को एक और करूंगा।" यह संभावना नहीं है कि सबसे अधिक संभावना है कि यह आपके लिए बदल जाएगा।
• भविष्य का प्रमाण । लगभग एक ही चीज - ये गैर-मौजूद समस्याएं हैं। "और अगर मेरे पास एक मिलियन उपयोगकर्ता हैं, तो क्या मुझे 22 मध्यवर्ती सर्वरों का सामना करने की आवश्यकता है?" आदि कमाई शुरू करने के लिए, एक सर्वर आपके लिए पर्याप्त है।
• गलत साधनों का उपयोग करना । जब आप ऐसे उपकरणों का उपयोग करते हैं जो फिट नहीं होते हैं और आपके भ्रम में बने रहते हैं।
• और हर कोई समय से पहले अनुकूलन जानता है ।

हमारे पास एक उदाहरण था जब उन्होंने कैलिबर बनाया था। जो लोग हमारी मदद कर रहे थे, उन्होंने तुरंत नवीनतम C ++ में एक सुपरसिराइज़र बनाने का फैसला किया।

नतीजतन, यह वांछित के रूप में काम नहीं करता था, यह एक आंशिक राज्य भेजने के लिए असुविधाजनक था, क्योंकि टेम्पलेट वास्तव में यह नहीं समझते हैं कि यह कहाँ आवश्यक है, जहां यह नहीं है, या यदि आप कुछ झंडे बनाते हैं। कीड़े जो इस बॉयलरप्लेट कोड में थे, यहां तक ​​कि लेखक भी समय के साथ समझ में नहीं आया।



फिर केवल दो घंटों में प्रोग्रामर ने सी कोड के एक पेज पर इस सभी सामान को फिर से लिखा, जो कि तब हमें सही चाहिए था। और यह अद्भुत काम किया।

एक और उदाहरण। हमारे पास पोस्टल III था और इसे सोर्स इंजन पर बनाया गया था। इस तरह की एक खुली दुनिया है, आप नक्शे, एक तीसरे व्यक्ति के कैमरे, कई अमेरिकी शैली की एक-कहानी वाले घरों में खिड़कियां, बॉट के आसपास चल सकते हैं और खुले दरवाजे घबराहट कर सकते हैं। नतीजतन, पूरे बीएसपी ने काम नहीं किया। यह बहुत लंबे समय के लिए माना जाता था, खिड़कियों के कारण यह एक लाख सेक्टर निकला और फिर भी कुछ नहीं किया। इसने बहुत सारी मेमोरी ली और लंबे समय तक लोड किया।



हाफ-लाइफ, जिसके लिए इंजन बनाया गया था, एक प्रथम-व्यक्ति शूटर है, और तीसरे से कुछ चीजें करने के लिए असुविधाजनक था। हाफ-लाइफ से उपयोगी हर चीज हमें बिल्कुल पसंद नहीं थी। साथ ही, बड़ी मात्रा में एनीमेशन किया जाना चाहिए था, क्योंकि तीसरे व्यक्ति से आपको चढ़ाई करने की आवश्यकता होती है, आदि। इंजन को बदलना आवश्यक था, लेकिन तब कोई विकल्प नहीं था।

क्या करें जब सब कुछ खराब हो, मुश्किल हो, लेकिन वे हमें धक्का देते हैं? सबसे पहले, सही क्रम में सुविधाएँ करना, क्योंकि समय से पहले अनुकूलन करना समस्याओं में से एक है। कुछ लोग ड्रेस सिलने से पहले स्ट्रैसिक से चिपकना शुरू कर देते हैं, और फिर वे सिलाई नहीं कर पाते, क्योंकि स्ट्रैज़िक्स हस्तक्षेप करते हैं।

सबसे पहले, सबसे सरल चिप बनाओ ताकि यह बस काम करे, फिर स्थिर हो, और फिर अनुकूलन करें। यह इस क्रम में है कि बाकी सब गलत है।



विज़ुअलाइज़ेशन द्वारा, हम समझते हैं कि यह न्यूनतम परिचालन है, अर्थात। एमवीपी (न्यूनतम व्यवहार्य उत्पाद)।



तब आप इसकी क्षमता का मूल्यांकन करते हैं। मान लें कि गेम डिजाइनर सुविधाओं के साथ आते हैं, प्रोग्रामर रिसॉर्ट्स और कहते हैं "मैं अच्छा करूँगा, मैं बुरा नहीं करूँगा, इसलिए तुरंत एक फंकी गेम डिज़ाइन तैयार करें।" लेकिन वह कैसे जानता है? वह नहीं खेलता था, यह नहीं जानता था कि यह अच्छा था या बुरा। इसलिए, आदर्श रूप से, आप एक सुविधा बनाते हैं, खेलते हैं, यदि सामान्य है, तो इसे आगे करें। सामान्य नहीं - बाहर फेंका गया, दया नहीं।

एक हजार साल पहले, सूर्य त्ज़ु ने कहा था कि 100 लड़ाई जीतने के लिए चोटी नहीं है, शिखर को बिना लड़ाई के जीतना है। यानी जो आप नहीं कर सकते, वह मत करो।

स्थिरीकरण। आपने सुविधाओं को बनाया है और अनावश्यक परिवर्धन के बिना इसे और अधिक स्थिर किया है। क्या आपको पेड़ पर, रस्सी पर पहिया की आवश्यकता है? यह लटका हुआ है। और कुछ नहीं।



तदनुसार, यदि अचानक यह पता चला (बिना किसी भविष्य के प्रमाण के) कि सुविधा बदलनी चाहिए - फिर से शुरू करें। बस प्रोटोटाइप, स्थिर, और आगे अनुमान लगाने की कोशिश मत करो। फिर भी आप अनुमान नहीं लगा सकते।

खैर, समय से पहले अनुकूलन। यह हमेशा खराब होता है। आपको बहुत ही अंत में अनुकूलन करने की आवश्यकता है, जब आप यह सुनिश्चित करने के लिए जानते हैं कि यह सुविधा महत्वपूर्ण है, तो इसे अनुकूलित किया जाना चाहिए और निकट भविष्य में यह मौलिक रूप से नहीं बदलेगा।



क्योंकि अनुकूलन विशेष मामलों का एक समूह है। कोड की पठनीयता बिगड़ती है, सार टूटता है और पोर्टेबिलिटी, एक नियम के रूप में, बहुत बिगड़ जाती है।



यह एक उत्तेजक स्लाइड है, क्योंकि बैसाखी वास्तव में खराब हैं। लेकिन यहां स्थिति को दिखाया गया है जब सुस्त सुविधाओं और प्रोटोटाइप का एक गुच्छा है, सब कुछ खराब है, और ऐसा लगता है कि सब कुछ ढह जाएगा। लेकिन ऐसा है नहीं। देखो - यह फॉर्मवर्क है, इसमें कंक्रीट डाला जाता है, और "बैसाखी" को गिरा दिया जाता है जबकि यह सूख जाता है। यानी स्थिति बिल्कुल सामान्य है, "बैसाखी" को फिर से हटा दिया जाएगा, लेकिन बिना घबराए तुरंत नहीं।

दर्शन के बारे में संक्षेप में। कोई सार्वभौमिक रूप से वैध समाधान नहीं हैं। 100 साल पहले या सभी अवसरों के लिए एक रूपरेखा बनाने की कोशिश न करें।



बेहतर है कि बहुत सारे छोटे टुकड़े करें जो अपना काम अच्छी तरह से करते हैं। जितनी जल्दी हो सके अनावश्यक को फेंक दें, इसका समर्थन करने की कोशिश न करें। और कोड लिखते समय, इसे स्पष्ट करें। कभी-कभी यह स्पष्ट कोड लिखना बेहतर होता है कि आप अपने हाथों से पलटा या किसी और चीज़ के बजाय सीरियल करें। जब आपको इसकी आवश्यकता नहीं होती है तो निर्भरता क्रिया का उपयोग करना भी एक बुरा विचार है। इसे पढ़ना बहुत कठिन है, रनटाइम में आधी त्रुटियां। निहितार्थ की तुलना में स्पष्ट है। और गलतियों से बचने के लिए जितना संभव हो उतना सरल बनाएं जब कोई व्यक्ति कुछ नहीं समझता है या पूरी तरह से भूल गया है।

जैसा कि ब्रूस ली ने कहा, सादगी कला की उच्चतम डिग्री है। एक बार एक अभिनेता जिसे उन्होंने अपने जीन कुने-डो को सिखाया था, उनसे पूछा: "आपकी मार्शल आर्ट जीत कुन-डू का सार क्या है?" उस क्षण में, ब्रूस ली ने अपना बटुआ गिरा दिया, अभिनेता ने उसे उठाया और ब्रूस ली ने कहा: "आप देखते हैं, आप बस नीचे झुकते हैं और बटुआ उठाते हैं, और यदि आप सवार की मुद्रा में खड़े होते हैं, तो काटा, आपने इसे कभी नहीं उठाया होगा।"

श्रोताओं से सवाल

"आपने कहा था कि समयपूर्व अनुकूलन बुराई है।" क्या यह समय से पहले परीक्षण के लायक है जब एक परियोजना बस शुरू हो रही है?

- मेरी समझ में, समय से पहले सब कुछ हानिकारक है। परीक्षणों में, मैं बहुत मजबूत नहीं हूं, क्योंकि खेल विकास में (कई मामलों में), परीक्षण विकास के अंत के करीब हैं। शुरुआत में, सब कुछ इतनी तेज़ी से बदलता है कि जब आप एक परीक्षण लिख रहे होते हैं, तो गेम डिजाइनर पहले से ही सब कुछ बदल देगा। मेरा मानना ​​है कि दो घंटे में क्या बदलेगा, इसका परीक्षण पर ऊर्जा खर्च करना बुरा है। यह स्थिरीकरण चरण में किया जाना चाहिए। लेकिन प्रोटोटाइप स्टेज पर नहीं। लेकिन अगर टीम जल्दी से परीक्षण लिख सकती है, तो यह शायद अच्छा है। यदि नहीं, तो नहीं।

- आपने उल्लेख किया है कि बैसाखी हटा दी जाएगी, लेकिन एक अद्भुत थीसिस है - अस्थायी से अधिक स्थायी कुछ भी नहीं है। हम सभी खेल देव में काम करते हैं, हमारे पास समय सीमा, निर्माता, फिर एक नई सुविधा और इतने पर हैं। आपने कितनी बार ऐसी स्थिति देखी है जहां आप बैसाखी की सफाई कर रहे थे? और क्या वे उन्हें शून्य पर ले गए?

- शायद शून्य पर नहीं। यदि परियोजना लाइव है, तो आपके पास हमेशा कुछ बैसाखी होगी। यह सब काम करता है अगर उन्हें व्यवस्थित रूप से साफ किया जाए। यानी आपने एक सुविधा बनाई - तुरंत रिकॉर्ड की गई।

- यानी। क्या कंपनी में एक निश्चित प्रक्रिया का निर्माण किया जाना चाहिए? आधिकारिक बैसाखी सफाई चरण का प्रकार?

- हां, मेरा मानना ​​है कि इसे टास्क में शामिल किया जाना चाहिए। यानी यदि आपको कार्य की प्रक्रिया में रिफ्लेक्टर की आवश्यकता है - आप रिफ्लेक्टर को। मोटे तौर पर, यहां तक ​​कि रिफैक्टिंग शब्द भी नहीं है - यह कार्य के अंदर है।

- क्या आप व्यवहार में ऐसा करने का प्रबंधन करते हैं? आप निर्माता के पास आते हैं और एक नई यात्रा की योजना बनाने पर कहते हैं कि हमें सफाई, रिफ्लेक्टर आदि के लिए दो सप्ताह की आवश्यकता है। और वह कहता है कि व्यवसाय का मूल्य शून्य है, अब हम फीचर एक्स करते हैं, और फिर आप काम के बाद शाम को इसे साफ करेंगे। इस स्थिति में कैसे रहें?

- हम सफल हुए। निर्माता को पता है कि कुछ ऋण हैं जो आप सही कर रहे हैं, लेकिन समय पर ढंग से। ऐसा नहीं है कि आपके पास एक नई रिलीज़ है, इसमें एक भी नई सुविधा नहीं है, लेकिन यहां कुछ प्रकार की रिफ्लेक्टरिंग है। बस सही निर्माता चुनें।

"अनुभव के साथ, समझ में आता है, बेहतर सरल।" लेकिन नौसिखिए प्रोग्रामर जटिल, डरावने, बड़े और विशाल सिस्टम बनाने की कोशिश करते हैं। प्रश्न: उन्हें इस से कैसे रखा जाए, सिवाय एक कठिन "नहीं" के?

- मुझे लगता है कि यह सीखने की समस्या है। यह संभव के रूप में जल्दी दिखाने के लिए आवश्यक है जो समाधान काम करते हैं, जो नहीं करते हैं, और क्यों। जब आपके पास अनुभव होता है और आप समझा सकते हैं कि आपको ऐसा करने की आवश्यकता क्यों नहीं है, तो आप बहुत सारे उदाहरण दे सकते हैं और यह पहले से ही अच्छी तरह से काम करता है। अपने स्वयं के उदाहरण के साथ दिखाने और लगातार निगरानी करने के लिए ताकि सब कुछ सरल हो। प्रोटोटाइप पर रखें ताकि वे अधिक बार फिर से लिखें - जब आप अक्सर फिर से लिखते हैं, तो आपको ऐसा नहीं लगता कि बहुत कुछ लिखना है और वे अधिक से अधिक बस लिखते हैं।

- अगर पहले से ही बहुत कुछ जटिल है जो कई परियोजनाओं पर उपयोग किया जाता है, और यह जटिलता अब और मदद नहीं करती है, बल्कि हस्तक्षेप करती है - सरल समाधानों पर स्विच करना कितना आसान है?

- मेरी राय है, बस इसे फिर से करना शुरू करें। आदर्श रूप से, खरोंच से सही एक अलग टीम। सबसे अधिक संभावना है कि आप 80% कार्यक्षमता को बहुत जल्दी ठीक कर लेंगे। एक नए और स्वच्छ पुस्तकालय पर। और तब तुम पकड़ोगे।

- उदाहरण के लिए, कुछ शक्तिशाली धारावाहिक और गेम लॉजिक के संपादक हैं, अब यह काफी पुराना है ...

- ये समान असुविधाजनक उपकरण हैं। आराम से ले जाओ। उदाहरण के लिए एकता।

- मुझे बताओ, कोड में आपकी योजना क्या है, यह कितना विस्तृत है? क्या मुख्य प्रोग्रामर सभी छोटे मुद्दों, सभी कार्यों को हल करता है?

- हमारे पास ऐसी अराजकता है, काफी सपाट संरचना है, बहुत सारे लोग नहीं हैं। हम सभी पर भरोसा करते हैं और बस वितरित करते हैं कि कौन प्रोटोटाइप ले जाएगा और कौन नहीं। यह कोई भी मनमाना व्यक्ति हो सकता है।

Pixonic DevGAMM वार्ता के साथ अधिक वार्ता

• कंसूल का उपयोग राज्य स्तरीय सेवाओं (इवान बुबनोव, BIT.GAMES में DevOps) के लिए;
• CICD: डाउनटाइम (Egor Panov, Pixonic सिस्टम एडमिनिस्ट्रेटर) के बिना वितरित क्लस्टर सिस्टमों में निर्बाध तैनाती ;
• क्वेक चैंपियंस गेम के बैकएंड प्लेटफ़ॉर्म में अभिनेता मॉडल का उपयोग करने की प्रथा (रोमन रोजोज़िन, बैकएंड डेवलपर कृपाण इंटरएक्टिव);
• टैक्टिकूल मोबाइल ऑनलाइन शूटर मेटा सर्वर आर्किटेक्चर (पावेल प्लाटो, पैंजरडॉग में लीड सॉफ्टवेयर इंजीनियर);
• कैसे ECS, C # जॉब सिस्टम और SRP आर्किटेक्चर के लिए दृष्टिकोण को बदलते हैं (वैलेंटाइन साइमनोव, फील्ड इंजीनियर एट यूनिटी);
• क्लाइंट और सर्वर पर सामान्य गेम लॉजिक (एंटोन ग्रिगोरिव, पिक्सेल में उप तकनीकी अधिकारी)।
• क्लाउड में ककड़ी: उत्पाद तनाव परीक्षण के लिए बीडीडी लिपियों का उपयोग करना (एंटोन कोसयाकिन, एलिस प्लेटफॉर्म पर तकनीकी उत्पाद प्रबंधक)।