रिफैक्टरिंग के बाद मेरी टीम लगातार त्रुटियों से कैसे बच सकती है?

20

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

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

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

उन समस्याओं से कैसे छुटकारा पाएं? आप किस तरह की 'घोषणा तकनीक' की सिफारिश कर सकते हैं?

— SDD64
स्रोत

34

स्पष्ट उत्तर टीडीडी है ।

— मौविसील

1

आप कैसे कहते हैं कि "मुख्य विशेषताओं का ओवरराइटिंग नहीं होता है", और फिर आपकी समस्या यह है कि ऐसा होता है? क्या आप "कोर" और "प्रमुख विशेषताओं" के बीच अपनी टीम में अंतर करते हैं, और आप ऐसा कैसे करते हैं? बस स्थिति को समझने की कोशिश कर रहा

— हूं

4

@mouvciel वह और डायनेमिक टाइपिंग का उपयोग नहीं करते हैं , लेकिन इस मामले में उस विशेष बिट की सलाह थोड़ी देर से आती है।

— डोभाल

3

OCaml जैसी जोरदार टाइप की गई भाषा का उपयोग करें।

— गयूस

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

— SDD64

24

मैं माइकल सी। पंख द्वारा लिगेसी कोड के साथ प्रभावी ढंग से कार्य करने की सलाह दूंगा । यह बताता है कि आपको वास्तव में स्वचालित परीक्षणों की आवश्यकता है, आप उन्हें आसानी से कैसे जोड़ सकते हैं, यदि आपके पास पहले से नहीं है, और किस तरह से "कोड बदबू आती है"।

इसके अलावा, आपकी स्थिति में एक और मुख्य समस्या दोनों टीमों के बीच संचार की कमी है। कितनी बड़ी हैं ये टीमें? क्या वे अलग-अलग बैकलॉग पर काम कर रहे हैं?

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

— Tohnmeister
स्रोत

मैंने "द माइथिकल मैन-मंथ" में पढ़ा है कि कोड संरचना आमतौर पर टीम / संगठन संरचना का अनुसरण करती है। इस प्रकार, यह वास्तव में "बुरा अभ्यास" नहीं है, लेकिन जिस तरह से चीजें आमतौर पर जाती हैं।

— मार्सेल

मुझे लगता है कि " सॉफ्टवेयर डेवलपमेंट की गतिशीलता " में, विजुअल C ++ के पीछे का मैनेजर अलग-अलग फीचर टीमों की सिफारिश करता है; मैंने "द मैथिकल मैन-मंथ", @ मार्सेल नहीं पढ़ा है, लेकिन AFAIK ने इंडस्ट्री में बुरे व्यवहारों को सूचीबद्ध किया है ...

— logc

मार्सेल, यह सच है कि यह उसी तरह है जिस तरह से चीजें आमतौर पर जाती हैं या जाती हैं, लेकिन अधिक से अधिक टीमें इसे अलग कर रही हैं, जैसे फीचर टीमें। क्रॉस घटक सुविधाओं पर काम करते समय घटक आधारित टीमों के संचार की कमी होती है। इसके आगे, यह लगभग हमेशा वास्तुशिल्प चर्चाओं में परिणत होता है जो एक अच्छी वास्तुकला के उद्देश्य पर आधारित नहीं होते हैं, लेकिन लोग अन्य टीमों / घटकों को जिम्मेदारियों को आगे बढ़ाने की कोशिश करते हैं। इसलिए, आपको इस प्रश्न के लेखक द्वारा वर्णित स्थिति मिलेगी। यह भी देखें माउण्टोआनेत्सवेयर . com/blog/the-benefits-of-feature-teams ।

— इनहेमिस्टर

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

— डॉक ब्राउन

@DocBrown आप सही हैं। प्रत्येक टीम कोर बदल सकती है। बेशक, उन परिवर्तनों को प्रत्येक परियोजना के लिए फायदेमंद माना जाता है। हालांकि, वे अलग-अलग बैकलॉग पर काम करते हैं। हमारे पास प्रत्येक ग्राहक के लिए एक और कोर के लिए एक है।

— SDD64

41

हम कोर का सबसे खराब हिस्सा अप्रयुक्त हैं (जैसा कि यह होना चाहिए ...)।

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

— जश्न
स्रोत

10

वह और बच्चे के चरणों में और बहुत बार कम करना।

— स्टीफन बिलियट

1

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

— जॉन हैना

