आप इसे बाद में कभी ठीक नहीं करेंगे - अपनी टीम को क्विकसैंड से कैसे बाहर निकालें

कोई स्टार्टअप टेस्टर से शुरू नहीं होता है।

फिर 2 साल बाद, वह स्टार्टअप अपने सबसे बड़े ग्राहक के लिए तब तक कोई नई सुविधा जारी नहीं कर सकता जब तक कि वे एक बड़े धमाके के साथ पूरी चीज को फिर से नहीं लिखते। इसे बार-बार देखना दर्दनाक है।

हमारे सॉफ़्टवेयर की साफ-सफाई की गुणवत्ता बनाए रखने के लिए कुछ आसान चीज़ें हैं, ताकि आप इस स्थिति में न पड़ें।

सबसे पहले, अपने डर को गले लगाओ। इंजीनियर बहादुर लोग होते हैं, और हम आसानी से यह स्वीकार नहीं करेंगे कि हमें चिंताएँ हैं। लेकिन हमारे पास है, और जितनी जल्दी हम उन चिंताओं को स्वीकार करते हैं और साझा करते हैं, उतनी ही जल्दी हम उनका सामना करने के लिए तैयार होंगे।

आज हम सॉफ्टवेयर कैसे बनाते हैं

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

ठीक है, जब तक हम इंजीनियरिंग टीमों के रूप में खुद को तोड़-मरोड़ कर पेश करते रहेंगे, तब तक इसे ठीक से करने के लिए पर्याप्त समय नहीं होगा।

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

तो हम इस तरह से सॉफ्टवेयर बनाते हैं:

• तेज़ और गंदा

• जल्दी नहीं, फिर भी गंदा

• त्वरित और सुखद विकर्ण पथ का परीक्षण किया गया

• बाकी सब कुछ किनारे का मामला माना जाता है। (एज केस जैसी कोई चीज नहीं है।)

  
  

हम में से कुछ भी जल्दी या गंदे को ना कहने और सॉफ्टवेयर को तेज और स्थिर बनाने के लिए बहादुर हैं।

आपको अपने अनुमानों से जो कटौती करनी चाहिए वह दायरा है, गुणवत्ता नहीं।

आप उस घटक की गुणवत्ता के बारे में क्या जानते हैं जिस पर आप काम कर रहे हैं?

• आप जानते हैं कि यह नाजुक है, लेकिन आप इसे छूना नहीं चाहते क्योंकि यह बहुत नाजुक है।

• आपने इसे बहुत पहले किया है, आप इसे मुश्किल से छूते हैं, इसे काम करना चाहिए।

• आप नहीं जानते कि यह नाजुक है।

• कोई परीक्षण नहीं है और यह जांचने और उजागर करने वाला कोई नहीं है कि यह वास्तव में कितना नाजुक है।

  
  

क्या आप हर दिन इस गंदे सॉफ्टवेयर से निपट कर खुश हैं?

क्या आप हर दिन अपने काम की गुणवत्ता के साथ समझौता करके खुश हैं, यह जानते हुए कि यह अच्छा नहीं है? "हमारे पास सफाई करने का समय नहीं है" और अभी भी देर हो रही है क्योंकि यह गंदा है और आप संभवतः इसे साफ किए बिना आगे नहीं बढ़ सकते।

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

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

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

आप इसे बाद में कभी ठीक नहीं करेंगे

क्या आप वह फर्क करने को तैयार हैं?

फिर, यहाँ क्या करना है: अनुशासित हो जाओ। मुझे खेद है, लेकिन इसके आसपास कोई दूसरा रास्ता नहीं है। और यह हर स्तर पर होना चाहिए।

उच्च गुणवत्ता वाले बिल्डिंग कोड के लिए आपका पहला कदम क्या होना चाहिए?

लॉगिंग और अलर्टिंग लागू करें

