सावधान रहें: सिंगल-पर्पस लोगों से

इतना शुद्ध कि दर्द हो

Single Responsibility Principle उन विचारों में से एक है जो इतना समझदार लगता है कि यह आपके विवेक को चकमा दे सकता है।

एक काम करो। उसे अच्छे से करो। मॉड्यूल को फोकस्ड रखो। कोड को बदलने का एक कारण दो। अच्छी सलाह।

फिर कोई उस सलाह को मापने का टेप बना देता है और यह घोषित करने लगता है कि पाँच लाइन से बड़ा कोई भी फंक्शन एक कोड स्मेल है।

समस्या SRP नहीं है। समस्या “छोटा” को “cohesive” का विकल्प मानना है।

उस बिंदु पर आप सिंगल-पर्पस लोगों से मिल चुके हैं: डेवलपर्स जो मॉड्युलरिटी के बारे में बिल्कुल गलत नहीं हैं, लेकिन उपयोगी बाउंड्रीज को अधिकतम विखंडन के साथ भ्रमित कर चुके हैं।

I. इसके नीचे का उपयोगी विचार

फॉर्म में एक सिंगल चेकबॉक्स जोड़ने से आदर्श रूप से केवल एक फाइल प्रभावित होनी चाहिए। 5 डायरेक्टरीज में 8 फाइलें नहीं… मैं तुम्हारी ही बात कर रहा हूँ, React/Redux।

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

यहाँ तक कि क्लासिक Unix उदाहरण भी नारे से ज़्यादा व्यावहारिक हैं। ls फाइलों को सूचीबद्ध करता है, हाँ, लेकिन यह opendir, readdir, closedir, और stat जैसे कॉल्स को भी कोऑर्डिनेट करता है। उपयोगी यूनिट सबसे छोटी संभव ऑपरेशन नहीं है। उपयोगी यूनिट वह सबसे छोटी सुसंगत चीज़ है जो कार्य को हल करती है।

मूल Unix दर्शन कंपोजिशन और सरलता के बारे में था, सब कुछ को एक सिंगल फंक्शन या फाइल में कम करने के बारे में नहीं।

यह अंतर मायने रखता है। “एक जिम्मेदारी” का मतलब “व्यवहार की एक लाइन” नहीं है।

II. ओवर-अब्सट्रैक्शन: जब सरलता अराजकता में बदल जाती है

हमारे आर्किटेक्ट का ज़िद है कि 5 लाइन से लंबा हर फंक्शन एक ‘कोड स्मेल’ है। हमारा कोडबेस अब बेवकूफीपूर्ण निराशा की हल्की गंध देता है।

फेलियर मोड को आसानी से देखा जा सकता है, भले ही इसने आपका हफ्ता पहले से ही खराब कर दिया हो।

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

उस सारी पवित्रता ने क्या खरीदा?

• फाइल सिस्टम श्रैपनेल: सोर्स डायरेक्टरीज़ असंख्य छोटी फाइलों के भयानक परिदृश्यों में फूल रही हैं, अक्सर एक tragically अकेले फंक्शन को शामिल करती हैं। नेविगेशन spelunking का एक अभ्यास बन जाता है।
• डिपेंडेंसी उलझनें: इम्पोर्ट्स और एक्सपोर्ट्स का एक जाल इतना घना कि एक्जीक्यूशन को ट्रेस करने के लिए एक बड़े व्हाइटबोर्ड और उस फीचर से ज़्यादा धैर्य की ज़रूरत होती है जिसका वह हकदार है। फाइलें जो बिल्कुल एक बार इम्पोर्ट की गई हैं, वहाँ रीयूज़ेबल होने का नाटक करती हुई बैठती हैं।
• टेस्टिंग धोखा: टेस्ट नाज़ुक हो जाते हैं, लघु इम्प्लीमेंटेशन विवरणों की रक्षा करने वाले अति-विशिष्ट सेंटिनल। एक फंक्शन सिग्नेचर बदलें? दर्जनों टेस्ट प्राचीन मिट्टी के बर्तनों की तरह चकनाचूर हो जाते हैं। टेस्ट सूट एक सेफ्टी नेट से माइनफील्ड में बदल जाता है।
• वेलोसिटी गायब: सरल बदलाव मल्टी-फाइल मॉडिफिकेशन सागा में मेटास्टेसाइज़ हो जाते हैं। नए डेवलपर्स को ऑनबोर्ड करने में उन्हें UserProfile कंपोनेंट वास्तव में कहाँ रहता है यह खोजने के लिए मैप और कंपास सौंपने में हफ्ते लग जाते हैं। इस “संगठन” के भार तले फॉरवर्ड प्रोग्रेस भूवैज्ञानिक रेंगने में बदल जाता है।

