राड वातावरण में रिलीज की गुणवत्ता में सुधार करने के लिए एक सरल तरीके

Question

यहाँ एक पृष्ठभूमि के एक बिट - हम आरएडी डेवलपर्स की एक छोटी टीम (5) एक बड़ी गैर-सॉफ्टवेयर कंपनी में आंतरिक सॉफ्टवेयर विकास के लिए जिम्मेदार हैं। "आंतरिक सॉफ़्टवेयर" एक डेस्कटॉप .NET अनुप्रयोग से भिन्न होता है जो MSSQL सर्वर का उपयोग करके MS Word दस्तावेजों और टेम्प्लेट की पृष्ठभूमि पर चल रहे पायथन स्क्रिप्ट के बैकएंड के रूप में होता है - प्रौद्योगिकियों का एक चिड़ियाघर।

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

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

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

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

1. वर्तमान में कुछ एप्लिकेशन उपयोगकर्ता स्वीकृति परीक्षण को दरकिनार कर सीधे डेवलपर परीक्षण के बाद उत्पादन में जारी किए जा रहे हैं। उस प्रथा को बंद किया जाना चाहिए और यहां तक ​​कि एक छोटे से बदलाव को एक अंतिम-उपयोगकर्ता द्वारा परीक्षण किया जाना चाहिए। प्रत्येक एप्लिकेशन में अंतिम उपयोगकर्ताओं से एक समर्पित बीटा-टेस्टर होगा। बीटा-टेस्टर के नई रिलीज के ठीक बाद ही इसे टेस्ट से प्रोडक्शन के माहौल में प्रमोट किया जाता है।

2. हम कोड की समीक्षा नहीं करते हैं - लेकिन हम बदलावों की जांच करने से पहले कोड समीक्षा करना शुरू कर देंगे। मैं "रोलआउट रिव्यू" के बारे में भी सोच रहा था - मूल रूप से डेवलपर्स में से एक को बैठकर दूसरी घड़ी के साथ बैठना पड़ता है, सॉफ्टवेयर रोलआउट (कॉपी बायनेरिज़, अपडेट कॉन्फिग, डेटाबेस में नई तालिका जोड़ना) आदि - यह आमतौर पर केवल 5-10 मिनट लगते हैं, इसलिए इसमें "रोलआउट समीक्षा" का समय नहीं लगेगा।

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

यह वह जगह है जहां हम अपने विचारों से बाहर भाग गए और हम इन पर आपकी प्रतिक्रिया प्राप्त करना चाहते हैं और यदि आप कुछ सरल रिलीज / देव प्रक्रिया सुधार सलाह साझा कर सकते हैं - तो यह भयानक होगा।

Comments

स्वचालित इकाई परीक्षण और CI लगता है कि जिस तरह की चीज़ की आपको ज़रूरत है।

— रेयनोस

Answer 1

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

मैंने हालांकि इस पर बहुत सीमित साहित्य देखा है, यह वह है जो हम अभ्यास करते हैं जो निश्चित रूप से मदद करता है:

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

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

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

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

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

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

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

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

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

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

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

Comments

कुडोस। यह उत्तर अधिकांश ऑनलाइन ट्यूटोरियल

— Ubermensch

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

— S.Robins

@DipanMehta प्रश्न नए-हास्य से प्रतीत होता है और इसने एक ऐसे उत्तर की वकालत की है जो मौजूदा चीजों पर निर्माण करने के लिए उसे एक व्यापक परिप्रेक्ष्य दे सकता है ताकि वह विशिष्ट हो और आपका उत्तर वास्तव में उसके करीब हो।

— Ubermensch

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

— रॉबिन्स

+1 के लिए "यह प्रक्रिया को सही करने के लिए बेहतर है, और फिर उपकरण से मिलान करने के लिए उपकरण के बजाय फिट करने के लिए उपकरण

— ढूंढें

Answer 2

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

हमारी प्रक्रिया को बेहतर बनाने के लिए मैंने एक कंबन बोर्ड की शुरुआत की । बोर्ड के साथ शुरू करने के लिए बहुत सरल था और केवल कुछ कॉलम थे (एक व्हाइटबोर्ड, इंडेक्स कार्ड और रंगीन मैग्नेट का उपयोग करके सेटअप):

