सिद्धांत शाश्वत हैं, अभ्यास भ्रमपूर्ण हैं

सिद्धांत और अच्छे अभ्यास के बीच एक बड़ा अंतर है।

सर्वश्रेष्ठ अभ्यास व्यक्तिपरक हैं और मुख्य रूप से संदर्भ पर निर्भर करते हैं, जबकि सिद्धांत शाश्वत और सार्वभौमिक हैं।

"जितना अधिक मैं जानता हूं, उतना ही कम मुझे पता है" लेख ( अंग्रेजी ) लिखने के बाद, मुझे यह कहते हुए कई पत्र प्राप्त हुए कि कुछ अभ्यास हैं जिन्हें बिल्कुल किसी सॉफ्टवेयर विकास प्रक्रिया में पालन किया जाना चाहिए।

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

कुछ सर्वोत्तम प्रथाओं पर एक नज़र डालें।

पहले, चलो सॉफ्टवेयर विकास में कुछ सर्वोत्तम प्रथाओं को देखें, और फिर विचारों की बेहतर समझ के लिए सिद्धांतों के साथ उनकी तुलना करें।

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

इकाई परीक्षण संदर्भ के प्रति संवेदनशील है। इससे मेरा तात्पर्य यह है कि सभी सहमत हैं कि परिस्थितियों का एक निश्चित समूह है जो इकाई परीक्षण मूल्य देता है।

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

लेकिन यह तर्क देने के बजाय कि इकाई परीक्षण कम से कम मूल्य के हैं, आइए बेहतर बात करते हैं कि वे सबसे बड़े मूल्य कहां हैं। इस मुद्दे पर हम तेजी से जुटेंगे।

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


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

जब अधिकांश डेवलपर्स ने चर और विधियों को संक्षिप्त नाम कहा, तो ऐसे कोड पर टिप्पणी करना महत्वपूर्ण था। जब तक चुस्त प्रचलन नहीं रहा, तब तक विकास से पहले विस्तृत उत्पाद आवश्यकताओं को प्रदान करना महत्वपूर्ण था।

लेकिन अधिकांश सर्वोत्तम अभ्यास वास्तव में अच्छे हैं!

हां, आप सही हैं, अधिकांश सर्वोत्तम प्रथाएं वास्तव में व्यापक रूप से लागू हैं और बड़ी संख्या में संदर्भों में उपयोगी हैं।

उदाहरण के लिए, संस्करण नियंत्रण प्रणालियों का उपयोग करना अच्छा अभ्यास माना जाता है, और ऐसी स्थिति की कल्पना करना मुश्किल है जहां यह हानिकारक हो सकता है।

क्या यह एक विशिष्ट नियम या सिद्धांत नहीं है?

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

यदि आपने सर्वोत्तम प्रथाओं का पालन किया है, लेकिन उन्हें अंतर्निहित सिद्धांत की खोज नहीं की है, तो यह संभावना नहीं है कि आप इससे लाभान्वित होंगे।

तथ्य यह है कि सबसे अच्छे अभ्यास सार्वभौमिक रूप से लागू सिद्धांतों से आते हैं जो कभी नहीं बदलते हैं। इसलिए, इनमें से अधिकांश प्रथाएं सबसे अच्छी हैं।

समस्या यह है कि प्रथाओं का उपयोग आपको उन सिद्धांतों से किसी भी लाभ की गारंटी नहीं देता है जो उन्हें रेखांकित करते हैं।

अधिक से अधिक मैं टीमों से मिलता हूं:

• वे यूनिट टेस्ट लिखते हैं
• निरंतर एकीकरण का उपयोग करें
• संस्करण नियंत्रण प्रणाली का उपयोग करें
• स्क्रेम रैलियों को पकड़ो
• जोड़ी प्रोग्रामिंग का अभ्यास करें
• IoC कंटेनरों का उपयोग करें

लेकिन वे इससे लाभ उठाकर शून्य हो जाते हैं। बस अधिक सिरदर्द और शरीर की अतिरिक्त हलचल। और कारण सरल है ...

प्रभावी अभ्यास नहीं है, लेकिन सिद्धांत इसे अंतर्निहित करता है

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


सिद्धांतों को समझने के लिए गुरुत्वाकर्षण एक महान उदाहरण है। जहां तक ​​हम जानते हैं, यह एक सार्वभौमिक शक्ति है जो हमेशा और हर जगह कार्य करती है। गुरुत्वाकर्षण से बचना असंभव है, आप जहां भी जाते हैं, यह वहीं होगा और आप पर कार्रवाई करेगा।

सिद्धांत प्रकृति के नियमों की तरह हैं, केवल व्यापक हैं। सिद्धांतों को वास्तविकता का नियम कहा जा सकता है। हो सकता है कि आप उनका पूरी तरह से वर्णन नहीं कर सकते हैं या समझ सकते हैं कि वे कैसे काम करते हैं, लेकिन वे हमेशा काम करते हैं।

उदाहरण के लिए "फसल का नियम" लें। ज्यादातर लोग इस सिद्धांत से परिचित हैं। सामान्य तौर पर, ऐसा लगता है:

-> तुम क्या काटते हो, तुम क्या काटते हो

यह सत्य कितना सार्वभौमिक है? क्या इस सिद्धांत से बचा जा सकता है? इस अपरिहार्य कानून में आप कितनी बार शामिल हुए हैं?

सॉफ्टवेयर विकास में कई सर्वोत्तम प्रथाएं इस सिद्धांत पर आधारित हैं। उन सर्वोत्तम प्रथाओं के बारे में सोचें जिनके कारण आपने अपने उत्पाद को जल्दी सुधारने के लिए कड़ी मेहनत की।

TDD (या अनजाने टेस्ट ड्रिवेन डेवलपमेंट के लिए) वास्तव में बहुत अच्छा अभ्यास है। टीडीडी का मूल सिद्धांत विकास प्रक्रिया में गुणवत्ता को जल्द से जल्द लागू करना है, जिसके परिणामस्वरूप एक बेहतर उत्पाद है।

यदि आप इसके सिद्धांतों को समझे बिना टीडीडी का उपयोग करते हैं, तो आप बिना किसी लाभ के केवल टीडीडी का अनुकरण करते हैं।

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

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

यही कारण है कि मुझे बॉब मार्टिन की पुस्तक, सिद्धांत, पैटर्न, और चुस्त तकनीक C # में बहुत पसंद है, और वह सॉफ्टवेयर विकास में कई सिद्धांतों के बारे में बात करता है जो हमेशा के लिए रहता है। इस तरह की पुस्तकें और मेरे द्वारा लिखी गई पुस्तक " मेरे मित्र और लोगों को कैसे प्रभावित करें" के बारे में 10 बार सिद्धांतों से भरा हुआ है।

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

इसलिए यह न भूलें कि जब आप किसी के साथ सर्वोत्तम प्रथाओं के बारे में बहस कर रहे हैं या आप अपनी परियोजना में किसी भी अभ्यास को शामिल करना चाहते हैं, तो यदि आप उस सिद्धांत को नहीं समझते हैं जिस पर अभ्यास आधारित है, तो संस्कारों, प्रक्रियाओं की कोई संख्या नहीं, नंबरों के साथ नृत्य इस अभ्यास से आपको मदद नहीं मिलेगी।

स्रोत: agile.dzone.com/articles/principles-are-timeless-best
अनुवादक से: क्षमा करें, मैं हब में "अनुवाद" प्रकाशित नहीं कर सका, "K" अक्षर के लिए सिद्धांत पर्याप्त नहीं था।