रीडमी आधारित विकास

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

वाह। तो हम इस समस्या को कैसे हल करते हैं? जितना आप सोचते हैं, उससे अधिक सरल और एक अलग पैराग्राफ में उत्तर को उजागर करने के लिए पर्याप्त महत्वपूर्ण है।

सबसे पहले, Readme फ़ाइल बनाएं।

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

यह स्वीकार्य नहीं है। तकनीकी विनिर्देश पत्रों के ढेर और इसकी अनुपस्थिति के बीच एक मध्य मैदान होना चाहिए, जैसे कि। और वास्तव में यह है। यह बीच का मैदान एक अगोचर और मामूली रीडमी फ़ाइल है।

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

बहुत शुरुआत में रीडमी फ़ाइल लिखने के साथ शुरू करते हुए, आप अपने लिए कई महत्वपूर्ण लाभ बनाते हैं:

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

अपनी परियोजना के निर्माण के लिए रीडमी फ़ाइल लिखने की प्रक्रिया पर विचार करें। यह ठीक वही जगह है जहाँ आपके सभी शानदार विचारों को व्यक्त किया जाना चाहिए। इस दस्तावेज़ को आपकी रचनात्मकता और आत्म-अभिव्यक्ति के प्रमाण के रूप में एक अलग स्थान पर कब्जा करना चाहिए। आपके कोड आधार में रीडमी फ़ाइल सबसे महत्वपूर्ण दस्तावेज होनी चाहिए; और इसे पहले बनाना सही है।

टिप्पणी:

1. सॉफ्टवेयर विकास तकनीशियन नामों के अनुवाद यहां से लिए गए हैं ।
2. Corey Oordt's PyCon 2011 प्रलेखन के माध्यम से विकास के सिद्धांतों पर बात करते हैं