जटिलता क्या है?

हाल ही में, मैंने "सॉफ़्टवेयर डिज़ाइन का एक दर्शन" पढ़ना समाप्त किया है और दूसरे अध्याय में, यह सॉफ़्टवेयर जटिलता के विषय की पड़ताल करता है। 

पुस्तक "ए फिलॉसफी ऑफ सॉफ्टवेयर डिजाइन" व्यावहारिक रूप से जटिलता को परिभाषित करती है:

"जटिलता एक सॉफ्टवेयर सिस्टम की संरचना से संबंधित कुछ भी है जो इसे समझना और संशोधित करना कठिन बना देती है।"

दूसरे शब्दों में, जटिलता कई रूप ले सकती है, और जरूरी नहीं कि इसका प्रदर्शन से कोई लेना-देना हो, आपका कोड निष्पादक हो सकता है और फिर भी जटिल हो सकता है

मैं इस लेख में पुस्तक की कुछ प्रमुख परिभाषाएँ और अंतर्दृष्टि साझा करना चाहूँगा। लेकिन पहले, आइए एक सामान्य स्थिति की कल्पना करें जिससे शायद आप पहले ही गुज़र चुके हैं…

एक छोटी डरावनी कहानी

आइए एक डरावनी कहानी पर गौर करें जिसे आपमें से कई लोगों ने शायद अनुभव किया होगा या अनुभव करेंगे।

1. इसकी शुरुआत एक सरल सीआरयूडी कार्य प्रबंधन ऐप से हुई। कोड साफ़, मॉड्यूलर और बनाए रखने में आसान था। विकास टीम खुश थी, और सिस्टम ने शुरुआती ग्राहकों के लिए पूरी तरह से काम किया।

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

3. कैलेंडर एकीकरण: टीम को Google कैलेंडर और आउटलुक के साथ एकीकृत करना था। विभिन्न डेवलपर्स ने समाधान लागू किए, जिसके परिणामस्वरूप असंगत दृष्टिकोण सामने आए।

4. ईमेल सूचनाएं: ईमेल सूचनाएं आगे जोड़ी गईं। एक डेवलपर ने एक विशिष्ट लाइब्रेरी का उपयोग किया, जबकि दूसरे ने एक कस्टम समाधान बनाया। मिश्रित दृष्टिकोण ने कोड को भ्रमित कर दिया।

5. रिपोर्ट जेनरेटर: रिपोर्ट जेनरेटर के लिए, डेवलपर्स ने विभिन्न तकनीकों का उपयोग किया: पीडीएफ, एक्सेल एक्सपोर्ट और इंटरैक्टिव डैशबोर्ड। एकीकृत दृष्टिकोण की कमी ने रखरखाव को एक बुरा सपना बना दिया।

6. बढ़ती जटिलता: प्रत्येक सुविधा को अलग-अलग और तेजी से विकसित किया गया था, जिससे सुविधाओं के बीच निर्भरता पैदा हुई। डेवलपर्स ने सब कुछ काम करने के लिए "त्वरित सुधार" बनाना शुरू कर दिया, जिससे सिस्टम की जटिलता और युग्मन बढ़ गया।

सॉफ्टवेयर विकास शून्य में नहीं होता है; विभिन्न आंतरिक और बाह्य कारक इसे प्रभावित करते हैं। हम सभी इस तरह की स्थिति में रहे हैं, या रहेंगे।

अंत की शुरुआत

तब समस्याएं शुरू हुईं:

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

लक्षणों का नामकरण

यह स्पष्ट है कि अब हमारे पास एक जटिल प्रणाली है।

अब आइए इस जटिलता को "विश्लेषण" करें ताकि इसे पहचानना और कम करना आसान हो सके।

खैर, "कम करना" का अर्थ है:

"कम गंभीर, गंभीर या दर्दनाक बनाने के लिए; कम करने के लिए।"

मेरा मानना ​​है कि जटिलता अक्सर कोड में अंतर्निहित होती है। कुछ चीज़ें स्वभाव से जटिल होती हैं। एक डेवलपर के रूप में आपकी भूमिका केवल वह कोड बनाना नहीं है जिसे कंप्यूटर कुशलतापूर्वक निष्पादित कर सके, बल्कि ऐसा कोड बनाना भी है जिसके साथ भविष्य के डेवलपर्स (आपके भविष्य के स्वयं सहित) काम कर सकें।

