अनियोजित, गंदे कोड का आयोजन?

Question

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

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

अब, मेरे पास निम्नलिखित प्रश्न हैं:

1. क्या हमें कोड को सुधारना चाहिए, और इसे OOP में बदलना चाहिए? हम अब इसे डीबग कर रहे हैं।
2. कोड में कोई टिप्पणी नहीं है, कोई दस्तावेज नहीं है, प्रोग्रामिंग की कोई विशेष शैली नहीं है, और इसके आगे। इसे बदलना वास्तव में महंगा और समय लेने वाला है। इस बारे में हम क्या कर सकते हैं?
3. मैं उन्हें सभी नियमों (टिप्पणी, OOP, अच्छी कोड गुणवत्ता, आदि) का पालन करने के लिए कैसे सिखा सकता हूं?
4. कोड त्रुटिपूर्ण है और त्रुटि प्रवण है। हम क्या कर सकते है? परिक्षण? हम सुधार के लिए लगभग दो या तीन ए 4 पेपर लिखते हैं, लेकिन यह अंतहीन लगता है।

मुझे यह कहना चाहिए कि मैं उनके साथ नया हूं। मुझे लगता है कि मैंने प्रोजेक्ट में बहुत देर से लोगों को जोड़ने के नियमों को तोड़ा है, साथ ही साथ। क्या आपको लगता है कि मुझे उन्हें छोड़ना होगा?

Comments

इसे दो या तीन प्रश्नों में विभाजित करने की आवश्यकता है, यह फिलहाल बहुत व्यापक है।

— जॉन हॉपकिंस

क्या यह परियोजना संस्करण नियंत्रण में है?

— JBRWilkinson 18

क्या उत्पादन में वर्तमान कोड है?

— 19

हाँ जेफ़। यह एक उत्पादन, एक वित्तीय मुद्दों के प्रबंधन के लिए एक प्रबंधन परियोजना है!

— सालिवन

क्षमा करें, जेबीआर, उन्होंने इस तरह की बात नहीं सुनी। हार्ड डिस्क पर कॉपी पेस्ट कोड का एक कूप बनाना बस संस्करण को नियंत्रित करने के लिए उनकी तकनीक है।

— सालिवन

Answer 1

चरण ०: SCM का बैकअप

क्योंकि, टिप्पणियों में JBRWilkinson द्वारा संकेत दिए जाने के कारण, संस्करण नियंत्रण आपके (अपरिवर्तनीय) आपदा के खिलाफ रक्षा की पहली पंक्ति है।

बैकअप सॉफ़्टवेयर कॉन्फ़िगरेशन विवरण, डिलिवरेबल्स बनाने की प्रक्रिया आदि भी करें ...

चरण 1: पहले टेस्ट करें

फिर परीक्षण लिखकर शुरू करें :

• किस काम के लिए,
• और जो विफल रहता है।

कोई फर्क नहीं पड़ता कि आप क्या करने का फैसला करते हैं, आप कवर किए जाते हैं। अब आप या तो कर सकते हैं:

• शुरू खरोंच से और पुनर्लेखन ,
• या इसे ठीक करें ।

मेरी सलाह यह होगी कि सामान्य आर्किटेक्चर को स्क्रैच से शुरू किया जाए , लेकिन मेस से उन हिस्सों को निकाला जाए जो चौकियों को मान्य करते हैं और इन्हें फिट करने के लिए इन्हें रिफ्लेक्टर करते हैं।

चरण 2: सत्यापित करें और मॉनिटर करें

एक सतत एकीकरण प्रणाली स्थापित करें ( चरण 0 और चरण 1 के पूरक के लिए ) और एक सतत निरीक्षण प्रणाली ( चरण 4 के लिए तैयार करने के लिए )।

चरण 3: दिग्गजों के कंधों पर खड़े हो जाओ

(जैसा कि आपको हमेशा करना चाहिए ...)

• प्रतिरूपों के प्रतिवर्तन
• Refactoring: मौजूदा कोड के डिजाइन में सुधार ।
• प्रभावी रूप से लिगेसी कोड के साथ काम करना (जैसा कि जेसन बेकर द्वारा अनुशंसित )
• पुनर्रचना

चरण 4: साफ

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

फिर आप एक कोड फॉर्मेटर भी चलाना चाहते हैं, जो पहले से ही हाउसकीपिंग के साथ थोड़ी मदद करेगा।

चरण 5: समीक्षा करें

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

चरण 6: अपनी विकास प्रक्रिया का भविष्य-प्रमाण

