क्या कोड को साफ करने के लिए नियमित समय निर्धारित करना एक अच्छा विचार है? [बन्द है]

42

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

क्या नियमित समय निर्धारित करना एक अच्छा विचार होगा, हर 2 महीने में 1 सप्ताह, सिर्फ हमारे कोडबेस को साफ करने के लिए?

— user84667
स्रोत

9

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

— gnat

4

कोड समीक्षा के

— l46kok

1

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

— पॉल

एक और "बहुत लोकप्रिय के रूप में बंद", एह, दोस्तों?

— MGOwen

100

नहीं।

जब आप इस पर काम कर रहे हों तो इसे ठीक करें:

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

— MGOwen
स्रोत

2

इस जवाब पर मेरा पैसा ..

— सोनर ग्नुएल

2

उत्कृष्ट उत्तर के लिए +1। आप "गोल्ड-प्लेटिंग" कोड को समाप्त नहीं करेंगे, जिसका कभी भी उपयोग नहीं किया जाता है क्योंकि आवश्यकताएं बदल जाती हैं

— एमडी महबूबुर रहमान

8

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

— बेन

3

ऐसा करने की कोशिश करें लेकिन जब आप नहीं कर सकते (और यह समय के दबाव के कारण होगा या क्योंकि आप बस यह नहीं जानते कि यह कैसे करना है, फिर भी) अपने टिकट सिस्टम में एक टिकट बनाएं। इस तरह से आप उम्मीद कर सकते हैं कि यह वापस आ सकता है जबकि समस्या अभी भी आपके दिमाग में ताजा है और इतना ही नहीं जब यह अंततः समस्याओं का कारण बनने लगती है।

— सरिएन

1

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

— बिल लीपर

21

मेरी व्यक्तिगत राय: यह 90% परियोजनाओं के लिए बिल्कुल आवश्यक है ।

विशेष रूप से उन परियोजनाओं के लिए जो बिक्री से बहुत अधिक प्रेरित हैं, आमतौर पर हर रिलीज में नई सुविधाओं को शामिल करने के लिए एक बड़ा धक्का होता है, और आप अनिवार्य रूप से अपनी बेहतर प्रवृत्ति से समझौता करने और कुछ कूडे / हैक को यहां और वहां पेश करते हैं।

आखिरकार आप इन छोटे समझौतों के माध्यम से पर्याप्त 'तकनीकी ऋण' अर्जित कर लेते हैं, जो कि आप कोड बेस की खामियों के आसपास काम करने में काफी समय खर्च करते हैं, और इसका पूरी क्षमता से उपयोग करने में असमर्थ हैं।

आमतौर पर दो तरह के मुद्दे इस तरह से उत्पन्न होते हैं:

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

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

— pswg
स्रोत

1

मैं फुर्तीली समस्या के रूप में बड़े धक्का की बढ़ी हुई संख्या को नहीं समझता।

— जेफो

2

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

— pswg

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

— जेफ़ो

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

— क्रिस्टोफर हम्मरस्ट्रॉम

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

— मार्किबेमा

11

मेरे पास मेरे डेवलपर चेकइन (तोड़फोड़) से पहले या मुख्य विकास शाखा (Git) के साथ विलय करने के लिए अपने कोड को साफ करते हैं।

मैंने उन्हें निम्नलिखित किया है:

अप्रासंगिक टिप्पणियाँ निकालें
सुनिश्चित करें कि उनके तरीकों, तर्कों और चर को उचित नाम दिया गया है
सुनिश्चित करें कि उनकी कक्षाओं के लिए संरचना है और आइटम एनकैप्सुलेटेड हैं जैसा कि उन्हें होना चाहिए
पठनीयता में सुधार करने और किसी भी कोड को कम करने के लिए रिफ्लेक्टर

बड़ी परियोजनाओं के लिए, कोड की समीक्षा औपचारिक रूप से विकास शाखा से मुख्य शाखा में विलय करने से पहले की जाती है।

मुझे लगता है कि "समर्पित समय" का मतलब होगा कि यह कुछ ऐसा है जिसे स्थगित किया जा सकता है, या काम की मात्रा के कारण इसे बंद कर दिया जा सकता है। डेवेलपर्स इसे प्रति-चेकइन पर करते हैं (जो कि JIRA में एक परिवर्तन अनुरोध / मुद्दे के बराबर है) यह बहुत अधिक प्रबंधनीय है।

— सैम
स्रोत

जिज्ञासा से बाहर: आप दो अलग वीसीएस का उपयोग क्यों कर रहे हैं?

— एखोर्न

2

एक प्रवासी चरण था / है। हमने अब सबसे अधिक SVN रिपॉजिटरी को माइग्रेट किया है, मैंने कुछ संदर्भ के लिए दोनों का उल्लेख किया है।

