🤳 🤱🏿 👨‍⚖️ जानवर को छेड़ना: विरासत कोड, परीक्षण और आप ⬜️ 👸 🕹️

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

इसके बाद श्रृंखला "रिक और मोर्टी" से शॉट्स। लेखक जस्टिन रॉयलैंड और डैन हार्मन।

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

किरिल बोरिसोव उद्योग में 12 साल, वर्षों में वह बैसाखी, टूटे हुए कोड और पुराने सिस्टम के घूर्णन फ्रेम में एक लंबा सफर तय कर चुके हैं: अखंड लेखा प्रणाली से प्राधिकरण microservices तक। यात्रा ने उन्हें अनुभव और कहानियों से सम्मानित किया जो वह मूल्यवान सलाह के रूप में साझा करेंगे।

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

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

यहाँ क्या नहीं होगा:

परीक्षण लिखने के लिए युक्तियाँ। कई किताबें, लेख और विभिन्न वीडियो इस सवाल को कवर करते हैं।
चर्चा के तरीके। BDD, TDD, ATDD - सभी अपने विवेक पर।
वह सब जो एनडीए का उल्लंघन हो सकता है। लोगों के पास एक लंबी मेमोरी है, और वकीलों के पास लंबे हथियार हैं।

विरासत कोड क्या है

इसकी कई परिभाषाएँ हैं। मेरा मानना है कि यह एक " काफी पुराना " कोड है जो 2 महीने से लेकर 10 साल पुराना है। विरासत कोड भ्रामक और नाजुक है, लेकिन एक विशालकाय सांप की तरह इसकी पूंछ को तोड़ता है।

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

क्या इस जानवर को दूर करना संभव है? हां, लेकिन तैयारी की जरूरत है।

प्रशिक्षण

जानवर से लड़ना उतना महत्वपूर्ण नहीं है जितना प्रारंभिक चरण। यह स्वयं के लिए तीन प्रश्नों से शुरू होता है।

"मैं यह क्यों कर रहा हूँ?" गंभीरता से, क्यों? आखिरकार, केवल दो विकल्प हैं।

, , , .
, .

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

"क्या मुझे पता है कि मैं क्या कर रहा हूँ?" यदि आपने परीक्षण लिखा है, तो आप जानते हैं। यदि नहीं, तो इससे पहले कि आप राक्षस पर सवार हों, मूल बातें मास्टर करें: 3-4 परीक्षण लिखें, कोड का एक छोटा सा हिस्सा कवर करें, अपना हाथ भरें और शक्ति महसूस करें।

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

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

सैनिक परीक्षण

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

एक निर्भरता आरेख बनाएं । कोई भी परियोजना शून्य में नहीं रहती। डेटाबेस, बाहरी सेवाओं, पुस्तकालयों - यह सब परियोजना में इस्तेमाल किया जा सकता है।

तुम्हें क्या हो गया है? आप जानवर से लड़ने वाले पहले व्यक्ति नहीं हो सकते हैं। "पूर्वजों" की प्रथाओं की जांच करें जो परियोजना को जला दिया और छोड़ दिया।

टोही के बाद, हम शत्रुता की ओर बढ़ते हैं।

संगठन से लड़ो

पहला राउंड आपके संगठन के साथ एक लड़ाई है। इसमें मुख्य बात आपके प्रबंधक, प्रत्यक्ष मालिक हैं।

प्रबंधक । वह उतना डरावना नहीं है जितना वह दिखता है। यह सामान्य जरूरतों वाला एक सामान्य व्यक्ति है: समय पर और अनावश्यक समस्याओं के बिना परियोजना को वितरित करने के लिए, इसके लिए धन और बोनस प्राप्त करें और चालू रहें।

नेता आपके उपक्रमों के खिलाफ नहीं है। वह चिल्लाते हुए इस परियोजना के लिए आप के खिलाफ है: "टेस्ट! टेस्ट! टेस्ट! ” यदि आप ऐसा करते हैं, तो वह आपको उस व्यक्ति के रूप में देखेगा जो अपना समय व्यतीत करता है और बाकी को धीमा कर देता है।

फायदा दिखाओ। प्रबंधक अच्छे, समय और पैसे की भाषा बोलता है। समझें कि वे समय पर परियोजना को बंद करने और कम संसाधनों के लिए अधिक परिणाम प्राप्त करने की इच्छा से प्रेरित हैं।

परीक्षण इस तरह प्रस्तुत नहीं किया जाना चाहिए:

- ओह, यह अच्छा होगा!

हमारे विचारों को निम्नानुसार प्रचारित किया जाना चाहिए:

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

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

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

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

