कैसे "आप की जरूरत नहीं है" और "अब पहले से कहीं बेहतर है" एक साथ खेलते हैं?


17

मैं अक्सर खुद को गले लगाता हूं "जब मैं किसी डिजाइन की DRYness को आगे बढ़ा रहा हूं तो यह पहले से कहीं बेहतर है"। आमतौर पर, मुझे लगता है कि मुझे ज्ञान के अन्य टुकड़ों की एक प्रणाली के संदर्भ में ज्ञान के एक टुकड़े के लिए एक आधिकारिक स्थान की समझ विकसित करने की आवश्यकता है। इस प्रकार, मैं सिस्टम को 'अभी' डिजाइन करता हूं।

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

इन दो पैटर्न को कैसे करें वर्गाकार?

यह सुनिश्चित करने के लिए कि आप अच्छा खेलते हैं, आप किन प्रथाओं का उपयोग करते हैं?

आप भ्रम पैदा किए बिना उन्हें एक साथ कैसे सिखाते हैं?


2
छलांग मारने से पहले देखो। लेकिन जो झिझकता है वह खो जाता है।
मिमीर्स

जवाबों:


26

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

मैं कोड के संबंध में "आपको इसकी आवश्यकता नहीं है" की ओर अधिक झुकाव है, लेकिन डिजाइन के साथ "अब पहले से कहीं बेहतर है"।

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

उस प्रणाली का सबसे सरल एंड-टू-एंड प्रतिनिधित्व बनाएँ जो काम कर सकता है; पहले ऐसा करें, और फिर आपको कुछ प्रतिबिंबित करना होगा। यह उन सभी अस्पष्ट "क्या अगर" सवालों के जवाब देने में मदद करने के लिए जाता है और आपको अगले निर्माण के लिए क्या आवश्यक है, इसके बारे में बताने में मदद करता है।


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

9

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

किसी भी स्थिति में, आप YAGNI के साथ कुछ भी नहीं खो सकते हैं

दूसरे मामले में, आप समय लेखन कोड खो देते हैं जो कभी उपयोग नहीं किया जाता है, और कोड के लिए परीक्षण लिखना जो कभी उपयोग नहीं किया जाता है, और कोड के लिए प्रलेखन लिखना जो कभी उपयोग नहीं किया जाता है, और कोड का रखरखाव जो कभी उपयोग नहीं किया जाता है, लोग सोच रहे हैं कि यह कोड क्या करता है , और यदि यह कभी भी उपयोग किया जाता है, तो विज्ञापन nauseum।

उदाहरण

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

क्या आपको लगता है कि जुकरबर्ग ने फेसबुक के पहले संस्करण को 500 मिलियन उपयोगकर्ताओं के पैमाने पर डिज़ाइन किया था? नहीं, उसने ऐसा करने के लिए डिज़ाइन किया और बनाया कि उसे केवल करने की ज़रूरत है और नहीं। यदि उसने पहले दिन से 500 मिलियन उपयोगकर्ताओं के लिए डिज़ाइन को झरना करने की कोशिश की होती, तो फेसबुक शायद कभी भी जारी नहीं होता।

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

उन्होंने पुन: डिजाइन और पुनर्लेखन की योजना बनाई । जो कि रसोई के सिंक के लिए योजना बनाने की तुलना में एक अलग मानसिकता है और कभी भी पूर्ण रूप से उपयोगी कुछ भी विकसित या वितरित नहीं करता है।

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


2
यदि आपका डिज़ाइन खराब है (उदाहरण के लिए अनम्य) तो आप YAGNI के साथ बहुत कुछ खो सकते हैं।
एरिकशोफर

1
@EricSiplefer - नहीं, अगर यह लक्ष्यों को पूरा करता है और व्यवसाय को मूल्य प्रदान करता है और आपके पास निवेश करने में बहुत समय नहीं है, तो आप इसे फेंक देते हैं कम खो दिया है अपने जादुई असीम लचीली प्रणाली को वितरित करने की तुलना में कभी भी पूरा नहीं होता है जो कभी भी पूरा नहीं होगा और जहाज होगा और यदि ऐसा होता है, तो यह एक बुरा सपना होगा।

6

अजगर के ज़ेन तरह से कहते हैं:

अब पहले से बेहतर है। हालांकि कभी भी अभी से बेहतर नहीं है।

विचार यह है कि ऐसा नहीं है क्योंकि आप अब कुछ परिभाषित कर सकते हैं जो आपको करना चाहिए। क्या आपको अभी इसकी आवश्यकता है?

  • हाँ: अब करो!
  • नहीं: यह मत करो! जरूरत के लिए रुको! YAGNI!

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

