प्रोग्रामिंग में सबसे महत्वपूर्ण पैटर्न

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

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

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

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

यहां उन सकारात्मक प्रभावों की एक सूची दी गई है, जब आप चर को कम करने के सिद्धांत के आधार पर प्रोग्रामिंग शुरू करते हैं:

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

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

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

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

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

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

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

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

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

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

वास्तव में, सामान्य तौर पर, किसी भी चर में अपराध-बोध होता है, जब तक कि विपरीत साबित नहीं होता है, तब तक किसी भी चर की आवश्यकता नहीं होती है।

आप मुझ पर आपत्ति कर सकते हैं, उन्होंने मुझे वही कहा, अमेरिका की खोज की, यह लंबे समय से जाना जाता है और इस तरह के सिद्धांतों द्वारा वर्णित है: ओकायामा रेजर , एसओएलआईडी । लेकिन मैं इस अवधारणा को "वैरिएबल का कम से कम" कहना पसंद करता हूं, क्योंकि यह व्याख्या सिर में बहुत ही सक्सेसफुल है और, तदनुसार, प्रैक्टिस में रहना बहुत आसान है। आप में से कितने SOLID सिद्धांत से हर बिंदु को याद करने का दावा कर सकते हैं?

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

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