"जटिलता को नियंत्रित करना कंप्यूटर प्रोग्रामिंग का सार है।"

— ब्रायन कर्निघन

उल्लेखित पुस्तक के लेखक का कहना है कि जटिलता आम तौर पर तीन तरीकों से प्रकट होती है, जिसे हम यहां देखेंगे।

प्रवर्धन बदलें

परिवर्तन प्रवर्धन तब होता है जब एक साधारण प्रतीत होने वाले परिवर्तन के लिए कई अलग-अलग स्थानों में संशोधन की आवश्यकता होती है।

उदाहरण के लिए, यदि उत्पाद स्वामी "प्राथमिकता" या "समापन तिथि" फ़ील्ड का अनुरोध करता है और आपकी इकाइयां कसकर जुड़ी हुई हैं, तो आपको कितने बदलाव करने की आवश्यकता होगी?

संज्ञानात्मक भार

संज्ञानात्मक भार से तात्पर्य किसी कार्य को पूरा करने के लिए डेवलपर द्वारा आवश्यक ज्ञान और समय की मात्रा से है।

तो इस परिदृश्य की कल्पना करें: एक नया डेवलपर टीम में शामिल हुआ, उसे रिपोर्ट जनरेटर में एक बग को ठीक करने का काम सौंपा गया था। इस कार्य को पूरा करने के लिए, देव को यह करना होगा:

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

यह क्लासिक "अनुमान लगाना असंभव" परिदृश्य है, जहां कार्य में एक या आठ अंक लग सकते हैं - बेहतर होगा कि एक D20 रोल करें और तदनुसार प्रतिक्रिया दें।

अज्ञात अज्ञात

अज्ञात अज्ञात तब होते हैं जब आप वह नहीं जानते जो आप नहीं जानते।

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

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

जटिलता के कारण

डरावनी कहानी और तीन मुख्य लक्षणों को देखने के बाद, आइए देखें कि जटिलता का कारण क्या है।

1. निर्भरता

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

परिभाषा:

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

निर्भरता के प्रकार:

• प्रत्यक्ष: मॉड्यूल ए सीधे मॉड्यूल बी पर निर्भर करता है।
• सकर्मक: मॉड्यूल ए मॉड्यूल बी पर निर्भर करता है, जो मॉड्यूल सी पर निर्भर करता है।
• चक्रीय: मॉड्यूल ए, बी, और सी एक गोलाकार तरीके से अन्योन्याश्रित हैं।

2. अस्पष्टता

अस्पष्टता तब होती है जब महत्वपूर्ण जानकारी स्पष्ट नहीं होती है। इससे कोडबेस को समझना कठिन हो सकता है, जिससे संज्ञानात्मक भार बढ़ सकता है और अज्ञात का जोखिम बढ़ सकता है।

परिभाषा:

अस्पष्टता तब होती है जब महत्वपूर्ण जानकारी स्पष्ट नहीं होती है।

अस्पष्टता के उदाहरण:

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

याद रखें: जटिलता वृद्धिशील है

• जटिलता शायद ही कभी एक "त्रुटि" या खराब निर्णय के कारण होती है।
• समय के साथ खराब निर्णयों और निर्भरताओं के कारण जटिलताएं "धीरे-धीरे" बढ़ती हैं।

क्योंकि यह वृद्धिशील है, यह सोचना आसान है, "सिर्फ एक बार, इससे कोई फर्क नहीं पड़ेगा।" लेकिन जब जमा हो जाए, तो केवल एक या दो निर्भरता को ठीक करने से ज्यादा फर्क नहीं पड़ेगा।

"सॉफ़्टवेयर इंजीनियरिंग में सब कुछ एक समझौता है।"
— मुझे लेखक याद नहीं है

निष्कर्ष

मैं जटिलता से बचने के लिए बहुत सारे नियम, रणनीतियाँ और ढाँचे लिख सकता हूँ जो शायद आपने पहले ही इंटरनेट पर देख लिए होंगे: SOLID, डिज़ाइन पैटर्न, YAGNI, KISS, आदि।

हालाँकि, आप उन सभी को एक मार्गदर्शक सिद्धांत में एकीकृत कर सकते हैं (जैसा कि "प्रैग्मैटिक प्रोग्रामर" में बताया गया है): "क्या मैं जो लागू कर रहा हूँ उसे बदलना आसान है?" यदि उत्तर नहीं है, तो आप संभवतः जटिलता बढ़ा रहे हैं।

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

धन्यवाद!