चौखटे बनाने में अनुभव

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

हमें रूपरेखा की आवश्यकता क्यों है?

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

विकास या बढ़ती प्रौद्योगिकी के अंक

थोड़ा सा हम कैसे एक नई तकनीकी दिशा में उभर रहे हैं। समय-समय पर, प्लेटफार्मों ने बदलाव का इस्तेमाल किया और आपको इन नए उत्पादों के लिए प्रौद्योगिकी का निर्माण करना होगा।

बाल विहार

इस तथ्य के कारण कि हमारा उत्पाद एक पूर्ण अनुप्रयोग नहीं है, एक प्रोटोटाइप परियोजना (1-3 पीसी।) के लिए किसी भी विषय क्षेत्र को पहले चुना गया है। यह एप्लिकेशन केवल उन समाधानों और दृष्टिकोणों को सत्यापित करने के लिए कार्य करता है जिन्हें हम कार्यान्वित करने की योजना बनाते हैं। मज़े के लिए, आखिरी ऐसी प्रणाली जिसका हमने इस्तेमाल किया, वह थी घरेलू बिल्लियों को अपार्टमेंट में रखने के लिए। प्रोटोटाइप की एक विशेषता यह है कि कोड बल्कि मिश्रित है और यह स्पष्ट नहीं है कि तकनीकी परत कहां है, और जहां लागू तर्क पहले से ही शुरू हो रहा है। इस "बिल्ली" परियोजना पर, सभी आवश्यक घटकों, जनरेटर, उपयोगकर्ता इंटरफ़ेस तत्वों पर काम किया जा रहा है। प्रोजेक्ट पर केवल टेक्नोलॉजिस्ट काम करते हैं।

स्कूल का समय

जब किसी और गंभीर चीज के लिए तकनीक की कोशिश करने का समय आता है, तो वाणिज्यिक लोगों से एक "बलिदान" परियोजना का चयन किया जाता है। एक नियम के रूप में, इसकी 1.5 - 2 गुना लंबी अवधि होती है जिसे एक विशिष्ट परियोजना की तुलना में विकास के लिए अलग रखा जा सकता है (हर कोई समझता है कि जोखिम हैं, क्योंकि हम पहली बार प्रौद्योगिकी का उपयोग करते हैं और कंपनी खुद तकनीकी कार्यों के लिए भुगतान करती है, नहीं ग्राहक)। इस तरह की परियोजना की एक विशेषता यह है कि तकनीकी कोड शुरू में समाधान में होता है, और जैसा कि इसे विकसित किया जाता है, इसे तकनीकी परियोजनाओं और एप्लिकेशन कोड (जो विषय क्षेत्र पर निर्भर करता है) में विभाजित किया गया है। टेक्नोलॉजिस्ट और एप्लाइड प्रोग्रामर दोनों प्रोजेक्ट पर काम कर रहे हैं। यह समझा जाना चाहिए कि अभी भी बुनियादी दृष्टिकोण डिबगिंग है और प्रौद्योगिकी में सब कुछ 100% तैयार नहीं है, इसलिए परियोजना जन्मजात "साइकिल" के साथ होगी जो समर्थन को जटिल बनाती है। कभी-कभी इन "साइकिल" को मानक तकनीकी समाधानों के साथ बदल दिया जाता है, कभी-कभी वे अंत तक बने रहते हैं।

उच्च शिक्षा

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

व्यावसायिक विकास

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

निवृत्ति

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

मुद्दे का तकनीकी पक्ष

अब तकनीक और तकनीक के बारे में थोड़ा। यह Microsoft .NET फ्रेमवर्क के बारे में होगा, क्योंकि हमारे समाधान इस प्लेटफ़ॉर्म पर बनाए गए हैं।

विस्तार अंक