जब हम प्रबंधक से सहमत होते हैं, तो हम उन लोगों की ओर मुड़ते हैं, जिनके साथ हमें हर दिन काम करना होता है।

साथियों

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

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

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

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

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

फूट डालो और शासन करो। दोपहर के भोजन पर या कोने में अपने किसी सहकर्मी के पास जाएं और कहें: “पूरी टीम पहले ही साइन अप कर चुकी है, आप इस प्रक्रिया को धीमा कर रहे हैं। शायद हम एक आम भाषा पा सकते हैं? ”

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

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

कार से लड़ो

यह कोड की चाल है जिसे उत्पाद कहा जाता है। आइए मूल बातों से शुरू करें।

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

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

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

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

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

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

लिंक बदलने से डरो मत। आपको अपनी आस्तीन ऊपर रोल करनी होगी और इस गंदगी में गहरी गोता लगाना होगा: लिंक हटाएं और बदलें, डेटाबेस की संरचना को बदलें। आप सिस्टम में सुधार करने आए थे, इसलिए बदलाव करने से न डरें।

हम परीक्षा पास करते हैं। पुराने उत्पादों को भ्रमित करने के लिए, एक अच्छी रणनीति धूम्रपान परीक्षण है।

धुआँ परीक्षण

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

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

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

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

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

समारोह परीक्षण

ये व्यक्तिगत कक्षाओं या किसी पद्धति का परीक्षण नहीं हैं, बल्कि कार्यात्मक के एक निश्चित भाग के परीक्षण का उच्चतम संभव स्तर हैं।

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

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

क्रियात्मक परीक्षण एक साधन हैं, अंत नहीं।

कार्यात्मक परीक्षण सुई पर हुक करना आसान है: "मैं वास्तविक कार्यक्षमता का परीक्षण कर रहा हूं! यह उपयोगकर्ताओं का सामना कर रहा है। ”

एक कार्यात्मक परीक्षण में बड़ी मात्रा में कोड शामिल होते हैं जो विशाल मात्रा में डेटा के साथ बातचीत कर सकते हैं। इसलिए, 3-4 कार्यात्मक परीक्षण अच्छे हैं, 10 बदतर हैं, और 9 घंटे लेने वाले हजारों परीक्षण बहुत अधिक हैं। दुर्भाग्य से, यह भी होता है।

कार्यात्मक परीक्षणों के बाद, यूनिट परीक्षण करें। लेकिन मैं उनके बारे में बात नहीं करूंगा - आप पहले से ही सब कुछ जानते हैं।

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

अपने से लड़ना

इस तथ्य के लिए तैयार रहें कि मार्ग अंतहीन प्रतीत होगा । आपकी योजना में एक सप्ताह के लिए काम परियोजना को पूरा करने की संभावनाओं के बिना छह महीने लगेंगे।

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

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

यह सामान्य है, यह जीवन और कैरियर का अंत नहीं है। यह भी पुष्टि नहीं है कि आप एक खराब पेशेवर हैं। यहां एकमात्र निष्कर्ष यह है कि यह विशेष परियोजना विफल रही।

लेकिन तब आपके पास अनुभव और ज्ञान होता है। अगली बार, जब आप अपने हाथ में एक नया भाला लेते हैं और आपका घोड़ा दूसरे पवनचक्की की ओर बढ़ता है, तो आप इस भाले को भी तोड़ने के लिए तैयार होंगे, लेकिन बाद में, एक अलग तरीके से और कम नुकसान के साथ।

अब आक्रामक, कड़वा और शाश्वत।

बिदाई शब्द

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

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

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

"बस" संख्या मजाक नहीं है। आप हमेशा इस परियोजना को अपने ऊपर नहीं खींच सकते। हर कोई बाहर जल सकता है, छुट्टी पर जा सकता है या छोड़ सकता है। इसलिए, अपने सहकर्मियों को अपने ज्ञान और जिम्मेदारी पर पास करें, जो आपके बिना सामना करने के लिए आवश्यक है। जब आप समुद्र तट पर आराम करते हैं, तो यह अप्रिय कॉल से बचने में मदद करेगा, और CI फिर से लाल है।

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

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

मैं नहीं चाहता कि तुम यह व्यक्ति बनो। एक सीमित कारक में मत बदलो।

दस्तावेज लिखें।
प्रशिक्षण आयोजित करें।
अपना अनुभव साझा करें।

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

27 Moscow Python Conf++ Python 2 Python 3 — 2020 .

, (fb, vk, twitter) telegram- . !

जानवर को छेड़ना: विरासत कोड, परीक्षण और आप