भविष्य में बदलाव के लिए डिज़ाइन या हाथ पर समस्या को हल करना [बंद]

Question

कोड लिखते समय या डिज़ाइन के दौरान आप पहली बार में ही समस्या को सामान्य करने का प्रयास करते हैं या उस विशिष्ट समस्या को हल करने का प्रयास करते हैं।

मैं यह इसलिए पूछ रहा हूं क्योंकि समस्या को सामान्य करने की कोशिश करने से चीजें जटिल हो जाती हैं (जो आवश्यक नहीं हो सकती) और दूसरी तरफ आवश्यकता में बदलाव होने पर विशिष्ट समाधान का विस्तार करना बहुत मुश्किल होगा।

मुझे लगता है कि समाधान मध्य मार्ग को खोजने के लिए है जो कि किए गए की तुलना में आसान है। आप इस प्रकार की समस्या से कैसे निपटेंगे? यदि आप इसे सामान्य करना शुरू करते हैं तो आप किस समय जानते हैं कि यह सामान्यीकरण पर्याप्त है?

Comments

यह भी देखें: कोड को फिर से उपयोग के लिए लागत बनाम बचत के लिए सामान्य नि , तीन के नियम में तीसरी बार तक इंतजार करना तर्क?

— कुटकी

यह एक बहुत महत्वपूर्ण प्रश्न है: क्या आप वास्तव में अनुमान लगा सकते हैं कि आवश्यकताएं कैसे बदलेंगी?

— user16764

बहुत से लोग आपको YAGNI बताएंगे। जब आप अपने काम को संभालने के लिए वे लोग हैं जो आप घृणा करते हैं।

— मार्टिन माट

Answer 1

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

अंगूठे के एक नियम के लिए इसे उबालने के लिए: कम अधिक है।

Comments

+1 "भविष्य वह नहीं है जो यह हुआ करता था।"

— डैन लियोन

Answer 2

क्या आप एजाइल से परिचित हैं? एजाइल के बड़े सिद्धांतों में से एक है YAGNI । मुझे लगता है कि चीजों के लिए सबसे अच्छा तरीका है।

"आपको इसकी आवश्यकता नहीं है" ... चरम प्रोग्रामिंग (XP) का एक सिद्धांत है जो बताता है कि एक प्रोग्रामर को आवश्यक समझे जाने तक कार्यक्षमता को नहीं जोड़ना चाहिए। रॉन जेफ्रीस लिखते हैं, "हमेशा चीजों को लागू करें जब आपको वास्तव में उनकी आवश्यकता होती है, तब कभी नहीं जब आप सिर्फ यह सोचते हैं कि आपको उनकी आवश्यकता है।"

... YAGNI XP सिद्धांत के पीछे एक सिद्धांत है "सबसे सरल काम करें जो संभवतः काम कर सकता है" (DTSTTCPW)। इसका उपयोग कई अन्य प्रथाओं के संयोजन में किया जाता है, जैसे कि निरंतर रीफैक्टरिंग , निरंतर स्वचालित इकाई परीक्षण और निरंतर एकीकरण । निरंतर रीफैक्टरिंग के बिना उपयोग किया जाता है, यह गन्दा कोड और बड़े पैमाने पर काम कर सकता है। बदले में निरंतर रिफैक्टिंग स्वचालित यूनिट परीक्षणों पर एक सुरक्षा जाल (अप्रत्याशित कीड़े का पता लगाने के लिए) और निरंतर एकीकरण समस्याओं को रोकने के लिए निरंतर एकीकरण पर निर्भर करता है ...

YAGNI सार्वभौमिक रूप से एक मान्य सिद्धांत के रूप में स्वीकार नहीं किया जाता है, यहां तक ​​कि सहायक प्रथाओं के संयोजन में भी। इसे स्टैंडअलोन का उपयोग करने के बजाय सहायक प्रथाओं के साथ संयोजन करने की आवश्यकता, XP की मूल परिभाषा का हिस्सा है ...