प्रौद्योगिकी को प्रोग्रामर को सीमित नहीं करना चाहिए, लेकिन खरोंच से एक समाधान पर लाभ देना चाहिए, और कभी-कभी पूरी तरह से टर्नकी समाधान। प्रोग्रामर के लिए अपने व्यक्तित्व को दिखाने के लिए जहां तकनीक "बहुत मानक" है, हम निम्नलिखित तरीकों का उपयोग करते हैं:
• वंशानुक्रम। एक आधार वर्ग है जो मानक व्यवहार को लागू करता है और तकनीकी विधानसभा में स्थित है। एप्लिकेशन प्रोजेक्ट के लिए उत्पन्न कोड बेस क्लास से विरासत में मिला है और विशेष तरीकों में मानक व्यवहार को बदलना शामिल है।
• घटनाएँ। प्रौद्योगिकी वर्गों में घटनाओं की एक श्रृंखला होती है, जिसके प्रसंस्करण से आप व्यवहार को बदल सकते हैं। यह याद रखना चाहिए कि एक घटना को कई बार सब्सक्राइब किया जा सकता है।
• प्रत्यायोजित करता है। घटनाओं के समान, लेकिन केवल एक कार्यान्वयन हो सकता है। यह कई बार अनचाहे ऑपरेशन को रोकता है।
• App.config। विभिन्न छोटी चीजें कॉन्फ़िगरेशन फ़ाइल में मिलती हैं। एक नियम के रूप में, ये कुछ झंडे और पथ हैं (क्या डिबगिंग जानकारी लिखना आवश्यक है, कनेक्शन स्ट्रिंग्स सेवाओं के लिए, आदि)।
• डीआई। इस विकल्प में पूरे मॉड्यूल को ओवरराइड करना शामिल है।

इवेंट लॉगिंग

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

XML टिप्पणियाँ