इसलिए, YAGNI जब तक आप नहीं करते हैं, तब तक आईटी नाउ। रुको मत!


3

मुझे नहीं लगता कि वे एक साथ खेलते हैं। मुझे लगता है कि आप या तो एक तरह से दुबले हैं। और मैं YAGNI की ओर झुक गया।

लेकिन इसके लायक क्या है, मैं दूसरे प्रस्ताव से सहमत नहीं हूं, कि "अब पहले से बेहतर है।" यदि कोई आवश्यकता महत्वपूर्ण है, तो उसे पूरा करना होगा। तो "कभी नहीं" एक संभावना नहीं है। यदि यह महत्वपूर्ण नहीं है, तो "अब" बेहतर नहीं है - "कभी नहीं" बेहतर है।

केवल मेरे दो सेंट्स।


और अब मिलियन-डॉलर का सवाल: "महत्वपूर्ण" का क्या मतलब है?
Aaronaught

1
"महत्वपूर्ण" का अर्थ है यह एक स्वीकृति परीक्षण है।
किंडल

महत्वपूर्ण इसका मतलब यह है कि जब यह वहाँ नहीं है ग्राहक hollers।
पॉल नाथन

2
महत्वपूर्ण का अर्थ है कि ग्राहक भुगतान नहीं करता है यदि वह वहां नहीं है।
क्रिस्टोफर महान

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

2

इन दो पैटर्न को कैसे करें वर्गाकार?

वे ऑर्थोगोनल हैं और उनका एक-दूसरे से कोई लेना-देना नहीं है।

यह सुनिश्चित करने के लिए कि आप अच्छा खेलते हैं, आप किन प्रथाओं का उपयोग करते हैं?

उम। क्या वे दोनों? और क्या हो सकता है?

आप भ्रम पैदा किए बिना उन्हें एक साथ कैसे सिखाते हैं?

YAGNI उपयोगकर्ताओं द्वारा देखी गई सुविधाओं का वर्णन करता है। आप कल्पना की जरूरत नहीं है।

अब प्रक्रिया का वर्णन करने से बेहतर है। अब परीक्षण लिखो। अब कोड लिखें। डिजाइन विकल्पों पर विचार करते समय घंटों दूर मत करो। कुछ बनाने के बारे में बात करने के बजाय कुछ बनाएं।


2

यदि "कभी नहीं" "अभी नहीं" का निहितार्थ है, तो आपका डिज़ाइन त्रुटिपूर्ण है।

आपके द्वारा किए गए स्थानीय निर्णय बाकी व्यवस्था के लिए पारदर्शी होने चाहिए।
उदाहरण के लिए, यदि आपके पास एक घटक है CookieSource, जिसे CookieFactoryबंद करने के लिए ए की आवश्यकता होती हैCookieRecipesCookies कुछ इनपुट मापदंडों के आधार पर पता करना है , तो CookieSourceइसकी आवश्यकता नहीं है और इस पर निर्भर नहीं होना चाहिए कि कैसे CookieFactoryलागू किया जाता है और कैसे CookieRecipesप्रतिनिधित्व किया जाता है।
अगर CookieFactoryवास्तव में एक है Bakery, कि कोई भी बात नहीं करनी चाहिए के Recipeअनुसार ले सकते हैं Pastry। और जब तक आपको उस कार्यक्षमता की आवश्यकता नहीं है, तब तक इसे लागू करने की आवश्यकता नहीं है। और दुनिया में कोई कारण नहीं है कि आप इसे बाद में नहीं जोड़ सकते हैं, सिवाय इसके कि इसके CookieSourceऔर सेवाओं के बीच कोई स्पष्ट अमूर्त बाधा नहीं है ।

सॉफ़्टवेयर का निर्माण करते समय, आवश्यकतानुसार कार्यक्षमता जोड़ें और अपने द्वारा किए गए किसी भी निर्णय में स्वयं को लॉक न करने का प्रयास करें। इसके बजाय निर्णय को एक उपयुक्त अमूर्तता में बंद करें


1

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


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

इस दृष्टिकोण के बारे में अच्छी बात यह है कि परिवर्तन कम दर्दनाक हैं; अभी भी बहुत सारे काम शामिल हैं। मुझे यकीन नहीं है कि आप माइग्रेटिंग मॉडल के साथ क्या मतलब रखते हैं - मैं निश्चित रूप से YAGNI की तरफ हूं, लेकिन मैं सबसे खराब तैयारी करता हूं :)
Anteru

0

भविष्य के एक्सटेंशन को ध्यान में रखते हुए डिज़ाइन करें, लेकिन जब तक आपको उनकी ज़रूरत न हो, तब तक उन एक्सटेंशन को लागू न करें।

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.