टीमों के साथ नाम बदलने, रीफैक्टरिंग और ब्रेकिंग परिवर्तन के लिए सर्वोत्तम अभ्यास


10

टीम के वातावरण में नाम बदलने और नाम बदलने के लिए कुछ सर्वोत्तम अभ्यास क्या हैं? मैं इसे कुछ परिदृश्यों को ध्यान में रखते हुए लाता हूं:

  1. यदि एक पुस्तकालय जिसे आमतौर पर संदर्भित किया जाता है, उसे किसी भी पुस्तकालय या परियोजना के लिए एक ब्रेकिंग परिवर्तन को प्रस्तुत करने के लिए फिर से सक्रिय किया जाता है जो इसे संदर्भित करता है। उदाहरण के लिए, एक विधि के नाम को मनमाने ढंग से बदलना।

  2. यदि परियोजनाओं का नाम बदला जाता है और समाधानों को उनके अद्यतन संदर्भों के साथ फिर से बनाया जाना चाहिए।

  3. यदि प्रोजेक्ट संरचना को फ़ोल्डरों को प्रस्तुत करने और मौजूदा परियोजनाओं या समाधानों को नए स्थानों पर ले जाकर "अधिक संगठित" किया जाता है।

कुछ अतिरिक्त विचार / प्रश्न:

  1. क्या इस मामले में परिवर्तन होना चाहिए या परिणामस्वरूप दर्द संरचना में गड़बड़ी का संकेत है?

  2. ब्रेकिंग चेंज से संबंधित त्रुटियों को ठीक करने की जिम्मेदारी किसे लेनी चाहिए? यदि कोई डेवलपर परिवर्तन करता है तो उन्हें प्रभावित परियोजनाओं में जाने और उन्हें अपडेट करने के लिए जिम्मेदार होना चाहिए या क्या उन्हें अन्य डेवलपर्स को सचेत करना चाहिए और उन्हें चीजों को बदलने के लिए संकेत देना चाहिए?

  3. क्या यह कुछ ऐसा है जो एक निर्धारित आधार पर किया जा सकता है या यह कुछ ऐसा है जिसे जितनी बार संभव हो किया जाना चाहिए? यदि एक रिफैक्टिंग को बहुत लंबे समय के लिए बंद कर दिया जाता है, तो सामंजस्य करना मुश्किल हो जाता है, लेकिन एक दिन में 1 घंटे का खर्च कहीं और होने वाले परिवर्तनों के कारण एक बिल्ड को ठीक करना है।

  4. क्या यह एक औपचारिक संचार प्रक्रिया का मामला है या यह जैविक हो सकता है?


1
प्रत्येक बार $ 1 को चार्ज करें जब भी वे निर्माण को तोड़ते हैं ... आपको आश्चर्य होगा कि यह लापरवाह गलतियों पर कितना अंकुश लगाता है।
बेरिन लोरिट्श

+1 क्योंकि आपकी टिप्पणी ने 3 उत्कृष्ट - और अलग - अलग उत्तरों को प्रेरित किया।
कार्ल मैनस्टर

जवाबों:


13

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

इसलिए मार्टिन फॉलर से इस बारे में नंबर एक सलाह आपके इंटरफेस (परियोजना के नाम और संरचनाएं) को समय से पहले प्रकाशित नहीं करती है

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

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


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

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

5

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


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

4

ध्यान दें कि बिल्ड सर्वर के लिए प्राथमिक कारणों में से एक है, जो परीक्षण चलाता है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.