लॉगिंग और अलर्ट करने के लिए बहुत सारे टूल हैं। यह पहली बात है। आपका सॉफ़्टवेयर क्रैश हो रहा है, और आप पूरी तरह अनजान हैं।

एक समाधान खोजें जो आपको अपवाद अलर्ट से आसानी से टिकट बनाने और उन्हें "ज्ञात" के रूप में चिह्नित करने या रिपोर्ट किए जाने के बाद उन्हें समूहित करने की अनुमति देता है।

अलर्ट देखने और रिपोर्ट करने के लिए एक टीम रूटीन बनाएं

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

बस "टिकट की रिपोर्ट करें" बटन या "ज्ञात के रूप में चिन्हित करें" बटन पर क्लिक करें। और अगर आपको कोई दिलचस्पी है, तो आप शायद एक या दो को ठीक कर लेंगे।

यहां सबसे बड़ा तर्क आता है - हम एक जोड़े को ठीक कर सकते हैं, लेकिन हम परीक्षण लिख रहे हैं कि किसी को पुष्टि करने की आवश्यकता है, हमें तैनात करने की आवश्यकता है, और यह टीम के लिए अधिक अनियोजित कार्य उत्पन्न करता है।

पीएम हम पर चिल्लाएंगे कि हम उच्च प्राथमिकता वाली वस्तुओं पर काम नहीं कर रहे हैं, लेकिन सोना चढ़ाने वाले छोटे अलर्ट हैं।

इसमें सभी "एम" भूमिकाओं वाली टीम इसके बारे में सहमत है।

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

बस इतना ही, बहुत आसान है।

लॉग और अलर्ट को एक-एक करके साफ करना शुरू करें

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

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

फिर से, यह कोई नई विशेषता नहीं है, और ऐसा लग सकता है कि यह आपकी महत्वपूर्ण प्राथमिकताओं से समय निकाल लेता है, लेकिन उन छिपे हुए मुद्दों के कारण आपकी महत्वपूर्ण प्राथमिकताओं में पहले ही देर हो चुकी है। आप पहले ही देर कर चुके हैं!

सभी खाली ट्राई-कैच स्टेटमेंट हटाएं और इसे क्रैश होने दें!

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

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

अभी यूनिट टेस्ट लिखना शुरू करें

वाकई। आप अभी कुछ कोड पर काम कर रहे हैं। फिर आपको यूनिट टेस्ट लिखने से कोई नहीं रोकता है।

ओह मैं समझा! इकाई परीक्षण के लिए कोई बुनियादी ढांचा तैयार नहीं है, है ना? चलो भी! वैसे भी आप उस सामान्य किस्म की सुविधा में देरी करने जा रहे हैं।

परीक्षण चलाने के लिए आपको यूनिट टेस्ट फ्रेमवर्क और आपके सीआई को सेट अप करने के लिए एक दिन से अधिक की आवश्यकता नहीं है। इसे कर ही डालो।

बग फिक्स के लिए टीडीडी शुरू करें

"हम नहीं जानते कि समस्या क्या है और हम इसे कैसे ठीक करने जा रहे हैं। हम उस कोड के लिए परीक्षण नहीं लिख सकते जो अभी मौजूद नहीं है।"

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

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

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

परीक्षण-संचालित विकास एक ऐसा परीक्षण लिख रहा है जो पुष्टि करता है कि आपने सही काम किया है, न कि यह कि आपने इसे सही किया है। यूनिट परीक्षण सत्यापित करते हैं कि आपने इसे सही किया है या नहीं।

एक कवरेज रोडमैप बनाएं

टेस्ट ऑटोमेशन और टेक डेट के समान दुखद नियति हैं - वे कभी शुरू नहीं होते हैं क्योंकि "हम कभी भी सब कुछ कवर नहीं कर सकते हैं, हम कभी भी सब कुछ साफ नहीं कर सकते हैं, यह बहुत अधिक ओवरहेड है। हमारे पास उसके लिए समय नहीं है।"

