एक सॉफ्टवेयर डेवलपर के लिए दस सिफारिशें

एकीकृत सॉफ्टवेयर सिस्टम का विकास आवश्यकता के कारण महत्वपूर्ण कठिनाइयों से जुड़ा है:

क) प्रणाली का तेजी से प्रोटोटाइप,

ख) अपने मॉडल और स्रोत कोड की गुणवत्ता सुनिश्चित करना,

ग) प्रणाली के जीवन के दौरान परिवर्तन करना।



निम्नलिखित दस सिफारिशें हैं जो डेवलपर्स को उनके कठिन पथ पर एकीकृत सिस्टम बनाने में मदद करेंगी।





1. आधुनिक सॉफ्टवेयर विकास प्लेटफार्मों की शक्ति का दोहन



जिस समय आपकी प्रणाली शुरू की गई थी उस समय पुराने प्लेटफॉर्म पर निर्भर न हों या पुरानी हो जाएं।



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



2. एप्लिकेशन डिज़ाइन को गंभीरता से लें



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



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



3. ऑब्जेक्ट डोमेन और यूजर इंटरफेस विरासत का उपयोग करें



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



डोमेन ऑब्जेक्ट्स के लिए, इनहेरिटेंस आपको ऑब्जेक्ट्स की सामान्य विशेषताओं और कार्यक्षमता को परिभाषित करने में मदद करेगा।



उपयोगकर्ता इंटरफ़ेस के लिए, वंशानुक्रम स्क्रीन रूपों के सामान्य घटकों (यह जीत या वेब फॉर्म हो) को परिभाषित करने में उपयोगी होगा।



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



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



4. अलग व्यावसायिक तर्क और उपयोगकर्ता इंटरफ़ेस



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



यह "अनुबंध" भविष्य में सिस्टम मॉडल में महत्वपूर्ण बदलाव करते समय आपकी मदद करेगा।



5. आपका सिस्टम व्यापार-स्तरीय वस्तुओं के परस्पर क्रिया का एक सेट होना चाहिए , जब तक कि परमाणु विस्फोट इसके साथ मॉडलिंग नहीं करते हैं, निश्चित रूप से



यह सॉफ्टवेयर विकास के लिए एक वस्तु-उन्मुख दृष्टिकोण का मूल सिद्धांत है। आप डोमेन ऑब्जेक्ट के लिए कक्षाएं लिखते हैं और उन्हें संदेशों का आदान-प्रदान करने के लिए मजबूर करते हैं (एक दूसरे से सार्वजनिक तरीकों को कॉल करें)। इस प्रकार, आवश्यक सिस्टम कार्यक्षमता प्राप्त की जाती है।



उदाहरण के लिए, आपको "ओके" बटन पर क्लिक करने पर स्क्रीन रूप में डेटाबेस में संपादित ऑब्जेक्ट को सहेजना होगा। आपका बटन हैंडलर कोड इस तरह दिखना चाहिए:



{

संपादन योग्य वस्तु। सहेजें ();

}



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



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



6. ऑब्जेक्ट, कंपोनेंट्स और सबसिस्टम में अपने सिस्टम की कार्यक्षमता को इनकैप्सुलेट करें



एक अच्छी तरह से परिभाषित कार्यक्षमता को प्राप्त करने के लिए एक साथ काम करने वाले वर्गों का एक सेट एक घटक और एक इंटरफ़ेस (यानी, सम्मेलनों और संदेश भेजने वाले हस्ताक्षर का एक सेट) के साथ बातचीत के लिए घोषित किया जाना चाहिए।



भविष्य में, यदि सिस्टम में परिवर्तन करते समय इंटरफ़ेस अपरिवर्तित रहता है, तो आप सिस्टम के बाकी हिस्सों को प्रभावित किए बिना घटक के आंतरिक व्यवहार को पूरी तरह से सुरक्षित कर सकते हैं। हालांकि, इस तरह के एक लाभ को प्राप्त करने के लिए, सिस्टम मॉडल पर बहुत गंभीरता से काम करना आवश्यक है (टिप 2 देखें)।



7. अपने आवेदन के घटकों और उप प्रणालियों के बीच अंतर का वर्णन करने के लिए स्पष्ट, समझने योग्य और प्राकृतिक इंटरफेस का उपयोग करें।



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



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



8. सिस्टम कार्यक्षमता के सही कार्यान्वयन को सत्यापित करने के लिए स्वचालित परीक्षण लिखें



स्वचालित परीक्षण एक डेवलपर को यह समझने में मदद करते हैं कि क्या उसका घटक ठीक से काम कर रहा है। प्रत्येक परीक्षण स्क्रिप्ट घटक के इंटरफ़ेस (तथाकथित इकाई परीक्षण) के एक अलग तत्व की जांच के लिए जिम्मेदार है। इस तरह के परीक्षण लिखने के लिए, NUnit का खुला स्रोत विकास है।



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



कुछ मामलों में, घटक की कार्यक्षमता विकसित करने से पहले एक घटक के लिए एक परीक्षण ड्राइवर लिखने की सिफारिश की जाती है (उपयोग मामलों के एक सेट के लिए)। यह आपको "सही" घटक इंटरफ़ेस विकसित करने में मदद करेगा।



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



9. स्वचालित कोड पीढ़ी के लिए उपकरणों का उपयोग करें



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



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



10. याद रखें कि एक डेटाबेस एक लक्ष्य नहीं है, लेकिन एक साधन है



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



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