मैंने आपको "+1" दिया, लेकिन मुझे लगता है कि "स्वचालित परीक्षण" इसे हल करने का एकमात्र तरीका नहीं है। एक बेहतर मैनुअल, लेकिन व्यवस्थित क्यूए, शायद एक अलग क्यूए टीम द्वारा गुणवत्ता के मुद्दों को भी हल कर सकती है (और यह संभव है कि दोनों के लिए - स्वचालित और मैनुअल परीक्षण)।

— डॉक ब्राउन

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

— लॉग

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

— jb510

5

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

— Buhb
स्रोत

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

— बॉब टवे

5

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

यदि आप रिलीज़ ¹ कर अपने कोर के व्यवहार को रोक देते हैं और आपने उस रिलीज़ को एक निजी विरूपण साक्ष्य प्रबंधन प्रणाली ² में डाल दिया है , तो कोई भी ग्राहक प्रोजेक्ट कोर संस्करण X पर अपनी निर्भरता की घोषणा कर सकता है , और यह अगले रिलीज़ X द्वारा नहीं तोड़ा जाएगा + 1 ।

"घोषणा नीति" तो बस प्रत्येक रिलीज़ के साथ एक CHANGES फ़ाइल होने या प्रत्येक नए कोर रिलीज़ की सभी विशेषताओं की घोषणा करने के लिए एक टीम मीटिंग होने को कम कर देती है।

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

संपादित करें : यदि आप सिमेंटिक संस्करण प्रणाली में सम्मेलनों का पालन करते हैं , तो कोर के एपीआई में किसी भी असंगत परिवर्तन को एक प्रमुख संस्करण परिवर्तन द्वारा चिह्नित किया जाना चाहिए । यही है, जब आप पहले से मौजूद कोर के व्यवहार को बदलते हैं, या कुछ हटाते हैं, न कि केवल कुछ नया जोड़ते हैं। उस सम्मेलन के साथ, डेवलपर्स जानते हैं कि संस्करण '1.1' से '1.2' तक अपडेट करना सुरक्षित है, लेकिन '1.X' से '2.0' तक जाना जोखिम भरा है और सावधानीपूर्वक समीक्षा की जानी है।

^{1: मुझे लगता है कि इसे एक रत्न कहा जाता है, रूबी की दुनिया में}
^{2: जावा में नेक्सस के बराबर या पायथन में PyPI}

— logc
स्रोत

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

— डॉक्टर ब्राउन

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

— लॉग करें

@DocBrown हां, हमने प्रत्येक ग्राहक परियोजना के लिए कोर की एक शाखा का उपयोग करना सीखा। इसके कारण कुछ अन्य समस्याएं हुईं। उदाहरण के लिए हम पहले से ही तैनात ग्राहक प्रणालियों को 'स्पर्श' करना पसंद नहीं करते हैं। नतीजतन, वे प्रत्येक तैनाती के बाद अपने उपयोग किए गए कोर के कई मामूली संस्करण कूद सकते हैं।

— SDD64

@ SDD64: ठीक यही मैं कह रहा हूं - एक सामान्य कोर में तुरंत बदलाव को एकीकृत नहीं करना दीर्घकालिक रूप में भी कोई समाधान नहीं है। आपको अपने मूल के लिए एक बेहतर परीक्षण रणनीति की आवश्यकता है - साथ ही स्वचालित और मैन्युअल परीक्षणों के साथ।

— डॉक ब्राउन

1

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

— लॉग

3

जैसे अन्य लोगों ने कहा, यूनिट टेस्ट का एक अच्छा सूट आपकी समस्या को हल नहीं करेगा: आपको परिवर्तन करते समय समस्या होगी, भले ही प्रत्येक टीम सूट सूट पास हो।

टीडीडी के लिए भी। मैं नहीं देखता कि यह कैसे हल कर सकता है।

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

— मैथ्यू फोर्टिन
स्रोत

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

— SDD64

2

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

— डॉक ब्राउन

2

@ SDD64: आप भ्रमित करने लगते हैं "आपको इसकी आवश्यकता नहीं है (फिर भी)" (जो कि बहुत अच्छी बात है) "आपको अपने कोड को साफ करने की आवश्यकता नहीं है (अभी तक)" - जो कि एक बुरी बुरी आदत है , और IMHO काफी विपरीत है।

— डॉक ब्राउन

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

— लॉग