Comments

हालांकि मैं कम या ज्यादा YAGNI से सहमत हूं, मैं इसे चुस्त सिद्धांतों में नहीं पा सकता हूं: agilemanifesto.org/principles.html

— Jens Schauder

"सादगी - काम की मात्रा को अधिकतम करने की कला - आवश्यक नहीं है," YAGNI और कुछ अन्य चुस्त प्रथाओं पर लागू होगी।

— तवान्फोसन

हालांकि यह विशेष रूप से घोषणा पत्र में "YAGNI" नहीं कहता है, मुझे लगता है कि वे एक दूसरे के साथ बहुत अधिक हैं।

@Jens और @Matt, YAGNI, XP के माध्यम से "फुर्तीली" कार्यप्रणाली के रूप में बंडल किए जा रहे हैं। जैसा कि विकिपीडिया लेख में उल्लेख किया गया है कि YAGNI सिद्धांत को रॉन जेफ्रीज़ द्वारा XP कोर प्रथाओं के एक भाग के रूप में विकसित किया गया था।

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

— रॉबर्ट कोरीटनिक

Answer 3

यह संभवतः सॉफ़्टवेयर विकास के सबसे कठिन हिस्सों में से एक है क्योंकि आपको "YAGNI" और "PYIAC" (पेंट योरसेल्फ इनटू ए कॉर्नर) के बीच की रेखा को चलना होगा।

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

कुंजी एक एक्स्टेंसिबल आर्किटेक्चर को डिज़ाइन करने में सक्षम है जहां आप वर्तमान में किसी भी अधिक कोड को लिखने की ज़रूरत नहीं है। इस अच्छी तरह से करने की क्षमता वास्तव में बहुत सारे अनुभव (और दर्द) से आती है।

Answer 4

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

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

Answer 5

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

Answer 6

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

मुझे लगता है कि मैंने अन्य लोगों को इसके प्रभाव के बारे में कुछ कहते सुना है:

मैं पहली बार समस्या हल करता हूं। जब मैं पहली बार अपना समाधान दोहराता हूं, तो मैं इसे नोट करता हूं। जब मैं इसे फिर से दोहराता हूं, तो मैं रिफ्लेक्टर करता हूं।

Answer 7

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

यह प्रोजेक्ट पर निर्भर करता है, और, संक्षेप में, अनुभव आपको सिखाएगा कि "+1" क्या है।

Answer 8

YAGNI का दर्शन , आपको इसकी आवश्यकता नहीं है (इस लेख से) संक्षेप में प्रस्तुत किया जा सकता है:

जो लोग YAGNI दृष्टिकोण की वकालत करते हैं, उनके अनुसार कोड लिखने का प्रलोभन जो इस समय आवश्यक नहीं है, लेकिन भविष्य में हो सकता है, निम्नलिखित नुकसान हैं:

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

Answer 9

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

मूल रूप से, विशिष्ट आवश्यकताओं की एक सूची दी गई है, इसके खिलाफ डिजाइन, हालांकि, इसका मतलब यह नहीं है कि आपको ऐसा नहीं करना चाहिए:

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

"संभव वायदा" के लिए डिजाइनिंग के साथ मुख्य समस्या यह है कि आप हमेशा केवल अनुमान लगा रहे हैं। संभवतः शिक्षित अनुमान लगाते हैं, लेकिन "जब धक्का को धक्का लगता है" तो यह अभी भी अनुमानों की एक श्रृंखला है।

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

वह क्या कह रहा है? "जब आपके पास एक हथौड़ा होता है, तो सब कुछ नाखून की तरह दिखाई देने लगता है।"

काश मेरे पास हर बार एक पाउंड होता है जो मैंने किसी को कहते सुना है, "लेकिन यह एक समाधान है जो उन सामान्य मामलों के लिए अधिक अनुकूल है जो हम भविष्य में देख सकते हैं।"