मैंने ऐसे कोडबेस के abyss में देखा है जहाँ एक सीधी 100-लाइन फीचर को 15+ फाइलों में विविसected किया गया था, प्रत्येक एक “शुद्ध” छोटा परी जिसमें शायद एक या दो फंक्शन थे। उस गंदगी को अपने सिर में रखने की कोशिश करने का कॉग्निटिव ब्लास्ट रेडियस अलगाव से किसी भी सैद्धांतिक लाभ को पूरी तरह से नकार देता है। यह सरल नहीं था; यह बस बिखरा हुआ था।

III. पूर्णता की कीमत: डेवलपर्स पर प्रभाव

हम फीचर्स शिप करने की तुलना में फाइल स्ट्रक्चर और नेमिंग कन्वेंशन पर बहस करने में ज़्यादा समय बिताते हैं। क्या यह Agile है?

यह पैथोलॉजिकल विखंडन केवल एक सौंदर्य समस्या नहीं है। यह बदल देता है कि डेवलपर्स अपना ध्यान कैसे खर्च करते हैं:

प्रोडक्टिविटी ड्रेन: टेक्निकल डेट को भूल जाइए; यह ऑब्सेसिव-कंपल्सिव डायरेक्टरी नेस्टिंग के माध्यम से अर्जित ऑर्गनाइज़ेशनल डेट है। हर मामूली बदलाव लेयर्स ऑफ़ अब्सट्रैक्शन के माध्यम से एक पुरातात्विक खुदाई बन जाता है। समय cd .. और grep के ब्लैक होल में गायब हो जाता है।

टेक्सिंग टैक्स: आत्मविश्वास प्रदान करने के बजाय, टेस्ट सूट घर्षण का स्रोत बन जाता है। घंटे उन टेस्ट्स को फिक्स करने में पिघल जाते हैं जो तुच्छ रिफैक्टर से टूट गए थे, टेस्ट जो उन माइक्रोस्कोपिक विवरणों से बहुत कसकर जुड़े हुए थे जिन्हें उन्हें सत्यापित करना चाहिए था।

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

IV. व्यावहारिकता को अपनाना: एक व्यावहारिक विकल्प

मैंने सुझाव दिया कि हम दो संबंधित फंक्शन्स को एक ही फाइल में रखें। कमरे ने प्रतिक्रिया व्यक्त की जैसे मैंने स्टेजिंग डिलीट करने का प्रस्ताव रखा हो। — एक रिकवरिंग प्यूरिस्ट पाठक

एस्केप हैच SRP को छोड़ना नहीं है। जवाब इसे अर्थ के सही स्तर पर लागू करना है।

व्यवहार में ऐसा दिखता है:

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

उद्देश्य PhD थीसिस के योग्य सैद्धांतिक पूर्णता नहीं है; यह ऐसा कोड बनाना है जिसे आपके सहकर्मी (और भविष्य का आप) नेविगेट कर सकें, समझ सकें, और इमारत को आग लगाने की इच्छा के बिना संशोधित कर सकें।

कभी-कभी इसका मतलब है कि एक फाइल 50 लाइन की बजाय 200 लाइन लंबी है। कभी-कभी एक फंक्शन डेटा फेच करना और इसे थोड़ा ट्रांसफॉर्म करना हैंडल करता है। कभी-कभी एक क्लास की दो जिम्मेदारियाँ होती हैं जो इतनी कसकर जुड़ी होती हैं कि उन्हें एक साथ रहना चाहिए। यदि यह सिस्टम को समग्र रूप से काम करना आसान बनाता है, तो यह शायद सही कॉल है।

व्यावहारिक प्रश्नों पर निर्दयता से केंद्रित रहें:

• क्या कोई नया अपना रास्ता खोज सकता है?
• क्या हम असंबंधित Y को तोड़े बिना X बदल सकते हैं?
• क्या यह टेस्ट वास्तव में मुझे बताता है कि फीचर काम कर रहा है?
• क्या हम वैल्यू शिप कर रहे हैं, या बस फोल्डर्स को पुनर्व्यवस्थित कर रहे हैं?

V. निष्कर्ष: कोहेसिव और मेंटेनेबल कोड को बढ़ावा देना

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

इसलिए जब आप सिंगल-पर्पस लोगों का सामना करें, जो तीन लाइन से ज़्यादा किसी भी फंक्शन पर युद्ध छेड़ने के लिए तैयार हैं, तो एक गहरी साँस लें। 12-फाइल चेकबॉक्स को याद करें।

हमारा काम सैद्धांतिक रूप से अक्षुण्ण स्नोफ्लेक फंक्शन बनाना नहीं है। हमारा काम ऐसा सॉफ्टवेयर बनाना है जो काम करे, समस्याओं को हल करे, और अगले व्यक्ति को दंडित न करे जिसे इसे छूना है।

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

¹ विडंबना यह है कि सबसे निचले स्तर पर वास्तविक सिंगल परपस प्राप्त करने के लिए immense कॉम्प्लेक्सिटी की ज़रूरत होती है जो सतह के ठीक नीचे छिपी होती है।

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