यदि यह पहले से ही नहीं है, तो उपरोक्त सभी को लें, और इसे अपनी सामान्य विकास प्रक्रिया का एक अंतर्निहित हिस्सा बनाएं। अपनी घड़ी पर फिर से ऐसा न होने दें, और अपनी टीम के साथ मिलकर अपनी प्रक्रिया में सुरक्षा उपायों को लागू करें और अपनी नीतियों में इसे लागू करें (यदि यह संभव हो तो)। उत्पादन संहिता को प्राथमिकता दें।

---

लेकिन वास्तव में, परीक्षण । बहुत कुछ ।

Comments

एक महान सुझाव - इससे कोई फर्क नहीं पड़ता कि अगर आपके पास परीक्षण हैं जो समस्याओं को पकड़ सकते हैं तो आपको क्या नुकसान होता है। बेशक, हम सब मान रहे हैं कि उनका पहले से ही संस्करण नियंत्रण है ..

— JBRWilkinson

@JBRWilkinson: वास्तव में अच्छी बात है! दरअसल, पूरी तरह से मान लिया है कि वे किया था।

— 18

पहले संस्करण नियंत्रण शुरू करें; देर आए दुरुस्त आए।

— 19

@ जेफ ओ: हां, यह पहले से ही है जो मैंने उत्तर में जोड़ा है।

— ज्येष्ठ रात्रि

संपादन के बाद स्पष्ट करने के लिए फिर से लिखना। बायां

— आक्षेप

Answer 2

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

Comments

व्यापक बाहरी संदर्भ के उपयोग के लिए +1 जो यह कहता है।

— हाइलम

दुर्भाग्य से, यहां लोगों को किताबें पढ़ने के बारे में कोई पता नहीं है। बस एक परियोजना विकसित करना जो यह काम करता है वह सब उनकी जरूरत है। मैंने आपको-उल्लिखित पुस्तक और CODE COMPLETE 2 भी पढ़ना शुरू किया। मुझे कहना है कि वे आश्चर्यजनक रूप से लिखे गए हैं।

— सालिवन

@ सलिवन - शायद उन्होंने अभी तक किसी को नहीं समझा है कि ऐसी किताबें पढ़ने लायक हैं। अगर केवल एक व्यक्ति था जो उनके साथ काम करता था जो इस तरह की किताबें पढ़ने में रुचि रखते थे ...

— जेसन बेकर

@ सलिवन - महत्वपूर्ण बात यह है कि एक त्वरित जीत या दो। कुछ ऐसा करें जिसमें लगभग तत्काल पेबैक हो। संस्करण नियंत्रण की तरह, इसलिए अगली बार कोई कहता है कि "यह कैसे हुआ" आप इसे देख सकते हैं। फिर WELC की अपनी कॉपी को पढ़ने से उन्हें कुछ सुझावों में ले जाएँ। बस उन पर किताब फेंक मत करो।

@ सालीवान आप उनके लिए किताबें पढ़ सकते हैं, और ड्रिप सलाह के रूप में उन्हें सामग्री खिला सकते हैं। आप टीम के गुरु बन सकते हैं।

— MarkJ

Answer 3

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

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