बैकलॉग | करने के लिए | किया हुआ

हालांकि, यह जल्दी से हमारी वास्तविक प्रक्रिया को प्रतिबिंबित करने के लिए विकसित हुआ:

बैकलॉग | विकास | देव। टेस्ट | UAT | हो गया | रिहा

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

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

एक तरफ के रूप में, हम रंगीन मैग्नेट (एक प्रति डेवलपर) का उपयोग उस कार्ड को ध्वजांकित करने के लिए करते हैं, जिस पर हम जिज्ञासावश काम कर रहे हैं, लेकिन एक अन्य विकल्प है स्विम लेन (पंक्तियाँ) जोड़ना, एक प्रति डेवलपर और प्रासंगिक स्विमिंग लेन में कानबन कार्ड रखना। फिर से यह एक त्वरित संदर्भ के रूप में देखने में मदद करता है कि प्रत्येक डेवलपर वर्तमान में क्या काम कर रहा है।

अन्य लिंक जो मुझे उपयोगी लगे:

कानबन ने सॉफ्टवेयर डेवलपमेंट के लिए आवेदन किया: एजाइल से लीन तक

सॉफ्टवेयर इंजीनियरिंग के लिए एक कंबन सिस्टम - वीडियो

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

Answer 3

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

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

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

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

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

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

Comments

मैं अपनी टीम को "आरएडी" डेवलपर्स की टीम के रूप में संदर्भित कर रहा था ताकि इस तथ्य पर जोर दिया जा सके कि हम "रैपिड एप्लीकेशन डेवलपमेंट" के व्यवसाय में हैं, जहां विकास चक्र बेहद कम हैं। इसलिए इसे RAD टूल्स या IDE से कोई लेना देना नहीं है। आपके जवाब के लिए धन्यवाद।

— पीटर

@PeterT: आह! गलतफहमी के लिए मेरी माफी। मुझे आपके तीसरे पैराग्राफ को स्किम करना चाहिए और संदर्भ से चूकना चाहिए। मैं अपने उत्तर को सूट करने के लिए संपादित करूंगा, हालांकि मुख्य में सलाह अभी भी संदर्भ में बनी हुई है। :-)

— रॉबिन्स

Answer 4

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

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

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

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

Answer 5

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

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

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

C / C ++ प्रोग्राम्स के लिए, मैंने पाया कि मेमोरी एलोकेशन को परखने के लिए प्रोग्राम जोड़ना प्रोग्राम में मेमोरी लीक की संख्या को कम करने में बहुत मददगार था।

Comments

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

— पीटर १

यह तुरंत भुगतान करना होगा क्योंकि आपको नई सुविधाओं / बग-फिक्स के लिए प्रत्येक रिलीज में एस्कॉर्ट्स / कंडीशन-चेकिंग के साथ शुरुआत करनी होगी। यह पूरी परियोजना को एक ही बार में जोड़ने के लिए एक बड़ा काम होगा; पी

— रुडोल्फ ओलाह

हालांकि जोर देने के साथ एक बात है - क्या हुआ अगर यह गलत है। क्या होगा यदि हम विधि को केवल 10 और 25 के बीच की संख्या स्वीकार करते हैं, लेकिन वास्तव में यह सीमा को चौड़ा करने के लिए ठीक है [0; 50] और यह केवल एक नई रिलीज के बाद रोल आउट होने और उत्पादन के लिए उत्पादन में पाया गया था; दिन। यदि एक quesiton के तहत एक विधि एक निम्न-स्तरीय एक है और कई जगहों पर उपयोग किया जाता है तो बहुत कुछ ऐसा नहीं है जो हम कर सकते हैं, लेकिन एक फिक्स के साथ फिर से जारी करने के लिए। हालाँकि अगर हमने उच्च स्तर की कोशिश करने वाले ब्‍लॉक को उपयोग करने के लिए विधि स्‍तर पर

— मुखरता नहीं जोड़ी है

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

— पीटरट