मेरी बात सुनो: आपको सब कुछ स्वचालित करने की ज़रूरत नहीं है!

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

आप देखें कि मैं इसके साथ कहां जा रहा हूं।

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

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

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

आखिर आप एक R&D टीम हैं, है ना?!

पूर्ण कवरेज का लक्ष्य न रखें - इसके बजाय कम जोखिम और उच्च आत्मविश्वास का लक्ष्य रखें

अपने अप-टू-डेट आर्किटेक्चर और इंफ्रास्ट्रक्चर को आरेखित करते समय, नोट्स या सर्कल जोड़ें, या सभी जगहों को बोल्ड या लाल रंग दें:

• आपके व्यवसाय और सॉफ़्टवेयर के लिए मिशन-महत्वपूर्ण

• रिफैक्टरिंग की सख्त जरूरत है, या आप हर समय उस अन्य मिशन-महत्वपूर्ण सुविधा को स्थगित करते रहेंगे।

• लगातार तोड़ना और उन्हें ठीक करने में आपका समय बर्बाद करना बहुत व्यर्थ है क्योंकि वे कुछ दिनों में फिर से टूट जाएंगे।

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

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

  
  

  • सफलता और विफलता के लिए सभी फ़ेच-डेटा API अनुरोधों को कवर करें ताकि आप जान सकें कि आप खराब अनुरोध नहीं भेजते हैं, और यदि यह विफल रहता है, तो यह विक्रेता के कारण विफल हो जाता है।

    
    

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

    
    

  • ट्रैफिक जाम की पहचान करें और तय करें कि आप उन्हें कैसे सुलझाएंगे।

    
    

  • इसे सही करने की योजना बनाएं। आपका त्वरित और गंदा कोड गंदे परीक्षणों से गंदा रहेगा।

मैंने जानबूझकर एक कवरेज मानचित्र का उपयोग किया है न कि परीक्षण पिरामिड का क्योंकि... इस स्तर पर, जब आपके पास मैन्युअल या स्वचालित कोई परीक्षण नहीं है, तो आप पिरामिड के लिए तैयार नहीं हैं।

कई टीमों की गलत धारणा है कि उन्हें पहले 96% यूनिट परीक्षण कवरेज हासिल करना है, और फिर एकीकरण परीक्षण और आगे बढ़ना है। आधुनिक इकाई परीक्षण कवरेज के साथ समस्या यह है कि हम विधियों और वर्गों का परीक्षण करते हैं, कार्यात्मकताओं का नहीं।

और भी टीमें यूआई स्वचालन के साथ शुरू होती हैं, जो समान रूप से गलत है।

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

इसलिए पिरामिड के ऊपर या नीचे से शुरू न करें, बल्कि एक जोखिम मानचित्र बनाएं।

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

या यह एक डेटा संग्रह सेवा है, और आपको एपीआई के प्रदर्शन पर ध्यान देने की आवश्यकता है, उदाहरण के लिए।

अपने सॉफ़्टवेयर हॉटस्पॉट्स का एक मानचित्र बनाएं, जिसके लिए भारी परीक्षण की आवश्यकता है।

फिर सोचें कि आप उस परीक्षण को कैसे स्वचालित कर सकते हैं।

आप क्विकसैंड में प्रगति नहीं कर सकते हैं और केवल आप ही वहां से खुद को खींच सकते हैं

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

यदि वे खुश नहीं हैं, तो आप अगली कंपनी में चले जाएँगे।

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

फिर भी, ऐसे इंजीनियर हैं जिन्हें रखने के लिए एक कंपनी सब कुछ करेगी। उनमें से एक बनने के लिए, आपको परिवर्तन लाने और लगातार यह साबित करने की आवश्यकता है कि व्यवसाय आप जैसे लोगों पर निर्भर करता है।

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

आप रेत में प्रगति नहीं कर सकते, और केवल आप ही अपने आप को बाहर खींच सकते हैं।