मैं खूबसूरती से लिखित, ओवर-इंजीनियरिंग कोड के अपने हिस्से पर आया हूं ... एक पल मैं सोच रहा हूं "यह ऐसा करने का एक दिलचस्प तरीका है" और अगले मिनट आप आश्चर्य कर रहे हैं "क्या नरक यहां चल रहा है! के (You Are Not Gonna Need It) सिद्धांत ओवर-इंजीनियरिंग का मुकाबला करने का एक अच्छा तरीका है: कार्यक्षमता केवल तब लागू की जानी चाहिए जब आपको इसकी आवश्यकता होती है, न कि संभावना पर कि आपको इसकी आवश्यकता होगी. मैंने अब कुछ बार ओवर-इंजीनियरिंग का उल्लेख किया है, और आप में से कुछ शायद सोच रहे हैं कि ओवर-इंजीनियरिंग क्या है? अब YAGNI अब बहुत ही सरल शब्दों में, ओवर-इंजीनियरिंग सॉफ्टवेयर / सिस्टम डिजाइन को आवश्यक से अधिक जटिल बनाता है; यह आमतौर पर ऐसा होता है क्योंकि आप अपने घटक को अतिरिक्त कार्यक्षमता जोड़ना चाहते हैं ताकि ए के कार्यान्वयन को सरल बनाया जा सके, केवल बाद में बी के लिए कार्यक्षमता जोड़ने के लिए। हमारे पास आमंत्रण प्रबंधन के लिए इस कोडबेस है; यह एक विरासत, परंपरागत कोडबेस है, जिसमें तकनीकी ऋण है जो ब्याज बढ़ता है। जितना अधिक आप विरासत कोड पर काम करने की कोशिश करते हैं, उतना ही कहीं और कुछ टूट जाता है। आपको अधिकांश मामलों में फिर से शुरू करना होगा। विरासत कोड के चारों ओर काम करना अंततः तकनीकी ऋण पर रुचि बढ़ती है; यह ऐप के माध्यम से सुविधाओं को तोड़ने का जोखिम उठाने या कोडबेस में अधिक तकनीकी ऋण जोड़ने के बीच एक झटका लगता है। तीसरा समाधान हमने उठाया था अवलोकन। हमें एप्लिकेशन के लिए नए सुविधाओं या सुधारों को मॉड्यूल करने के तरीकों का पता लगाना था, और जहां आवश्यक हो, एक कोडबेस पर कई लोगों के साथ सहयोग करते समय (जो लगभग हमेशा होता है), और उन कंपनियों के लिए जो कोड गुणवत्ता की तुलना में शिपिंग सुविधाओं में अधिक रुचि रखते हैं, कोड समीक्षाएं हमेशा पीड़ित होती हैं। ओवर-इंजीनियरिंग और ओवरअबस्ट्राशन जैसे मुद्दों के लिए, पारंपरिक लाइन-दर-लाइन कोड समीक्षाएं अक्सर इन व्यवस्थित मुद्दों को याद करती हैं। आप DRY सिद्धांत का पालन करते हुए एक विशेषता के एकीकरण का समर्थन करने के लिए कुछ हफ्तों पहले बनाई गई एक घटक की जांच करते हैं, और महसूस करते हैं कि अब 10 अंतर्निहित / समान विशेषताएं हैं जो घटक पर निर्भर करती हैं। कोड समीक्षाओं को इन वास्तुकला ड्राई कोड स्पैगेटी हम DRY (Don’t Repeat Yourself) सुसमाचार का पालन करते हैं क्योंकि यह काम को सरल बनाता है, और डेवलपर्स स्वाभाविक रूप से आलसी हैं (एक अच्छी तरह से)। . सिस्टम को सहयोगी मॉड्यूल से बनाया जाना चाहिए, जिनमें से प्रत्येक एक-दूसरे से स्वतंत्र रूप से कार्यक्षमता को लागू करता है Alıntılar - Pragmatic प्रोग्रामर: Journeyman से मास्टर करने के लिए Kitap.Guru। orthogonal प्रणालियों और DRY कोड पर अधिक जोर देना चाहिए; आप एक दूसरे के साथ बनाए जाने वाले दोहराने योग्य कार्यों को जोड़ना आसान है और रजिस्टर की प्रगति के रूप में उन्हें स्केलिंग करना आसान है जब वे पतला नहीं होते हैं और अत्यधिक निष्कर्षित होते हैं, जिस बिंदु पर आप एक कठोर प्रणाली के साथ अंत में एक दूसरे के साथ इतना जुड़े होते हैं कि यह कनेक्ट करना जटिल होगा कि कोड का कौन सा पहलू जो एक सटीक नियम को पूरा नहीं करता है, आप कोड को दोहराना पाएंगे क्योंकि इसे एक नए कनेक्शन के लिए काम करने से एक पुराना सिस्टम टूट जाता है। जटिल घटकों आपके घटकों को न केवल दोहराव से बचने पर ध्यान केंद्रित करना चाहिए, बल्कि पूरे सिस्टम के छोटे अवलोकनों पर भी ध्यान केंद्रित करना चाहिए; अन्यथा, आप घटकों के साथ इतने जटिल हो जाएंगे कि वे आसानी से एक कनेक्टेड घटकों के लिए एक एकल परिवर्तन के साथ तोड़ सकते हैं। पुनः उपयोग कोड बनाने पर, दृष्टिकोण को कोड लिखना चाहिए जो किसी अन्य कोड ब्लॉक पर निर्भर नहीं करता है कि एक निश्चित तरीके से कार्य करे। पुनः उपयोग को एक उपकरण के रूप में उपयोग किया जाना चाहिए और लक्ष्य नहीं; जब आपके पास एक ही घटकों में व्यापार या एपीआई तार्किक के साथ पुनः उपयोग के लिए यूआई घटकों हैं, तो आप अतिरिक्त बाहरी तार्किक / संदर्भ जोड़ने के बिना घटकों पर पुनः उपयोग नहीं Over-abstraction और over-engineering से बचने के लिए पैटर्न Modularity Modularity मॉड्यूलरता Modularity Modularity मॉड्यूलरता में आपके सिस्टम को छोटे, स्वतंत्र कोड / घटकों में तोड़ना शामिल है, जिन्हें मॉड्यूल कहा जाता है। कृपया "छोटे" शब्द पर ध्यान दें; आवश्यक से अधिक कोड के साथ एक सूखा मॉड्यूल होने की संभावना है, जिससे अत्यधिक अवलोकन पैदा होता है और इसे दूर किया जाना चाहिए। अत्यधिक अवलोकन वास्तव में मॉड्यूलरता पर एक असफल प्रयास है। आपके मॉड्यूल अन्य मॉड्यूलों से स्वतंत्र रूप से काम करने में सक्षम होना चाहिए, केवल आवश्यक डेटा को प्रकट करना। पहला काम orthogonal सिस्टम का निर्माण करने के लिए एक अच्छा दृष्टिकोण और आसानी से अत्यधिक अवलोकन से बचने के लिए सबसे पहले कार्यक्षमता के साथ निर्माण करना है, फिर विशेषताएं; यह Component-Based आर्किटेक्चर के साथ अच्छी तरह से समायोजित करता है (अनुकूलित घटकों से यूआई घटकों को अलग करना)। कार्यक्षमता चरण को छोटे से पुनः उपयोग किए जाने वाले कोड इकाइयों पर ध्यान केंद्रित करेगा जो विशेषता को लागू करने के लिए इकट्ठा किए जाते हैं। अत्यधिक परिष्कृत कोड के लिए कोई पदक नहीं प्रत्येक कोड कार्यान्वयन लिखने के बाद, अपने आप से पूछें कि क्या एक ही परिणाम प्राप्त करने का एक आसान या सरल तरीका है. हम में से अधिकांश कोड के बारे में कहानियां सुन चुके हैं जो कंपनी में केवल एक व्यक्ति द्वारा संपादित या काम किया जा सकता है, जो गर्व करने के लिए एक उपलब्धि नहीं है। एक कंपनी के पूर्व कर्मचारी कोड में जांच नहीं करने के लिए जाना जाता है और अपने हार्ड ड्राइव पर कोडबेस के कार्यक्रमों और भागों को रखने के लिए (इस उत्पाद को बनाए रखने के लिए ओवरहेड की कल्पना करें!). "हम कॉलम से बाहर चले गए" - जिमी मिलर के सर्वश्रेष्ठ, सबसे खराब कोडबेस मैंने खुद को बहुत परिष्कृत कोड लिखने के लिए पाया है क्योंकि मैं एक नई तकनीक / पैकेज / पुस्तकालय का उपयोग करना चाहता हूं जिसे मैंने अभी सीखा है, इस बात पर विचार किए बिना कि क्या यह नौकरी के लिए सबसे सरल उपकरण है। अंतिम सही कोड लिखने की तलाश में जो सभी संभावित भविष्य और समय यात्रा के मामलों को संबोधित करते हैं, आप एक अत्यधिक इंजीनियरिंग कोडबेस के साथ समाप्त हो जाते हैं. आपको इसे छोड़ना चाहिए क्योंकि यह सही कोड लिखना संभव नहीं है, अपने सभी तत्काल आवश्यकताओं को पूरा करने के लिए पर्याप्त अच्छे के लिए लक्ष्य रखना चाहिए. DRY सिद्धांत मौलिक है; दोहराना सॉफ्टवेयर विकास में अभी भी एक पाप है. DRY सिद्धांत को एक ऑर्थोकोनल सिस्टम पर लागू किया जाना चाहिए ताकि एक कोडबेस बनाया जा सके जो अलग हो, प्रत्येक मॉड्यूल स्वतंत्र रूप से और एक अलग मीटिंग बिंदु पर डेटा का आदान-प्रदान कर रहा है(फायर मॉड्यूल). ये आपको सिस्टम बनाने में मदद करेंगे