@DocBrown: ठीक है, शायद हमारी समझ अलग है। उनके द्वारा लिखी गई मुख्य विशेषताएं, अजीब तरह की संभावनाओं को पूरा करने के लिए अत्यधिक जटिल हैं। उनमें से अधिकांश, हमने कभी सामना नहीं किया। जटिलता हमें दूसरी तरफ, उन्हें फिर से भरने के लिए धीमा कर देती है।

— SDD64

2

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

— dolphus333
स्रोत

2

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

प्रश्न कम से कम दो अंतर्निहित समस्याओं को प्रकट करता है: व्यक्तिगत ग्राहकों के लिए आवश्यकताओं को पूरा करने के लिए 'कोर' को संशोधित करने का अभ्यास, और बदलाव करने के लिए अपनी मंशा को संप्रेषित करने और समन्वय करने के लिए टीमों की विफलता। इनमें से कोई भी मूल कारण नहीं हैं, और आपको यह समझने की आवश्यकता होगी कि इसे ठीक करने से पहले ऐसा क्यों किया जा रहा है।

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

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

एक संभावना है कि मैं इसका उल्लेख करने में संकोच करता हूं क्योंकि यह संभावना नहीं है: ग्राहकों की आवश्यकताएं इतनी असमान हैं कि साझा कोर कोड को सही ठहराने के लिए अपर्याप्त समानता है। यदि ऐसा है, तो आपके पास वास्तव में कई अलग-अलग उत्पाद हैं, और आपको उन्हें इस तरह से प्रबंधित करना चाहिए, और उनके बीच एक कृत्रिम युग्मन नहीं बनाना चाहिए।

— sdenham
स्रोत

इससे पहले कि हम अपने उत्पाद को जावा से RoR में माइग्रेट करते, हमने वास्तव में जैसा आपने सुझाव दिया था, वैसा ही किया। हम सभी ग्राहकों के लिए जावा कोर था, लेकिन एक दिन उनकी आवश्यकताओं ने इसे तोड़ दिया और हमें इसे अलग करना पड़ा। उस स्थिति के दौरान, हमें समस्याओं का सामना करना पड़ा: 'यार, ग्राहक वाई में इतनी अच्छी कोर विशेषता है। बहुत बुरा हम इसे ग्राहक Z में पोर्ट नहीं कर सकते, क्योंकि उनका मूल असंगत है '। रेल के साथ, हम कड़ाई से 'सभी के लिए एक कोर' नीति के लिए जाना चाहते हैं। यदि यह होना है, तो हम अभी भी कठोर परिवर्तन की पेशकश करते हैं, लेकिन वे ग्राहक को किसी भी अन्य अपडेट से अलग करते हैं।

— SDD64

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

— SDD64

1

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

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

मूल छद्म कोड:

def someFunction
   do original stuff
   return result
end

अस्थायी इन-प्लेस टेस्ट कोड:

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

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

— कीथ
स्रोत

1

"अधिकतर, टीमों में बदलावों की घोषणा नहीं की जाती है, इसलिए बग लगभग हमेशा अप्रत्याशित रूप से प्रभावित होते हैं"

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

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

— jwenting
स्रोत

1

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

मैं इस बात को स्वीकार करता हूं कि ग्राहक परियोजना शुरू करते समय कोर मॉड्यूल को फ्रीज या कांटा करना संभव नहीं है (अन्यथा तब आपको अपनी कंपनी के कुछ गैर-ग्राहक-संबंधित प्रोजेक्टों को एकीकृत करने की आवश्यकता होती है जो कोर मॉड्यूल को अपडेट करने का लक्ष्य रखते हैं)।

इसलिए हम टीमों के बीच संचार को बेहतर बनाने की कोशिश कर रहे हैं। इसे दो तरीकों से संबोधित किया जा सकता है:

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

आप CI के बारे में अधिक जानकारी एक संचार प्रक्रिया के रूप में यहां पा सकते हैं ।

अंत में, आपको कंपनी के स्तर पर टीम के काम की कमी के साथ एक समस्या है। मैं टीम निर्माण की घटनाओं का बहुत बड़ा प्रशंसक नहीं हूं, लेकिन यह एक मामले की तरह लगता है जहां वे उपयोगी होंगे। क्या आपके पास नियमित रूप से डेवलपर-व्यापी बैठकें हैं? क्या आप अन्य टीमों के लोगों को अपने प्रोजेक्ट रेट्रोस्पेक्टिव्स के लिए आमंत्रित कर सकते हैं? या शायद शुक्रवार शाम को कभी-कभी बीयर पीते हैं?

— sansuiso
स्रोत