क्या सालों से स्पेगेटी कोड से बचने का कोई तरीका है?

Question

मेरे पास कई प्रोग्रामिंग नौकरियां हैं I प्रत्येक 20-50 डेवलपर्स के साथ, परियोजना 3-5 साल के लिए चल रही है।

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

और मेरे से अधिक अनुभवी लोग इसे सामान्य मानते हैं। क्या यह? क्या यह होना चाहिए? इससे बचने के लिए मैं क्या कर सकता हूं या क्या मुझे इसे जीवन के तथ्य के रूप में स्वीकार करना चाहिए?

संपादित करें: दोस्तों, मैं यहां प्रतिक्रियाओं की मात्रा और गुणवत्ता से प्रभावित हूं। यह साइट और इसके समुदाय चट्टान!

Answer 1

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

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

उस पर उन्हें बाहर बुलाओ और उनसे यह

मुझे लगता है कि एक कोड की समीक्षा के दौरान बेहतर तरीका उनका कहना है आमतौर पर पर्याप्त जा रहा लोगों को पाने के लिए है बदलने के लिए। अगर वे इसे जांचते हैं और मैं दृढ़ता से महसूस करता हूं, तो मैं इसे खुद दोबारा कर दूंगा।

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

मुझे यह भी लगता है कि इकाई परीक्षण की संस्कृति स्पेगेटी कोड को रोकने में भी मदद करती है। यूनिट टेस्ट स्पेगेटी कोड के लिए यह बहुत कठिन है जो अच्छी तरह से फैक्टर कोड है। समय के साथ यह लोगों को कुछ हद तक फैक्टर रखने के लिए मजबूर करता है।

Answer 2

20 से 50 डेवलपर शायद समस्या है। यह बहुत अधिक है और सब कुछ जांच में रखने के लिए बहुत सारे प्रबंधन और संसाधनों की आवश्यकता होगी।

मैं परियोजना को छोटे पुन: प्रयोज्य खंडों में विभाजित करने पर विचार करता हूं। कोर सिस्टम से दूर कुछ परतों सार।

Answer 3

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

इन एपीआई को पत्थर में डालना नहीं है - आपको तब तक चीजों को जोड़ने में सक्षम होना चाहिए, जब तक आप सुनिश्चित करते हैं कि आप फ़ायरवॉल को प्रदूषित नहीं कर रहे हैं।

Answer 4

अधिक कोड समीक्षा और शायद कोड स्वामित्व।

यदि आप कुछ यादृच्छिक कोड हैक करते हैं तो आपको उस कोड के जितना अधिक ध्यान नहीं है जितना आप "स्वयं" करते हैं। यदि परियोजना के एक मॉड्यूल को बनाए रखना आपकी ज़िम्मेदारी है, तो आप चमकना चाहते हैं।

और कोड समीक्षा एक समय है जब आप अपना कोड दिखाते हैं।

Answer 5

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

Answer 6

Refactoring

प्रयास संभव के रूप में स्वच्छ के रूप में डिजाइन रहते हैं। यह आसान नहीं है, लेकिन यह प्रयास के लायक है।

Answer 7

ऐसा लगता है कि कई लोग encapsualtion और अच्छे डिज़ाइन के कुछ बुनियादी सिद्धांतों का पालन नहीं कर रहे हैं।

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

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

Answer 8

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

Answer 9

मुझे लगता है कि मुख्य बिंदु जब आप कहते हैं

तुम सिर्फ खरोंच

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

Answer 10

मुझे नहीं लगता कि यह सामान्य है। इस बात से लड़ना वाकई मुश्किल है जब यह कुछ सालों से था।

"रवैया चुस्त डेवलपर्स सॉफ्टवेयर के डिजाइन की ओर है कि एक ही रवैया सर्जन बाँझ प्रक्रिया की ओर है कि है:

एक ही तरीका है यह से बचने के लिए रुख बदलने के लिए है। स्टेरिल प्रक्रिया सर्जरी संभव बनाता है। इसके बिना, संक्रमण का जोखिम सहन करने के लिए बहुत अधिक होगा। Agile डेवलपर्स अपने डिजाइन के बारे में एक ही तरह से महसूस करते हैं।दे के खतरे को भी सड़ांध का सबसे नन्हा सा शुरू भी बर्दाश्त करने के लिए अधिक है। " मार्टिन सी रॉबर्ट " फुर्तीली सिद्धांतों, पैटर्न, और सी # "

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

शुभकामनाएं!

Answer 11

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

