विकास प्रक्रिया में हमें किसी दस्तावेज़ की आवश्यकता क्यों है? इस कथन के बारे में क्या कहना है कि ? कोड स्वयं दस्तावेजित है आइए सबसे सामान्य परिदृश्य पर विचार करें: सिस्टम का कोड (चाहे वह प्रोग्राम, प्रोजेक्ट या उत्पाद हो) एक लंबी अवधि में लिखा जा रहा है, और इस प्रक्रिया के दौरान टीम धीरे-धीरे बदलती है, तथा डेवलपर्स के जाने पर सिस्टम के बारे में कुछ ज्ञान अपने साथ ले जाती है। ऐसे मामले में हम क्या कर सकते हैं? सबसे सरल उत्तर यह है कि जिसमें सभी कार्यान्वयन विवरण शामिल हों ताकि यह सुनिश्चित हो सके कि प्रणाली मूल आवश्यकताओं को पूरा करती है। एक विनिर्देश लिखा जाए हालाँकि, इस तरह के दस्तावेज़ को पहले से लिखना बहुत मुश्किल है, और विकास प्रक्रिया के दौरान, कुछ कार्यान्वयन विवरण बदल सकते हैं (बाजार के अनुकूल होना/यांत्रिकी के लिए नए अनुरोध, आदि)। तो, हम को बेहतर बनाने के लिए क्या कर सकते हैं? बस कारक आइए हम एक ऐसे प्रवाह का अनुसरण करने का प्रयास करें जो ऊपर बताई गई समस्या के समाधान के लिए संभावित समाधानों में से एक हो सकता है। आवश्यकताएँ और RFC सबसे पहले, हमें हितधारकों की आवश्यकताओं के आधार पर प्रारंभिक डिज़ाइन का वर्णन करना होगा और उसका दस्तावेज़ीकरण करना होगा। उसके बाद, इस दस्तावेज़ को अन्य टीमों के साथ साझा किया जा सकता है और उनकी प्रतिक्रिया मांगी जा सकती है: कुछ विशेषताओं को लागू करने के लिए कहें, प्रारंभिक डिज़ाइन पर टिप्पणी करें, एक निश्चित इंटरफ़ेस को ठीक करें, आदि। ऐसे दस्तावेज़ को कहा जा सकता है। RFC , या "टिप्पणियों के लिए अनुरोध", एक दस्तावेज़ है जो इच्छुक पक्षों के बीच वितरित किया जाता है - जिसमें डेवलपर्स, आर्किटेक्ट और अन्य टीमें शामिल हैं - प्रतिक्रिया, टिप्पणियाँ और सुझाव एकत्र करने के लिए। यह विनिर्देश की तुलना में कम विस्तृत है और इसमें केवल प्रारंभिक समस्या, कार्य और समाधान डोमेन शामिल है। अधिक लचीला होने के कारण, यह कार्य की गहन समझ सुनिश्चित करने और गुणवत्ता और विचारशील निर्णय लेने की सुविधा प्रदान करते हुए डिज़ाइन में परिवर्तनों को सक्रिय रूप से स्वीकार करने की अनुमति देता है। RFC डिज़ाइन प्रतिबद्धता और एडीआर ठीक है, हमने है और । आगे क्या है? तकनीकी आवश्यकताओं को परिभाषित कर लिया अन्य टीमों से आवश्यकताएं एकत्र कर ली हैं इस स्तर पर, देना आवश्यक है। इस उद्देश्य के लिए, हम एक लिखते हैं। सिस्टम डिज़ाइन और इसके द्वारा किए जाने वाले सभी मुख्य कार्यों को अंतिम रूप ADR , या "आर्किटेक्चर डिसीजन रिकॉर्ड," एक दस्तावेज है जो सॉफ्टवेयर विकास प्रक्रिया के दौरान किए गए महत्वपूर्ण आर्किटेक्चरल निर्णयों को रिकॉर्ड करता है। प्रत्येक एक विशिष्ट उच्च-स्तरीय आर्किटेक्चरल निर्णय, उसके संदर्भ, विचार किए गए विकल्पों, लिए गए निर्णय और इन विशिष्ट विवरणों को दूसरों पर चुनने की प्रेरणा का वर्णन करता है। एडीआर एडीआर ऐसा दस्तावेज़ हर टीम के सदस्य (और साथ ही अन्य टीमों) को डिज़ाइन के मूल सिद्धांतों और मूल्यों को अनुमति देता है। अगर कोई नया डेवलपर सालों बाद टीम में शामिल होता है और पूछता है, "आपने ऐसा क्यों किया?", तो उन्हें यह दस्तावेज़ दिखाया जा सकता है, जो उनके सभी सवालों के जवाब देगा। समझने की विनिर्देश अब कोड और उसके विनिर्देशों को लिखने का समय आ गया है। इस चरण में, हम प्रत्येक सुविधा पर गहनता से काम करते हैं, साथ ही सभी जानकारी और कार्यान्वयन विवरणों को एक विशेष दस्तावेज़ में संकलित करते हैं। इस दस्तावेज़ में सिस्टम के लिए वर्तमान निम्न-स्तरीय आवश्यकताओं को प्रतिबिंबित करना चाहिए। : सॉफ़्टवेयर जीवनचक्र के दौरान, इस तरह के विनिर्देश में काफी बदलाव हो सकते हैं, और यह ठीक है। हालाँकि, कोडबेस को अप्रबंधनीय बनने से रोकने के लिए मूल डिज़ाइन और आर्किटेक्चर के भीतर रहना बहुत महत्वपूर्ण है। एक महत्वपूर्ण बिंदु जाँच की योजना इसकी आवश्यकता क्यों है? परीक्षण योजना के लिए यह महत्वपूर्ण है कि इसे विनिर्देश के अनुसार लिखे गए बनाया जाए (हम इस कोड के लिए कोड और परीक्षण लिखते हैं ताकि वे पास हो जाएं), लेकिन पर जिसमें महत्वपूर्ण परिदृश्य शामिल हों जिन्हें । यह भी बहुत सुविधाजनक है कि आप अन्य टीमों (एकीकरण के लिए या सिर्फ अतिरिक्त परीक्षण के लिए) की समीक्षा के लिए ऐसी परीक्षण योजना प्रस्तुत कर सकते हैं, जिससे यह स्पष्ट हो जाता है कि सिस्टम विभिन्न स्थितियों में कैसे व्यवहार करेगा। कोड के आधार पर नहीं एक ऐसे डिज़ाइन के आधार सही तरीके से संसाधित किया जाना चाहिए इसमें क्या-क्या शामिल है? सभी संभावित सिस्टम संचालन परिदृश्य सुखद पथ दुखद पथ त्रुटि प्रबंधन सभी संभावित अपरिवर्तनीयताएं जिन्हें सिस्टम संचालन के दौरान बनाए रखा जाना चाहिए प्रारंभ में सिस्टम स्थिति की जांच करने के लिए स्वीकृति परीक्षण (पर्यावरण पर विचार करना चाहिए, उदाहरण के लिए, नेटवर्क पर डेटा) हमने अंतिम रूप दे दिया है, कोड और लिख दिए हैं, और तैयार कर ली है। यह पहले से ही बहुत ठोस लगता है! लेकिन हम और क्या जोड़ सकते हैं? डिज़ाइन को विनिर्देश परीक्षण योजना तैनाती योजना और ऐसी परिस्थितियां बनाने के लिए कुछ हद तक ऐसी योजना की आवश्यकता हो सकती है, जिसमें कोई भी टीम सदस्य सिस्टम को तैनात कर सके और इसकी स्थिति को सत्यापित कर सके। बस फैक्टर को बेहतर बनाने हम इसके बिना क्यों नहीं कर सकते? हम कर सकते हैं, लेकिन वास्तविक दुनिया में, बड़ी टीमें जहां कई लोग सिस्टम के विभिन्न हिस्सों के लिए जिम्मेदार होते हैं, और तैनाती प्रक्रिया जा सकती है। इसमें क्या गलत है, चूंकि हमने परीक्षण लिखे हैं, उन्हें CI में डाला है, और कमजोरियों की जांच की है, क्या हमें किसी और चीज की आवश्यकता है? शायद नहीं, लेकिन अक्सर परीक्षण सिस्टम की वर्तमान स्थिति पर विचार नहीं करते हैं और हम जो चाहते हैं वैसा परीक्षण नहीं करते हैं। पूरी तरह से DevOps को सौंपी तैनाती योजना में क्या : शामिल हो सकता है तैनाती के लिए किए जाने वाले कार्यों का पूर्ण विवरण परिनियोजन पैरामीटर: पर्यावरण चर आरंभिक राज्य प्रक्षेपण के लिए मापदंड किसी भी कदम पर कुछ गलत होने पर योजना यदि संभव हो तो एक बैकअप योजना वह आवश्यक स्थिति जिस पर सिस्टम को लाया जाना चाहिए, यदि परिनियोजन जारी रखना संभव न हो तैनाती के बाद की जाने वाली आवश्यक कार्रवाइयां अन्य टीमों को सूचित करें यदि आवश्यक हो तो आवश्यक एकीकरण सक्षम करें कुछ भी जटिल नहीं है, है न? किसी विशिष्ट अपडेट के लिए ऐसा दस्तावेज़ होने से हो सकता है और विशिष्ट व्यक्तियों पर । क्या यही हम नहीं चाहते? बस फैक्टर में काफी सुधार निर्भरता कम हो सकती है निष्कर्ष सॉफ़्टवेयर विकास प्रक्रिया में, सिर्फ़ कोड लिखना ही महत्वपूर्ण नहीं है, बल्कि दस्तावेज़ीकरण बनाना भी महत्वपूर्ण है जो विकास के सभी चरणों में समझ और स्थिरता सुनिश्चित करता है। दस्तावेज़ीकरण , लेकिन अनुभव से पता चला है कि सिस्टम की गुणवत्ता, स्थिरता और भविष्य की मापनीयता को बनाए रखने के लिए दस्तावेज़ीकरण बहुत महत्वपूर्ण है, खासकर जब विकास के दौरान टीम बदलती है, और तब भी जब परियोजना विकसित होती है और नई आवश्यकताओं के अनुकूल होती है। कोड ही हो सकता है दस्तावेज़ीकरण में (टिप्पणियों के लिए अनुरोध), (आर्किटेक्चर रिकॉर्ड), , , , और बहुत कुछ शामिल हैं। यह की गारंटी देगा, परियोजना में की प्रक्रिया को सरल करेगा, और । RFC ADR विनिर्देश परीक्षण योजनाएँ परिनियोजन योजनाएँ टीम में ज्ञान के प्रतिधारण नए कर्मचारियों को एकीकृत करने परिवर्तनों के लिए सिस्टम की समग्र विश्वसनीयता और प्रतिरोध को बढ़ाएगा
