आपको बग्स को खत्म करने की आवश्यकता नहीं है, लेकिन उनकी उपस्थिति का कारण: गेम डेवलपर से एक मामला

अनुवादक से: आज हम आपके लिए अनुभवी gamedev परीक्षक रिचर्ड टेलर द्वारा एक लेख प्रकाशित कर रहे हैं। लेख शुरुआती और अनुभवी डेवलपर्स दोनों के लिए उपयोगी होगा - यहां चर्चा करने के लिए निश्चित रूप से कुछ है।

मैंने कई गेम बनाए हैं। आमतौर पर विकास का अंतिम चरण बहुत दर्दनाक होता है। आखिरकार, यह अंत में है कि हम बग का सामना करते हैं, और उसके बाद ही हम पूरी तरह से उत्पाद में चमक ला सकते हैं। जब डेवलपर के पास प्रोजेक्ट पूरा करने के लिए न्यूनतम समय होता है, तो स्थिति बिगड़ जाती है। आपको जल्दी से काम करना होगा, और इस मामले में बग लगातार मेहमान हैं। मैं उनसे कैसे निपट सकता हूं? यह बहुत सरल है: कम गलतियाँ करने के लिए, यह सब है (यह लेखक की विडंबना है - अनुवादक द्वारा ध्यान दें)।

स्किलबॉक्स सलाह देता है: दो साल का व्यावहारिक कोर्स "मैं एक प्रो वेब डेवलपर हूं । "

हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रचारक कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।

बग की संख्या कम करें

चूंकि सभी बग कोड में हैं, तो क्या यह संभवतः विकास टीम को कम गलतियां पूछने के लिए पर्याप्त है?

यदि आप इस स्थान पर मजाकिया हैं, तो मुझे आश्चर्य नहीं होगा। और वास्तव में, क्योंकि कोई भी (अच्छी तरह से, या लगभग कोई नहीं) उन्हें अपनी मर्जी से करता है। तो आप टीम को कोड में कम गलतियां करने के लिए क्या पेशकश कर सकते हैं ताकि इसमें कोई कीड़े न हों?

हम एक नई परियोजना शुरू करते हैं। एक कदम - पिछले त्रुटियों को दोहराएं नहीं

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

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

यह दिलचस्प कार्यों को करने के लिए समय खाली करने के बारे में है, जो आपको सुबह खुशी से जागने और तुरंत कार्य के कार्यान्वयन की अनुमति देते हैं। यह वही है जो हमें सभी डेवलपर्स बनाता है - वास्तव में शांत सामान के लिए हमारे समय का उपयोग करने का अवसर!

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

यह कैसे करना है के सवाल का जवाब देते समय, वैज्ञानिक पद्धति की मूल बातों का पालन करना आवश्यक है: अवलोकन, परिकल्पना, परीक्षण, पुनरावृत्ति।

देख

वर्गीकरण

अपने नवीनतम प्रोजेक्ट का बग डेटाबेस खोलें और इसे देखें। कीड़े की कई किस्में हैं, इसलिए बस कह रही है: कम त्रुटियां बस बेकार हैं।

समस्या को बेहतर ढंग से समझने के लिए, आपको बारीकियों को निर्धारित करने की आवश्यकता है। सबसे पहले, उन समस्याओं की संख्या को कम करना आवश्यक है, जिनके पता लगाने और समाधान के लिए समय की सफलता की आवश्यकता होती है।

के विश्लेषण

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

समस्या का कारण

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

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

हमने आपको ऐसा कहा था!

तब हमने अपने निष्कर्षों पर चर्चा करने के लिए प्रोग्रामरों के साथ एक बैठक की। जैसा कि यह पता चला, दोस्तों को कोड में अधिकांश समस्या क्षेत्रों के बारे में पता था। लेकिन अगर ऐसा है, तो बैठक होने की बात क्या थी?

उत्तर: हम कोड में विशिष्ट स्थानों और इन समस्याओं से जुड़े समय के नुकसान के बीच एक समानांतर खींचने में कामयाब रहे। और यह, बदले में, कोड रखरखाव के लिए किसी भी प्रस्ताव का निष्पक्ष मूल्यांकन करना संभव बनाता है।

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

