यदि आवश्यकताएं अक्सर बदलती रहती हैं और आप समय पर अपना कोड वितरित करना चाहते हैं तो स्पेगेटी जाने से निपटने के लिए उपयोग किया जाने वाला सबसे अच्छा समाधान या पद्धति क्या है?क्या अक्सर आवश्यकताओं में परिवर्तन स्पेगेटी कोड का कारण बनता है?
स्पेगेटी कोड की आपकी परिभाषा क्या है? मेरे लिए, स्पेगेटी कोड एक बहुत लंबा, असंगठित और अराजक विधि/कार्य है। यह बदलती आवश्यकताओं के कारण नहीं होता है, लेकिन डेवलपर्स की आलस्य के कारण होता है। यदि आपको एक विधि को फिर से लिखना है क्योंकि चीजें बदल गई हैं, तो आप बिना किसी ओवरहेड के इसे सीधे साफ़ कर सकते हैं।
यदि आप इसके बजाय बुरी तरह से डिज़ाइन की गई ऑब्जेक्ट संरचना का मतलब है, तो आप सही हो सकते हैं। यदि आवश्यकताएं बहुत तेज़ी से बदलती हैं, तो आप आसानी से उन वर्गों के साथ समाप्त हो जाएंगे जो अब उनके लिए किए गए कार्यों, खराब वस्तु पदानुक्रमों और इसी तरह के लिए नहीं किए गए थे।
कुछ tipps इस से बचने के लिए कर रहे हैं:
शुरुआत में overdesign न करें। परिवर्तनों को कम मुश्किल बनाने के लिए अपनी विधियों, कक्षाओं और वर्ग पदानुक्रमों को यथासंभव सरल रखने की कोशिश करें।
एक आवश्यकता बदलावों के बाद, सही तो यह लागू करना शुरू नहीं है, लेकिन एक कदम पीछे जाएं और देखो अपने कोड संरचना से पहले नई सुविधा में फिट कर सकते हैं बदलने की आवश्यकता है।
को संवाद अपने ग्राहक, कि परिवर्तन कुछ समय की आवश्यकता है। यदि आप जानते हैं कि वे जानते हैं कि आवश्यकता को बदलने से आपके कोड की संरचना में परिवर्तन भी शामिल हैं, तो आपके मौजूदा कोड में आपके कोड को निचोड़ने के लिए आपके पास कम दबाव होगा।
कोडिंग करते समय हमेशा रिफैक्टर। मेरे अनुभव में, कई जगहों से एक विधि या कक्षा में अनावश्यक कोड को स्थानांतरित करने जैसे छोटे रिफैक्टरिंग आपके कोड को साफ रखने के लिए सबसे प्रभावी हैं।कोड गंध के लिए हमेशा देखो और अपने काम को आसान बनाने के लिए जितनी जल्दी हो सके उन्हें हटा दें। यह कुछ अनुभव लेता है, लेकिन अब यह प्रशिक्षण शुरू करने का सही समय है :-)
क्रोसेंवॉल्ड की तरह कहा, बड़े बदलावों के डर को दूर करने के लिए अपने कोड में टेस्ट केस जोड़कर इसे सुरक्षित रखें। खुद को एक बड़ी विरासत प्रणाली पर काम करने के बाद, मुझे यह डर पता है और सुरक्षा नेट के बिना काम करने की तरह कैसा लगता है। जब आप पहले अपने सुरक्षा नेट पर काम करते हैं, तो यह निरंतर परिवर्तन करने के लिए एक साहसिक कार्य कम हो जाता है।
मुझे लगता है कि एक महत्वपूर्ण बिंदु कोड लिखना है जो आसानी से परिवर्तनीय है। यह आम तौर पर सार के बजाय विशिष्ट का समर्थन करता है। कुछ डिज़ाइन पैटर्न भी हैं जो आपके कोड के माध्यम से बहुत बड़े स्तंभ बनाएंगे। ऐसे स्तंभों में गलत जगहों में परिवर्तन करने की प्रवृत्ति होती है क्योंकि आप अपने कोड के उन विशाल केंद्रीय टुकड़ों को बदलने से डरते हैं जिन्हें आप वास्तव में बदलना चाहिए।
टेस्ट कवरेज आपको निडर रिफैक्टरिंग करने की अनुमति देने में वास्तव में एक बहुत अच्छा सहायक है। यह पैराशूट है जो पागल और सेन टेस्ट प्लेन पायलट के बीच का अंतर बनाता है।
अच्छा परीक्षण कवरेज लगातार परिवर्तनों के खिलाफ सबसे अच्छा बचाव है।
लगातार आवश्यकताओं के लिएखानपान में परिवर्तन निम्नलिखित का उद्देश्य है:
तो यदि आप स्पेगेटी से बचना चाहते हैं, तो ऊपर उल्लिखित अवधारणाओं को सीखें और लागू करें।
किसी भी आवश्यकता के लिए, अधिकतम संभव परिवर्तनों के लिए अपना कोड डिज़ाइन करें। यह परिवर्तनीय भाग को परिवर्तनीय भाग से अलग करके किया जा सकता है। यह विकास से पहले ज्यादा समय नहीं लेगा। स्पेगेटी कोड आवश्यकता परिवर्तन के कारण ज्यादातर समय प्रकट होता है, और आपका डिज़ाइन और प्रोग्रामिंग इसका सामना करने में सक्षम होना चाहिए।
http://www.dreamsongs.org/Files/DesignBeyondHumanAbilitiesSimp.pdf सहायक होगा।
एक परियोजना की आवश्यकताओं के लगातार परिवर्तन जोड़ना भी शामिल करने के लिए ले या सुविधाओं को हटाने, आवश्यक स्पेगेटी कोड की ओर ले जाता है, लेकिन शायद यह मॉड्यूलर सॉफ़्टवेयर (Modular Programming देखें) नहीं लिखता है।
को देखते हुए अच्छी तरह से आयोजित मॉड्यूल है कि एक साथ, जबकि शिथिल युग्मित किया जा रहा काम (फिर से, इन कार्यों, कक्षाओं, पुस्तकालयों, और पूर्ण आवेदन पत्र हो सकता है), आवश्यकताओं में बदलाव से निपटने के लिए जिस तरह से नए मॉड्यूल लिखने के लिए है, का विस्तार मौजूदा मॉड्यूल पर, और नए तरीकों से मॉड्यूल कनेक्ट करें।
पहली जगह में इन अच्छे सॉफ़्टवेयर मॉड्यूल होने की स्थिति में आप कैसे पहुंचते हैं, refactoring कुंजी है।unit testing जैसे अन्य अभ्यास और एक विकास पद्धति (जैसे Scrum) भी उपयोगी हैं, लेकिन आपकी रोटी और मक्खन रीफैक्टरिंग - और यह एक बात है कि कई व्यावसायिक वातावरण पर्याप्त समय नहीं बनाते हैं।
ढीले युग्मित कोड लिखने पर अच्छी सलाह के लिए, dependency injection पर कुछ शोध करें।
गुंजाइश क्रीप/बुरा आवश्यकताओं के विश्लेषण (कभी बदलते):
प्लेग की तरह सबसे अच्छा सलाह एक किसी भी गुणवत्ता (कोड या अन्यथा) की गारंटी के लिए दे सकते हैं यह बचने के लिए, यह हमेशा नकारात्मक प्रभाव होगा (सभी पर पक्ष) इस पर ध्यान दिए बिना कि आप अपनी विकास परियोजनाओं की योजना बनाने की कितनी अच्छी कोशिश करते हैं।
सबसे अच्छा समाधान मील का पत्थर सेट करना है और यह जानने के लिए कि this link को दिखाने के लिए जो भी आवश्यकताओं को बदलता रहता है।
आप बॉक्स के बाहर सोचने और कोड को जितना संभव हो सके बदलने के लिए अपने दृष्टिकोण में उबर-मानव हो सकते हैं, लेकिन आप अभी भी असफल हो जाएंगे यदि आप समझने के बिना सभी सुविधाओं को हां कहते हैं कि इससे कैसे प्रभावित होना चाहिए परियोजना की गुणवत्ता-समय-स्कोप पिरामिड।
अक्सर-बदलने वाली आवश्यकताओं को एक समस्या है कि Agile विधियों को संभालने के लिए विकसित किया गया था - वे कम से कम आंशिक रूप से समस्या की पहचान में बनाए गए थे कि परिवर्तन, अक्सर बहुत अच्छे कारणों से बदलते हैं।
यदि कोई आवश्यकता बदलती है जिसे आपने पहले ही लागू नहीं किया है, तो प्रभाव कम होना चाहिए यदि आप ऊपर के डिजाइन में अधिक प्रयास नहीं करते हैं लेकिन छोटे पुनरावृत्तियों, निरंतर परीक्षण और रिफैक्टरिंग द्वारा डिज़ाइन विकास का प्रबंधन करते हैं।
यदि कोई आवश्यकता पहले से ही लागू हो चुकी है, और आप अपनी समाप्ति तिथि को स्थानांतरित नहीं कर सकते हैं, तो आपके पास तीन विकल्प हैं: खोए गए समय को पुनर्प्राप्त करने के लिए लंबे समय तक काम करें, अतिरिक्त कार्य के लिए भुगतान करने के लिए आवश्यकताओं को छोड़ दें (दायरे को कम करें) या उत्पाद की गुणवत्ता को कम आप एक सलाह के साथ छोड़ रहे हैं तो ("स्पेगेटी" विकल्प "हो सकता है जो)
:।! refactor, refactor, refactor अक्सर
बाकी सब कुछ के बारे में विवरण है रिफैक्टरिंग आसान बनाना।
+1 @ कार्यान्वयन से पहले पुनर्गठन कोड एनजी एक नई सुविधा – Spoike
करने के लिए एक बहुत ही सरल अभ्यास है ओपी के समान समस्या का सामना करना, मुझे कहना है कि यह एक बहुत उपयोगी और अच्छी तरह से सोचा जवाब था। – rcampbell