आप बड़े कोड आधार और कई डेवलपर्स के साथ रीफैक्टरिंग कैसे प्रबंधित करते हैं?

Question

मैं एक ऐसी स्थिति को रोकना चाहूंगा, जहां दो डेवलपर पहले एक ही कोड को एक साथ रिफलेक्टर करते हैं, इसके बारे में बात किए बिना, शायद किसी तरह के उपकरण का उपयोग कर रहे हैं, शायद एक ग्रहण प्लग-इन। क्या आप मदद कर सकते हैं?

हमें चार महाद्वीपों पर 4.5 मिलियन लाइनों की कोड, और डेवलपर्स की 20 से अधिक टीमें मिली हैं।

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

क्या आप कोई उपाय जानते हैं?

Comments

किसी भी ग्रहण प्लग-इन के बारे में नहीं जानते ... यह संस्करण नियंत्रण प्रणाली के लिए एक नौकरी की तरह लगता है।

— एसएल बर्थ -

आप इसे क्यों रोकना चाहते हैं? क्या यह जटिलताओं (बग) से बचने या डेवलपर समय बचाने के लिए है? समाधान इस IMO के उत्तर पर बहुत निर्भर करता है।

— KaptajnKold

आप कुछ SVN की कोशिश क्यों नहीं करते, Apache Subversion या Tortoise svn इसके लिए ठीक रहेगा।

बीस टीमें एक ही स्रोत को क्यों संपादित करती हैं?

हमारे पास एक वीसीएस है। हम अभी ClearCase से Git में बदल गए हैं।

— रोजर सीएस वर्नरसन

Answer 1

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

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

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

Comments

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

— रोजर सीएस वर्नरसन

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

— डैनियल बी

Answer 2

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

Comments

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

— जियोर्जियो

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

— श्रीराम

क्या इसे स्वचालित किया जा सकता है (प्राथमिकताओं को संग्रहीत करके और लॉक संघर्षों को स्वचालित रूप से हल करके)? या प्रत्येक डेवलपर यह तय करता है कि क्या उनकी रीफैक्टरिंग में उच्च प्राथमिकता है?

— जियोर्जियो

मुझे लगता है कि अगर प्राथमिकताओं को एक सभ्य एपीआई के साथ टास्क एमजीएमटी ऐप में संग्रहीत किया जाता है, तो आप इसे स्वचालित कर सकते हैं। मैंने कभी इसकी कोशिश नहीं की, लेकिन मैं यह नहीं देखता कि ऐसा क्यों नहीं होना चाहिए।

— श्रीराम

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

— रोजर सीएस वर्नरसन

Answer 3

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

Comments

+1: कमिटमेंट और अपडेट अक्सर इसका मतलब यह भी है कि परिवर्तन छोटे और आसानी से प्रबंधनीय हैं, जिससे संघर्ष को प्रबंधित करना आसान हो जाता है।

— ब्रिंजर128

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

— रोजर सीएस वर्नरसन

Answer 4

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

Comments

उन्होंने 20 टीमों की बात की, 20 की टीम की नहीं।

— इंगो

प्रौद्योगिकी के लिए +1 सामाजिक समस्याओं को हल नहीं कर सकता है। लेकिन "20 टीमों के साथ, कुछ संरचना और नियम आवश्यक होंगे" कहने के जवाब को संपादित करें

— मार्कज

कुछ लोग सोते हैं जबकि दूसरे काम करते हैं। हमारे पास चार महाद्वीपों पर टीमें हैं।

— रोजर सीएस वर्नरसन

Answer 5

यदि आप छोड़ते हैं notice that someone else is working on the same piece of code and talk to the first one before modifying anything, तो आपने जो कहा, उसके अनुसार आपको एक संस्करण नियंत्रण प्रणाली (CVS / SVN / GIT) की आवश्यकता है। मुझे यकीन नहीं है, लेकिन अगर आप इसे भी शामिल करना चाहते हैं, तो आपको कुछ उन्नत चीजों (ट्रिगर तंत्र / कुछ कस्टम चीज़ शायद) की आवश्यकता होगी।

Comments

हमें गेट मिल गया है। इससे पहले हमारे पास ClearCase था। VCS समाधान नहीं है। हमें कुछ ट्रिगरिंग तंत्र की आवश्यकता है।

— रोजर सीएस वर्नरसन

Answer 6

स्रोत नियंत्रण में फ़ाइलों को लॉक करने वाले डेवलपर्स को आपकी समस्या को आसानी से हल करना चाहिए, लेकिन फिर मुझे लगता है कि आपको बड़ी समस्याएं हो सकती हैं।

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

Comments

अधिकांश परिवर्तन ऊर्ध्वाधर हैं; जीयूआई, नेटवर्क प्रोटोकॉल, डेटाबेस। प्रत्येक टीम फुर्तीली होती है और हर स्प्रिंट पर ग्राहक मूल्य देने पर ध्यान केंद्रित करती है। हमारे पास डेटाबेस पर एक टीम, GUI पर एक आदि नहीं हो सकता है, यह आसान होगा यदि कोड क्लीनर था। लेकिन कोड साफ करने का मार्ग "कई छोटे रिफैक्टोरिंग" हैं।

— रोजर सीएस वर्नरसन

Answer 7

कुछ बातें:

1. काम करने के लिए अलग मॉड्यूल
2. वे किए गए परिवर्तनों के बारे में बात कर रहे हैं [सभी देवों के साथ]
3. यूनिट परीक्षण [संबंधित चीजों को तोड़ने के लिए सत्यापन और परिहार के लिए]
4. जैसा कि अन्य लोगों ने वीसीएस का उल्लेख किया है

Comments

1. कठिन जब प्रत्येक टीम खड़ी काम करती है 2. कठिन क्योंकि कुछ टीम सोती है जबकि अन्य काम करते हैं। मुद्दे को संबोधित नहीं करते हैं 4. जहां अब गिट पर, पहले ClearCase पर।

— रोजर सीएस वर्नरसन