रीफैक्टरिंग की बात (जैसा कि फाउलर की किताब और केरिविस्की के एक http://www.industriallogic.com/xp/refactoring/ ) में है कि यह सिस्टम को काम करता रहता है, हो सकता है कि रिफैक्टरिंग को दोहरा समय लगेगा लेकिन जोखिम शून्य है।

खरोंच से फिर से शुरू करना कई जोखिमों को पेश कर सकता है, गलतफहमी की आवश्यकताओं से लेकर गलत कार्यान्वयन तक (बाद में टीम के अधिकांश हिस्से समान होंगे)।

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

Comments

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

— माइकल के

यह बिना कहे चला जाता है ... मैं TDD को किसी भी अच्छे कोड (नया उर्फ) के लिए आवश्यक मानता हूं।

— Uberto

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

— Salivan

परीक्षण प्रेरित विकास की सराहना की है!

— सालिवन

"लेकिन यदि आप संबंधों को निकालने के लिए कोड का विश्लेषण करना चाहते हैं तो आप क्या करेंगे?" -> यदि यह मामला है तो इसका मतलब है कि परियोजना न तो छोटी है और न ही टूटी हुई है। अका मैं समय पर एक टुकड़ा refactoring करना शुरू कर देंगे। मिकादो विधि भी देखें। danielbrolund.wordpress.com/2009/03/28/…

— Uberto

Answer 4

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

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

Comments

इसे पूरी तरह से पुन: लिखने में कितना खर्च आएगा? कौन सा दृष्टिकोण परिणाम सबसे तेज देगा?

— JBRWilkinson 18

@JBRWilkinson यह निर्भर करता है। जब आपके पास वर्किंग कोड हो, तो पुनरावृति दृष्टिकोण अच्छा होता है।

— 18

@duros, टूटे हुए कोड के लिए, हाँ। यह कोड उत्पादन में चलता है।

Answer 5

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

अच्छा ब्लॉग बता रहा है कि नेटस्केप क्यों ढीला है

Comments

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

— जेफओ

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

— सालिवन Sal

@ सालीवन ... किसी भी नए कोड को लिखने से दूर रहने की जरूरत है । मुझे यकीन है कि प्रबंधन यह कह रहा है। लेकिन पहली बात यह है कि जब आप एक छेद में होते हैं तो खुदाई बंद कर देते हैं (वही गलतियाँ करना जारी रखें)। इन स्थितियों के तहत अधिक निर्माण की अनुमति देने के लिए छेद खोदना जारी रखना है। मुश्किल यह है कि मुद्दों को समझने के लिए प्रबंधन और कोडर्स कैसे प्राप्त करें।

— सेरमा

Answer 6

यदि यह काम करता है, तो इसे रिफलेक्टर करें। ऐसा करने में आपकी मदद करने के लिए उपकरण हैं। यदि यह काम नहीं करता है, तो जादुई कोड सुधार कमांड का उपयोग करें, अर्थात deltreeविंडोज सम्मान पर। rm -rfलिनक्स पर।

Comments

"सभी कोड को पूरी तरह से मिटाने" का सुझाव विशेष रूप से अनपेक्षित है - क्या आपके पास अधिक रचनात्मक उत्तर है?

— JBRWilkinson

जबरदस्त हंसी। मैं आपसे पूरी तरह सहमत हूँ, बारूद!

— सालिवन an

JBRWilkinson: नए सिरे से काम करना सबसे अधिक संभावना है कि गंदगी को काम करने और साफ करने की कोशिश करने से बेहतर दृष्टिकोण है। मैंने जिस कंपनी के लिए काम किया है, और साल-दर-साल, उन्होंने बहुत सारे संसाधन बर्बाद किए हैं और बिल्कुल नहीं मिला है।

— user281377

@ammoQ, आपको यह देखने के लिए पुराने कोड की आवश्यकता है कि यह वास्तव में क्या किया है, जब आप इसे गलत करते हैं।

Thorbjorn: हम उस कोड के बारे में बात कर रहे हैं जो काम नहीं करता है , है ना? अनियोजित, गंदे कोड का विश्लेषण जो सही काम नहीं करता है, मुझे इसके रचनाकारों की मानसिक स्थिति के बारे में कुछ और बताता है।

— user281377

Answer 7

क्या हमें कोड को सुधारना चाहिए, और इसे OOP में बदलना चाहिए? हम अब इसे डीबग कर रहे हैं। [... इसमें त्रुटियाँ हैं, कोई दस्तावेज़ नहीं है ...]

मैं वहाँ गया था, आप मेरी सहानुभूति है। मैंने इस बारे में एक लेख भी लिखा है जो आपको कुछ परिप्रेक्ष्य प्राप्त करने में मदद कर सकता है। लेकिन संक्षेप में:

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

मैं उन्हें सभी नियमों का पालन करना कैसे सिखा सकता हूं?

यह समझाने के साथ शुरू करें कि वे ऐसा क्यों करना चाहते हैं, यह दिखा कर कि वे व्यक्तिगत रूप से इससे क्या हासिल कर सकते हैं। जब वे इस बात से सहमत हो जाते हैं और सीखने के लिए तैयार हो जाते हैं, तो उन्हें शुहारी का इस्तेमाल करना सिखाना शुरू कर दें ।

Comments

धन्यवाद मार्टिन। "यह समझाने के साथ शुरू करें कि वे ऐसा क्यों करना चाहते हैं, यह दिखा कर कि वे इससे व्यक्तिगत रूप से क्या हासिल कर सकते हैं। जब वे इस बात से सहमत होते हैं और सीखने के लिए तैयार होते हैं, तो उन्हें शुहारी का उपयोग करना सिखाना शुरू करें।"

— सालिवन Sal

Answer 8

मेरा सुझाव @ duros's & @Manoj R के उत्तरों का संयोजन है।

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

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