वास्तव में, कई समस्याएं प्रणालीगत थीं। कई "अदृश्य" पहलुओं ने उन घटनाओं की एक श्रृंखला का नेतृत्व किया जो एक त्रुटि की उपस्थिति का कारण बने। वैसे, समस्याओं का कारण इतना व्यवस्थित था कि परियोजना को खरोंच से शुरू करना पड़ा।

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

परिकल्पना

परिकल्पना 1. विशिष्ट कोडिंग पैटर्न एक बड़े सॉफ्टवेयर प्रोजेक्ट में कीड़े की उपस्थिति के लिए नेतृत्व करने की संभावना है।

परिकल्पना 2. किसी परियोजना में त्रुटियों को ठीक करने के लिए आवश्यक समय को पहली परिकल्पना में परिभाषित व्यवहार के पैटर्न से बचाकर कम किया जा सकता है।

आइए तय करें कि एक बड़ी परियोजना क्या है। यह लगभग 25 प्रोग्रामर, 12 महीने का विकास है। निम्नलिखित कथन उसके लिए सत्य हैं:
A. कोई भी कोड लंबे समय तक जीवित रहेगा, इसलिए रखरखाव की लागत अंततः विकास की लागत से अधिक होगी।
B. व्यक्तिगत परियोजना प्रणालियों को जोड़ने की जटिलता किसी विशेष प्रणाली की जटिलता से अधिक है।

यह इतना महत्वपूर्ण क्यों है? छोटी परियोजनाओं में, आप लगभग हर चीज से सामना कर सकते हैं, यहां कार्यक्रम संरचना इतनी महत्वपूर्ण नहीं है। कोड आपके निपटान में है।

यदि परियोजना बड़ी है, तो सब कुछ बदल जाता है। आप एक ऐसे कोड के साथ काम कर सकते हैं जिसका उद्देश्य आपको समझ में नहीं आता है, आप यह भी नहीं जानते होंगे कि किसी विशेष साइट से संबंधित परियोजना का कौन सा हिस्सा है।

हमारी चर्चा के बाद, हमें परिणामों का यह बयान मिला: “डेटा दिखाते हैं कि ये विशिष्ट प्रोग्रामिंग पैटर्न विभिन्न बग / समस्याओं से जुड़े एक सामान्य कारक थे। हमारा मानना ​​है कि इन पैटर्न से बचकर, हम त्रुटियों को ठीक करने में लगने वाले समय को कम कर सकते हैं और साथ ही गुणवत्ता में सुधार कर सकते हैं। ”

अब हम व्यावहारिक कार्यान्वयन शुरू करते हैं।

परीक्षण

एक नया प्रोजेक्ट बनाते समय, आपको पहचाने गए बग पैटर्न से बचना चाहिए। हमारे पास यह था:

• ऑपरेटर ओवरलोडिंग और खराब नामकरण।
• ऑटो, बहुरूपी सुविधाएँ और प्रकार की सुरक्षा की उपेक्षा।
• उदाहरण के लिए, कोड जटिलता बढ़ाना, निर्भरता और कॉलबैक को इंजेक्ट करना।
• उच्च स्तरीय कोड में म्यूटेक्स, सेमाफोर और जैसे का उपयोग करना।

आगे क्या है?

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

यह सब संभव हो गया क्योंकि हमने समस्याग्रस्त पैटर्न का उपयोग नहीं किया, जैसे कि वे अब मौजूद नहीं थे। हमने यहां तक ​​कहा कि मंत्र "एक गलती की उपस्थिति की शिकायत करें।"

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

स्किलबॉक्स अनुशंसा करता है:

• व्यावहारिक पाठ्यक्रम "वेब डेवलपर का व्यवसाय" ।
• ऑनलाइन कोर्स "प्रोफेशन फ्रंटेंड-डेवलपर । "
• व्यावहारिक वार्षिक पाठ्यक्रम "पीएचपी-डेवलपर 0 से प्रो तक" ।