दस्तावेज़-संचालित विकास के बारे में आप क्या जानते हैं?

विकास प्रक्रिया में हमें किसी दस्तावेज़ की आवश्यकता क्यों है?

इस कथन के बारे में क्या कहना है कि कोड स्वयं दस्तावेजित है ?

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

ऐसे मामले में हम क्या कर सकते हैं?

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

हालाँकि, इस तरह के दस्तावेज़ को पहले से लिखना बहुत मुश्किल है, और विकास प्रक्रिया के दौरान, कुछ कार्यान्वयन विवरण बदल सकते हैं (बाजार के अनुकूल होना/यांत्रिकी के लिए नए अनुरोध, आदि)। तो, हम बस कारक को बेहतर बनाने के लिए क्या कर सकते हैं?

आइए हम एक ऐसे प्रवाह का अनुसरण करने का प्रयास करें जो ऊपर बताई गई समस्या के समाधान के लिए संभावित समाधानों में से एक हो सकता है।

आवश्यकताएँ और RFC

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

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

डिज़ाइन प्रतिबद्धता और एडीआर

ठीक है, हमने तकनीकी आवश्यकताओं को परिभाषित कर लिया है और अन्य टीमों से आवश्यकताएं एकत्र कर ली हैं । आगे क्या है?

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

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

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

विनिर्देश

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

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

जाँच की योजना

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

इसमें क्या-क्या शामिल है?

• सभी संभावित सिस्टम संचालन परिदृश्य

  • सुखद पथ
  • दुखद पथ
  • त्रुटि प्रबंधन

• सभी संभावित अपरिवर्तनीयताएं जिन्हें सिस्टम संचालन के दौरान बनाए रखा जाना चाहिए

• प्रारंभ में सिस्टम स्थिति की जांच करने के लिए स्वीकृति परीक्षण (पर्यावरण पर विचार करना चाहिए, उदाहरण के लिए, नेटवर्क पर डेटा)

  
  

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

तैनाती योजना

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

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

तैनाती योजना में क्या शामिल हो सकता है :

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

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

निष्कर्ष

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

दस्तावेज़ीकरण में RFC (टिप्पणियों के लिए अनुरोध), ADR (आर्किटेक्चर रिकॉर्ड), विनिर्देश , परीक्षण योजनाएँ , परिनियोजन योजनाएँ , और बहुत कुछ शामिल हैं। यह टीम में ज्ञान के प्रतिधारण की गारंटी देगा, परियोजना में नए कर्मचारियों को एकीकृत करने की प्रक्रिया को सरल करेगा, और परिवर्तनों के लिए सिस्टम की समग्र विश्वसनीयता और प्रतिरोध को बढ़ाएगा ।