प्रक्रिया कोड में XML टिप्पणियाँ महत्वपूर्ण हैं। सार्वजनिक कक्षाओं, विधियों और गुणों के लिए उन्हें निर्धारित करना आवश्यक है। यह मदद की पीढ़ी (http://sandcastle.codeplex.com/) की अनुमति देगा और IntelliSense के लिए आवेदन परियोजनाओं में सुझाव प्रदान करेगा। टिप्पणियों के साथ xml-file उत्पन्न करने के लिए प्रोजेक्ट सेटिंग्स में इंगित करना न भूलें।

ब्रेकिंग चेंजेस

प्रौद्योगिकी में इस तरह का बदलाव अत्यंत दुर्लभ है, जिसे प्रौद्योगिकी परत को अपडेट करने के लिए एप्लिकेशन प्रोग्रामर के हस्तक्षेप की आवश्यकता होती है। यदि इस तरह के अद्यतन की भविष्यवाणी की जा सकती है, तो आपको पहले से ही चेतावनी देने की आवश्यकता है, उदाहरण के लिए, अप्रचलित विशेषता का उपयोग करके:
[अप्रचलित ("यह फ़ंक्शन अगले संस्करण में हटा दिया जाएगा, फ़ंक्शन का उपयोग करें")]
कभी-कभी आपको अपनी लीड का पालन करना होता है और नियम को लागू करना होता है: "2 बार अपडेट की तुलना में 1 बार जोड़ना बेहतर होगा", अर्थात यदि प्रत्येक एप्लिकेशन प्रोजेक्ट में 1000 स्थानों पर विधि हस्ताक्षर का उपयोग किया जाता है, तो इसे तकनीक में बदलना एक अच्छा विचार नहीं है। सबसे महत्वपूर्ण नियम: हमेशा अद्यतन के साथ संभावित समस्याओं का विस्तृत विवरण - चेतावनी दी, फिर सशस्त्र।

कुछ दस्तावेज़ीकृत

तकनीकी असेंबलियों के लिए, प्रलेखन की उपलब्धता अत्यंत महत्वपूर्ण है। जानकारी संग्रहीत करने के लिए, हम प्रौद्योगिकीविदों के लेखन पहुंच के साथ एक विकी इंजन का उपयोग करते हैं। जानकारी बनाए रखने के लिए, 2 नियम लागू होते हैं:
1. किया - विकी को लिखें!
2. प्रश्न का उत्तर दिया - विकी में लिखें!
विवरण स्तर:
1. अपने लिए (व्यवस्था के अनुसार)
2. लागू परियोजनाओं के प्रोग्रामर के लिए (तरीकों और कक्षाओं का उपयोग कैसे करें)
3. सिस्टम उपयोगकर्ताओं के लिए (घटकों का उपयोग कैसे करें)

ढांचा परियोजना संरचना

कभी-कभी परियोजनाओं के लिए जारी किए गए विधानसभाओं की संख्या को कम करना आवश्यक होता है। यह आपको गलत अपडेट से निपटने की अनुमति देता है जब आपको एक साथ कई विधानसभाओं को अपडेट करने की आवश्यकता होती है, अन्यथा कुछ काम नहीं करेगा और उस जोखिम को कम कर देगा जो वे ग्राहक को कुछ स्थापित करने के लिए भूल जाते हैं। हालाँकि, अलग-अलग प्रोजेक्ट्स के लिए अलग-अलग कार्यों की आवश्यकता होती है। क्या लगाया जा सकता है?
1. परियोजनाओं के बीच सीएस-फाइलों के लिए लिंक (परियोजनाओं के साथ काम थोड़ा जटिल है)
2. ILMerge (इसे बिल्ड सर्वर को सौंपा जा सकता है, लेकिन डिबगिंग मुश्किल है)
3. संसाधनों में असेंबली (एक अलग विधानसभा लोडिंग तंत्र के साथ)

विधानसभाओं या मजबूत नाम पर हस्ताक्षर करना

एक अन्य लौह नियम: सभी तकनीकी विधानसभाओं पर हस्ताक्षर किए जाने चाहिए। इससे हमें निम्नलिखित लाभ मिलते हैं:
1. हस्ताक्षरित विधानसभाओं को GAC में विशिष्ट रूप से पहचाना जाता है
2. आप केवल तभी हस्ताक्षर कर सकते हैं जब सभी आश्रित असेंबलियों पर हस्ताक्षर किए जाते हैं (यदि आवेदन असेंबली हस्ताक्षरित नहीं हैं तो अनुप्रयोग असेंबली हस्ताक्षर नहीं कर सकते हैं)
3. कुछ हद तक सुरक्षा (कोड को बदलने के लिए, आवेदन के सभी बिल्ड को फिर से बनाना आवश्यक होगा)
यदि ऐसा होता है कि असेंबली से कोड खो गया है, तो असेंबली का पुनर्निर्माण करके हस्ताक्षर किए जा सकते हैं। Reassembly इस तरह से किया जाता है (एक कुंजी के साथ एक फ़ाइल निर्दिष्ट करने के लिए, एक विशेष पैरामीटर देखें)
1. aildasm.exe sampleA.exe / source /out:sampleA.il
2. Iilasm.exe sampleA.il / exe /out:sampleA.exe

संस्करण की रणनीति

अधिक बार उत्पाद जारी किया जाता है, यह उपयोगकर्ताओं को कम लगता है कि प्रोग्रामर कुछ भी नहीं करते हैं। हमने तकनीकी उत्पाद संस्करणों की रिलीज़ के 2 संस्करणों का परीक्षण किया:
1. नवीनतम बिल्ड सबसे अच्छे हैं
SourceControl में रखा गया सब कुछ सिद्ध माना जाता है और एप्लिकेशन प्रोग्रामर तकनीकी असेंबली का कोई भी सर्वर बिल्ड ले सकते हैं। उसी समय, प्रौद्योगिकीविदों को प्रत्येक चेक-इन से पहले अपने परिवर्तनों को सावधानीपूर्वक जांचना चाहिए।
पेशेवरों:
• तत्काल परिवर्तन पोस्टिंग
विपक्ष:
• प्रत्येक चेक-इन को बहुत अधिक कार्यक्षमता वाले विस्तारित चेक की आवश्यकता होती है जो पीड़ित हो सकता है
• त्रुटियां ग्राहक के संस्करण में आसानी से घुसपैठ कर सकती हैं
2. स्थिर संस्करण की आवधिक रिहाई
आवधिक आधार पर तकनीकी असेंबली के एक संस्करण का विमोचन।
पेशेवरों:
• अधिक विश्वसनीय एकीकरण सत्यापन
विपक्ष:
• पुनरावृति के बीच में कोड का नियंत्रण खोने का जोखिम है
• सब कुछ फिर से जांचने में समय लगता है, कोई त्वरित सुधार नहीं
1-2-दिवसीय संस्करण की रिलीज़ के दौरान, सभी टेक्नोलॉजिस्ट जांच की गई त्रुटियों को जांचने और सही करने से विचलित होते हैं। यह वह विकल्प है जिसका हम वर्तमान में उपयोग कर रहे हैं।

विधानसभा संस्करण

बिल्ड संस्करणों के नामकरण के लिए 2 रणनीतियाँ हैं:
1. परिवर्तनीय बिल्ड संस्करण
• केवल परियोजना की पुन: स्थापना के साथ लागू परियोजनाओं को अद्यतन करना (ग्राहक को सीधे प्रौद्योगिकी में एक पैच भेजने में असमर्थता)
• समस्याओं का एक हिस्सा संकलन के दौरान दिखाई देगा (विधानसभाओं के बीच जटिल निर्भरता के लिए प्रासंगिक)
• प्रकार के क्रमांकन के साथ एक समस्या (विधानसभा संस्करणों को अपडेट करते समय ग्राहक पर संग्रहीत क्रमबद्ध डेटा समस्या पैदा कर सकता है)
2. फिक्स्ड बिल्ड संस्करण
• विधानसभाओं का एक सरल प्रतिस्थापन अद्यतन करें
• समस्याएँ स्टार्टअप पर दिखाई देंगी क्योंकि नवीनीकरण के दौरान पुनर्संयोजन की आवश्यकता नहीं है
• केवल एक निश्चित विधानसभा को अंतिम उपाय के रूप में ग्राहक को भेजा जा सकता है
पहचान के लिए सशर्त संस्करण के रूप में विधानसभा की रिलीज की तारीख
हमारी टीम दूसरे विकल्प पर आ गई क्योंकि अक्सर लागू परियोजनाओं पर नई तकनीकी असेंबलियों की जांच करना आवश्यक है, और उन्हें फिर से स्थापित करने की कोई इच्छा या समय नहीं है। हमने टीम फाउंडेशन सर्वर में सर्वर बिल्ड कॉन्फ़िगर किया है और कार्यान्वयन के लिए केवल सर्वर बिल्ड को स्थानांतरित किया जा सकता है।

ब्रांचिंग: पेशेवरों और विपक्ष

स्रोत कोड संग्रहण को व्यवस्थित करने के लिए हमने 2 दृष्टिकोणों पर विचार किया:
सुविधाओं को जोड़ने के लिए शाखाएं, कार्यान्वयन के लिए शाखाएं
प्लस:
• आप सीधे इच्छित संस्करण में एक छोटा सा बदलाव कर सकते हैं
कम:
• आपको बहुत सारे कोड मर्ज करने की आवश्यकता है
शाखाओं के बिना एकल संस्करण
प्लस:
• कोई विलय नहीं
कम:
• एक असंतुष्ट संस्करण को जल्दी से ठीक नहीं किया जा सकता है।
हम एक सरल दूसरे विकल्प पर बस गए। हम चेक-इन के बिना दीर्घकालिक परिवर्तन नहीं करने की कोशिश करते हैं, लेकिन चेक-इन को हमारे समाधान के प्रदर्शन को बर्बाद नहीं करना चाहिए।

बाहरी विधानसभाएं

एक वाणिज्यिक उत्पाद में OpenSource के बारे में कुछ शब्द: यदि आप चाहें, तो आप किसी भी वांछित कार्य को हल करने के लिए एक अच्छा लाइसेंस के साथ OpenSource समाधान पा सकते हैं। हालांकि, इस तरह का निर्णय लेते समय, आपको इस बारे में कठोर सोचना चाहिए कि वहां कैसे बदलाव किए जाएंगे:
1. स्थानीय रूप से सब कुछ संपादित करें
प्लस:
• आप कुछ भी कर सकते हैं
कम:
• आधिकारिक संस्करण को अपडेट करते समय, आपको अपने परिवर्तनों को स्वयं मर्ज करना होगा
2. प्रोजेक्ट सपोर्ट टीम को अपडेट भेजें
प्लस:
• सुधारों की अतिरिक्त गुणवत्ता जांच
विपक्ष:
• जो जोखिम समर्थन करता है वह बंद हो जाएगा
• एम। बी। लंबे समय से जाँच और रिलीज़ फिक्स
• सुधारों को एक कारण या किसी अन्य के लिए अस्वीकार किया जा सकता है।
कभी-कभी आपको केवल भुगतान किए गए समाधान के पक्ष में चुनाव करना पड़ता है क्योंकि परिवर्तन करने की नीति (कम से कम त्रुटियों को ठीक करना) उस लाइसेंस में तय की जाती है जिसके लिए पैसे का भुगतान किया जाता है।

कहानियो

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

परीक्षण

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

निष्कर्ष

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