आप इसके बजाय अत्यधिक विखंडन के लिए नेतृत्व कर सकते हैं, लेकिन यह एक और मुद्दा है और वैश्विक संरचनात्मक समस्या से कम है।

Answer 12

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

Answer 13

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

Answer 14

नहीं

:)

Answer 15

कोड समीक्षा, मानक, और फर्म नीतियों कोडिंग।

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

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

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

याद रखें, प्रक्रिया में किए गए किसी भी बदलाव में पुशबैक शामिल होगा। जिस तरह से हमने इसे कम करने में मदद की है, वह नीतियों को हमारे पुराने संस्करण नियंत्रण/दोष ट्रैकिंग सिस्टम से संक्रमण के लिए प्रशिक्षण में बनाना है।

Answer 16

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

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

इससे बचने के लिए, या तो एक ही 'पेज' पर सभी कोडर प्राप्त करें, अपने सम्मेलन का सामान्य कोड हिस्सा बनाएं, या नौकरियों के बाद पीछा करें विकास दल छोटे (1-3 लोग) हैं और आप हैं बड़ा कहूना किसी दिन बड़ी टीमों को बेहतर सामान बनाने का एक तरीका मिल सकता है, लेकिन तब तक उनमें से सर्वश्रेष्ठ भी भाग्यशाली हैं यदि वे सिर्फ 10 में से 6 के करीब आ सकते हैं। हम निम्न गुणवत्ता वाले सॉफ्टवेयर का निर्माण करते हैं क्योंकि हमने यही स्थापित किया है हमारे उद्योग को करने के लिए ...

पॉल।

Answer 17

मेरा मानना ​​है कि कोड सड़कों से बचने की कुंजी ध्वनि नीचे डिजाइन और कार्यान्वयन पद्धतियों में निहित है (मुझे विश्वास है कि मैंने अपना व्यवसाय नाम दिया - इसके बाद नीचे सोचो - इसके बाद!)। पसंद के उपकरण यहां हैं:

• decoupling सामान्य समाधान
• चौखटे हल्के, सरल रखें और की तलाश में, हमेशा मन में पुन: उपयोग के साथ निर्माण पर अनुबंध
• स्तरित डिजाइन
• फोकस द्वारा प्रोग्रामिंग केंद्रित

अन्य उत्तरदाताओं द्वारा सुझाए गए अनुसार, आपको जल्दी ही समस्याओं को पकड़ने की आवश्यकता है। हरे रंग के डेवलपर्स के साथ, इसका मतलब है सलाह देना (जोड़ी प्रोग्रामिंग यहां बहुत अच्छी है) और समीक्षा (कोड और डिज़ाइन समीक्षा)। अधिक वरिष्ठ डेवलपर्स के साथ, इसका मतलब सतर्कता है।

सबसे अधिक, रिफैक्टरिंग से डरो मत। यदि रिफैक्टरिंग आपको डराता है, तो आप पहले से ही डूब गए हैं। यदि रिफैक्टरिंग को "खराब" के रूप में देखा जाता है, तो आपके व्यवसाय में कुछ गड़बड़ है।

जब आप कुछ ठीक करते हैं, तो इसे ठीक से ठीक करें। मैं गलत तरीके से किए गए एक फिक्स का वर्णन करने के लिए "फक्स" शब्द का उपयोग करता हूं: यह आपके कोड बेस को "फक्स" करता है।

चीयर्स,

दान

Answer 18

कोड आँखों के कम से कम दो जोड़े तक के लिए प्रतिबद्ध होना करने के लिए अनुमति न दें यह देखा है।

Answer 19

Shore and Warden's The Art of Agile Development "एक मौजूदा परियोजना में एक्सपी लागू करना" (अध्याय 4 में) पर एक अनुभाग के साथ एक महान पुस्तक है। जब तक आप कड़ी मेहनत नहीं करते हैं तब तक परियोजनाएं खराब हो जाती हैं: ऐसे तकनीकी ऋण पर काबू पाने में मुश्किल होती है और स्वीकार्य रिलीज को शिप करना मुश्किल हो जाएगा। एकमात्र समाधान उस दर को कम करना है जिस पर आप नई सुविधाएं प्रदान करते हैं, और परीक्षण कवरेज और रीफैक्टरिंग में सुधार के समय को बचाते हैं।

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

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

संक्षेप में, प्रत्येक हफ्ते में थोड़ा सा समय बिताएं, और सुनिश्चित करें कि इस हफ्ते की तुलना में कोड अगले हफ्ते बेहतर होगा।