— सैम

मैं यह करता हूं। एक चेकइन से पहले कोड को साफ करें और अगर मैं कार्यक्षमता में सुधार करने के लिए कोड पर वापस आता हूं तो इसे रीफैक्टर करें।

— बारफील्डम

1

यह उन परेशानियों को संबोधित नहीं करेगा जो उन क्षेत्रों में घूम रही हैं जो उत्पाद टीम से सुविधा अनुरोध का हिस्सा नहीं हो सकते हैं।

— बिल लीपर

9

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

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

— Telastyn
स्रोत

आपका दूसरा वाक्य पहले का खंडन करता है। आपने कहा नहीं, लेकिन फिर कहा कि आप इस तरह की चीजों को हर स्प्रिंट में काम करते हैं। एक तरह से जो इसे करने का समय निर्धारित कर रहा है।

— बिल लीपर

2

@BillLeeper - enh जब मैं "नियमित समय" सुनता हूं तो इसका मतलब है कि सफाई कार्य करने के लिए कुछ नियमित अंतराल है। IMO, यह गलत है - हर समय सफाई का काम करने का सही समय है।

— तेलस्तीन

1

अच्छी बात है, मैं मानता हूँ कि नियमित समय अच्छी तरह से काम नहीं करता है। अक्सर प्राथमिकताएं इसे रद्द करने आदि का कारण बनती हैं

— बिल लीपर

4

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

1 सप्ताह हर 2 महीने में निश्चित रूप से अक्सर पर्याप्त नहीं होता है। यह अधिकांश अन्य उत्तरों के लिए बोलता है, जिन्होंने आपके प्रश्न का उत्तर 'नहीं' में दिया है। इनमें से अधिकांश उत्तरों का सार यह है कि यदि आप बहुत लंबे समय तक प्रतीक्षा करते हैं तो आप अब कोड के संपर्क में नहीं रहेंगे और आमतौर पर इसे ठीक करने / साफ करने में बहुत समय लगता है।

— मॉरिट्ज़ हेन्सन
स्रोत

हम इसके लिए "तकनीकी ऋण मंगलवार" करते हैं। इसके आधे रास्ते ने एक इजरायली काम का सप्ताह फेंक दिया और हमें मुद्दों से निपटने के लिए एक कदम वापस लेने की अनुमति दी

— Zachary K

1

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

आपको इसका उपयोग नहीं करना चाहिए क्योंकि पहली जगह में [सही समाधान, प्रासंगिक इकाई परीक्षण, निरीक्षण आदि को लागू करना] ठीक नहीं है।

— जयन
स्रोत

1

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

दूसरी ओर, "इस पर काम करते हुए इसे ठीक करें" मेरी राय में इसके लिए एक आदर्श इच्छा है। आप अपने कोड को "फिक्स-अप" से और भी अधिक कर सकते हैं

सावधान सहकर्मी
कोड के साथ ही यूनिट परीक्षण लिखना
कोडिंग दिशानिर्देशों को अपनाना
स्वचालित स्वरूपक और लिंटर का उपयोग करना (लेकिन YMMV)
आदि।

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

— einpoklum - मोनिका को बहाल करना
स्रोत

1

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

एक ऐसी परियोजना का प्रबंधन करना, जिसमें कोड ऋण का एक बहुत बड़ा हिस्सा था, नियमित रूप से काम करना इन चीजों को सुचारू रूप से काम करने के लिए महत्वपूर्ण था। हमारी कुछ चीजें बड़ी थीं, कुछ छोटी थीं।

इस तरह के काम के कुछ महीनों के बाद हमारे ऑपरेशन टीम लीड ने मुझे बताया कि सब कुछ कितना सुचारू रूप से चल रहा था।

प्रत्येक आइटम बहुत अधिक नहीं लग सकता है, लेकिन सभी ऋणों की तरह, यह विज्ञापन करता है।

— बिल लीपर
स्रोत

1

आदर्श उत्तर नहीं है, क्योंकि आप इसे आवश्यक बनाने से बचने के लिए आवश्यक कदम उठाते हैं (जैसा कि आप पहले ही बताए गए कई कारणों से साफ करते हैं)।

यह अंत में लक्ष्य हो सकता है, लेकिन आपके पास एक टीम हो सकती है जो इसे व्यवहार में लाने से दूर है।

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

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

आखिरकार, आपको एक समय निर्धारित नहीं करना चाहिए।

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

— JeffO
स्रोत

-1

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

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

— रिकार्डो मोग
स्रोत

इसे रिफैक्टरिंग कहा जाता है कि आप टीडीडी का उपयोग कर रहे हैं या नहीं। इस सवाल का TDD से कोई लेना-देना नहीं है ...

— बेन ली