डब्ल्यूटीएफ प्रति घंटे

कवि की आत्मा अस्पष्टता को सहन नहीं कर सकती है, और वह उदारतापूर्वक अपने उदात्त विचारों को साझा करता है। (c) अनाम

कुछ समय पहले मैंने अपने सपनों की वास्तुकला के लिए समर्पित तीन लेख "एक मोबाइल गेम के लिए वास्तुशिल्प समाधान" लिखे:
• भाग 1: मॉडल
• भाग 2: कमान और उनकी कतार
• भाग 3: जेट प्रणोदन पर देखें

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

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

इस तरह की अवधारणा "निकटतम विकास के क्षेत्र" के रूप में है: यह उन कार्यों की सामग्री से निर्धारित होता है जो एक व्यक्ति अभी तक अपने दम पर हल नहीं कर सकता है, लेकिन किसी ऐसे व्यक्ति के साथ संयुक्त गतिविधि में हल करने में सक्षम है जो पहले से ही इस बाधा को ले चुका है। वह जो शुरू में दूसरों की भागीदारी के साथ एक व्यक्ति के लिए सुलभ है, फिर उसका अपना अधिकार (कौशल, योग्यता) बन जाता है। इसलिए, यह सबसे उपयोगी है, ज़ाहिर है, एक दिलचस्प परियोजना पर एक मजबूत नेता के साथ मिलकर काम करने के लिए। लेकिन मुझे सभी परियोजनाएं कहां मिल सकती हैं, और इससे भी ज्यादा।

सामान्य तौर पर, इस सब के बारे में सोचते हुए, मैं एक अलग प्रारूप में लोगों के साथ साझा करने का प्रयास करना चाहता था: मैं कोड समीक्षा के लिए समर्पित एक स्ट्रीम की व्यवस्था करूंगा, मैं अपना कोड प्रतिक्रियात्मकता के लिए समर्पित दिखाऊंगा और उन विचारों को समझाऊंगा जो इसमें निर्धारित किए गए हैं और क्यों इसे इस तरह से लिखा गया है और नहीं अन्यथा। धारा ठीक एक घंटे तक चलेगी। यहां लेख में मैं संक्षेप में बताऊंगा कि मैं किस बारे में बात करना चाहता हूं, और फिर इस तथ्य के बाद कि मैं समय जोड़ूंगा और किन मुद्दों पर चर्चा करने में कामयाब रहा और किस मिनट से।

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

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

धारा बुधवार को 22:30 बजे शुरू होगी (यह मेरा खाली समय है, अफसोस। :) और यहां उपलब्ध होगा:

अब स्ट्रीम के कंटेंट के बारे में।

सामान्य तौर पर, प्रतिक्रियाशीलता का एक अच्छा कार्यान्वयन यूनिआरएक्स पुस्तकालय में है, जिसे मैं दृढ़ता से परिचित होने की सलाह देता हूं। शायद आप इसे सचमुच अपने लिए ले जाएंगे, या हो सकता है कि बस वहाँ से विचारों को मिटा दें। लेकिन मैं अपनी खुद की बाइक दिखाऊंगा, जिसे खरोंच से लिखा गया है। यह केवल इसलिए नहीं है क्योंकि मुझे साइकिल से प्यार है। UniRX में, मानक सिस्टम इंटरफेस को लागू करता है। IObserver <T> और System.IObservable <out T> में। और कई स्थानों पर थ्रेडसेफ़ ऐसा करता है (हमेशा सही ढंग से नहीं) और आंतरिक। यही है, पुस्तकालय में बहुत सारे अतिरिक्त कोड हैं, और इसका विस्तार करना असुविधाजनक है। वास्तव में, मुझे तीन में से तीन मामलों में स्थानीय स्थितियों का विस्तार और अनुकूलन करने की आवश्यकता थी।

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

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

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

IObserver के साथ दूसरी समस्या यह है कि मैं लेन-देन परिवर्तन चाहता हूं। बस कल्पना करें कि सूची एक स्रोत से आती है, और दूसरी धारा से हमें तत्व का सूचकांक मिलता है, जिसे हमें शीट से निकालना होगा और पास करना होगा। और यहां सूचकांक अंतिम तत्व की ओर इशारा करता है, और यहां एक तत्व हटा दिया जाता है, और सूचकांक 1. घट जाता है। अंत में, सबकुछ ठीक हो जाएगा और ऑपरेशन का परिणाम नहीं बदलेगा, लेकिन अगर हमें सूची में परिवर्तन के बारे में एक संदेश प्राप्त होता है और केवल तब सूचकांक के परिवर्तन के बारे में एक संदेश, हमारे कोड एक IndexOutOfRangeException को पकड़ लेगा। वास्तव में, जिस क्रम में परिवर्तन लागू किए जाते हैं, उसी समस्या को दर्जनों अन्य तरीकों से प्रकट किया जा सकता है, यह केवल सबसे स्पष्ट है।

इसलिए, मैं एक ओर Onrrr को खींचे बिना एक तरफ अपना इंटरफ़ेस चाहता हूं, लेकिन दूसरी तरफ जिसमें .OnTransaction (ITransaction t) है।

कुछ मुझे बहुत गहरा लगता है। स्क्रीन पर कोड के साथ एक धारा के दौरान इसके बारे में बात करना स्पष्ट रूप से तेज़ होगा, और बहुत अधिक समझने योग्य होगा। सबसे ऊपर के बारे में आगे:

• मेरे इंटरफेस IActive और IReactive हैं। वे किसी भी घटना से अधिक सुंदर कैसे होते हैं और उनके उपयोग का अंतिम परिणाम कैसा दिखता है।
• ActiveProperty <T>। Active.Proxy <T> से क्या अंतर है, एक चर का प्रारंभिक मूल्य कैसे संचरित होता है और इसे कैसे संसाधित किया जाता है।
• मैं परीक्षणों के साथ यह सब कैसे जांचूं और यह बहुत सुविधाजनक क्यों है। वास्तव में, बिना परीक्षण के ऐसी बात लिखना संभव नहीं होगा।
• हाउसकीपिंग की रणनीति OnComplete और ICollection <IDisposible> दोनों का समर्थन करने वाला दोहरा तंत्र
• टूलकिट एक्सटेंशन को आसानी से स्ट्रीमिंग और सबसे उपयोगी उदाहरणों को पढ़ने के लिए कैसे करें।
• यह सब गड़बड़ के लिए उपकरण डिबगिंग। सबसे पहले .लोग (), और हम अगली बार कुछ समय के लिए कैलकुलेट्री तक पहुँचेंगे।
• Active.Proxy <T> कोड का सावधानीपूर्वक पढ़ना, हुड के तहत कोई भी घटना क्यों नहीं है, लेकिन एक दोहरी लिंक की गई सूची है।
• IActiveList और IActiveDictionary, सबसे पहले आम विचारों।
• ViewModel, नियंत्रक और दृश्य में विभाजित कैसे करें। कैसे अपनी धाराओं को लूप न करें।
• एक मॉडल के लिए प्रतिक्रियाशीलता से चर छोड़ने की प्रक्रिया।
• ActiveList और सक्रिय डेल्टा न्यूनतम डेल्टा के साथ। विशेष रूप से और सामान्य तौर पर UniRX में डेल्टा रिटेल के ललाट कार्यान्वयन के विपरीत।
• कोड में त्रुटियों को सुधारने के लिए सामान्य रणनीति, क्योंकि विश्वविद्यालयों में ऐसा कोई विषय नहीं है, लेकिन होना चाहिए।

वास्तव में, पहले से ही कई घंटे की कहानियां और कोड शो हैं, तो चलो पहले घंटे से शुरू करते हैं, और फिर कैसे रौंदते हैं।

PS यह मेरी पहली धारा होगी, इसलिए यदि कोई तकनीकी समस्या हो तो कड़ाई से न्याय न करें।