क्या कीड़े आपकी गति को नष्ट कर रहे हैं?

प्रौद्योगिकी की दुनिया में सॉफ़्टवेयर बग एक सामान्य घटना है। यदि आपने कभी कोड की दस से अधिक पंक्तियाँ लिखी हैं, तो संभावना है कि आपने गलती से एक पंक्ति बना ली होगी।

अब, मैं चाहता हूं कि आप इस बारे में सोचें कि आखिरी बार आपको किसी ग्राहक या सहकर्मी से बग के बारे में संदेश कब प्राप्त हुआ था। यह कैसे खत्म हुआ? क्या बग इतना जरूरी था कि आपको जो करना था उसे रोकना पड़ा?

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

मेरे बारे मेँ

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

मैंने यह लेख बग के बारे में पारंपरिक सोच को चुनौती देने और "हमें इसे जल्द से जल्द ठीक करने की आवश्यकता है!" के लक्ष्य के साथ लिखा है। मानसिकता, प्रत्येक मुद्दे की वास्तविक लागत का पता लगाने की आवश्यकता पर सवाल उठाना।

100% बग-मुक्त सॉफ़्टवेयर। मिथक या हकीकत?

100% बग-मुक्त सॉफ़्टवेयर प्राप्त करने का लक्ष्य हमेशा एक मुश्किल रहा है। बग-रहित ऐप बनाने का विचार आदर्श लग सकता है, लेकिन क्या यह वास्तव में संभव है?

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

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

और, कोडबेस में किसी भी बदलाव के साथ, कुछ न कुछ तोड़ना हमेशा संभव होता है। (कई उपकरणों और कई ब्राउज़रों का समर्थन करने से बिल्कुल भी मदद नहीं मिलती है।)

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

यह बताता है कि क्यों इन उद्योगों में अधिकांश सॉफ्टवेयर दशकों पहले की प्रौद्योगिकियों में लिखे गए हैं और क्यों लोग अब इसे छूने से झिझकते हैं।

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

सभी बग समान नहीं बनाए गए हैं

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

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

इसी तरह, हम साइनअप पेज में एक बग का इलाज नहीं कर सकते हैं जो नए उपयोगकर्ताओं को हमारे नए राइड-शेयरिंग ऐप में शामिल होने से रोक रहा है, इसे प्रोफाइल फोटो अपडेट करने से संबंधित समस्या के समान नहीं माना जा सकता है।

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

"हमें इसे अभी ठीक करना होगा या ग्राहक छोड़ देगा"

मैंने देखा है कि हम अपने ग्राहकों को मिलने वाले बग के लिए "अतिरिक्त" तात्कालिकता की भावना जोड़ते हैं।

आप शायद ऐसी ही स्थिति में रहे होंगे जब आपके किसी बड़े ग्राहक को कोई छोटी सी समस्या हो रही हो, और आपकी पूरी टीम पर संदेशों की बाढ़ आ रही हो जैसे कि दुनिया में आग लग गई हो 🔥

जियोवन्नी ने शिकायत की कि वे पाठ को सही-संरेखित नहीं कर सकते 11 1 वे एक महत्वपूर्ण ग्राहक हैं। हमें अब बग ठीक करना होगा!”

- आपका बौस

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

कोई भी बुरा प्रभाव नहीं डालना चाहता या नकारात्मक प्रतिष्ठा नहीं चाहता, और वास्तव में यही बग का कारण हो सकता है।

किसी बग से जितने अधिक उपयोगकर्ता प्रभावित होंगे, उसे ठीक करना उतना ही महत्वपूर्ण (संभवतः) होगा

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

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

आमतौर पर, ये उपकरण त्रुटियों को इस आधार पर प्राथमिकता देते हैं कि वे कितनी बार होती हैं और कितने उपयोगकर्ता प्रभावित होते हैं।

मानव.प्रायोरिटाइज़बग्स()

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

उनका प्राथमिकता निर्धारण मानदंड कुछ इस तरह दिख सकता है:

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

इसका कितने ग्राहकों पर असर पड़ रहा है? बस एक ठो? सब लोग? क्या हम भी जानते हैं? जब बड़ी संख्या में उपयोगकर्ता प्रभावित होते हैं, तो आप समस्या का समाधान करना चाह सकते हैं, भले ही वह छोटी कार्यक्षमता से संबंधित हो।

इसे ठीक करने में कितना समय लगेगा? इसके बाद, "बग ट्राइएज" प्रक्रिया का मालिक पूछेगा कि समस्या को ठीक करने में कितना समय लगता है। यदि इसमें केवल कुछ घंटे लगते हैं, तो वे इसे इस सप्ताह के काम में लगाने के तरीके ढूंढ लेंगे।

"ठीक करने के लिए (यथाशीघ्र) या ठीक नहीं करने के लिए, यही सवाल है।"

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

इन परिदृश्यों में तीन महत्वपूर्ण समस्याएं हैं:

1. टीम गलत तरीके से प्राथमिकता देती है, जिसके परिणामस्वरूप संभवतः समय बर्बाद होता है और कम प्रासंगिक बग को ठीक किया जाता है।

   
   

2. गैर-महत्वपूर्ण बगों में अनावश्यक तात्कालिकता जोड़ने से टीम अनावश्यक रूप से फोकस बदल देती है।

   
   

3. किसी बग का समाधान करने से पहले, उसकी लागत पर विचार करना महत्वपूर्ण है। तो, वास्तव में एक बग से टीम को कितना नुकसान हो रहा है? क्या इसे ठीक करना उचित लागत है?

किसी बग को ठीक करना कितना महंगा है?

क्या आपने कभी यह मुहावरा सुना है "मुफ़्त दोपहर के भोजन जैसी कोई चीज़ नहीं होती?"

जब हम लागत के बारे में बात करते हैं, तो पहली चीज़ जो हम डेवलपर के रूप में सोचते हैं वह है बुनियादी ढांचे की लागत, एक सर्वर की लागत, एक लैम्ब्डा फ़ंक्शन, एक मोंगोडीबी क्लस्टर, इत्यादि। हालाँकि, जब बग की बात आती है, तो मैं मानव-संबंधी लागत के बारे में बात कर रहा हूँ: ध्यान ।

प्रसंग स्विचिंग

यदि आपने कंप्यूटर इंजीनियरिंग का अध्ययन किया है या आपने कभी पढ़ा है कि ओएस कैसे काम करता है, तो आपने संभवतः संदर्भ स्विचिंग के बारे में सुना होगा।

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

( [विकिपीडिया] से (https://Context स्विच https://en.wikipedia.org › wiki › Context_switch))

ओएस-संदर्भ स्विचिंग का एक मामला मल्टीटास्किंग हो सकता है: संदर्भ स्विचिंग मल्टीटास्किंग की विशेषता है जो प्रक्रिया को सीपीयू से स्विच करने की अनुमति देता है ताकि दूसरी प्रक्रिया को चलाया जा सके।

मैंने ये शब्द पहले कहाँ सुने हैं 🤔? - आह हाँ:

"मैं मल्टीटास्किंग में मास्टर हूं।"

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

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

मनोवैज्ञानिकों ने इसकी लागत निर्धारित करने के लिए कार्य-स्विचिंग पर कई प्रयोग किए हैं । उन्होंने लोगों द्वारा कार्यों को पूरा करने में लगने वाले समय और उनके बीच स्विच करने में लगने वाले समय को मापा। परिणाम निम्नलिखित थे:

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

"क्या आपके पास एक मिनट का समय है?"

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

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

या हो सकता है कि आपको अभी-अभी अपने सहकर्मी से एक स्लैक संदेश प्राप्त हुआ हो जिसमें पूछा गया हो कि क्या आपके पास किसी विशिष्ट मुद्दे पर मदद करने के लिए एक मिनट का समय है।

क्या दूसरी स्थिति पहली की तुलना में अधिक स्वीकार्य है?

खैर, अंत में, इससे कोई फर्क नहीं पड़ता। एक्लिप्स और विज़ुअल स्टूडियो का उपयोग करके 86 प्रोग्रामर से रिकॉर्ड किए गए 10,000 प्रोग्रामिंग सत्रों के विश्लेषण और 414 प्रोग्रामर के सर्वेक्षण के आधार पर ( पार्निन:10 ) पाया गया:

• एक प्रोग्रामर को रुकावट के बाद काम फिर से शुरू करने के बाद अधिक कोड लिखने में 10-15 मिनट का समय लगता है।

• किसी विधि के संपादन के दौरान बाधित होने पर, केवल 10% बार प्रोग्रामर ने एक मिनट से भी कम समय में काम फिर से शुरू किया।

• एक प्रोग्रामर को एक दिन में केवल एक निर्बाध 2 घंटे का सत्र मिलने की संभावना है।

जब बेकार बैठकों की बात आती है तो डेवलपर्स संदर्भ-परिवर्तन से बचते हैं ( और नफरत करते हैं )। फिर भी, मेरा मानना है कि जब हम "डेवलपर कार्यों" के बीच संदर्भ-स्विच करते हैं और इसके नकारात्मक प्रभाव को पूरी तरह से अनदेखा करते हैं तो हम किसी तरह अंधे हो सकते हैं।

अंतिम विचार

वास्तविक दुनिया में, हम हमेशा सीमित संसाधनों से निपट रहे हैं, चाहे वह पैसा हो, समय हो या ध्यान हो ।

बग ठीक करने की एक कीमत होती है।

"नहीं" एक चीज़ के लिए नहीं है। "हाँ" बहुत सी चीज़ों के लिए नहीं है। - जेसन फ्राइड

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

संदर्भ स्विचिंग की छिपी हुई लागतों को समझने से आपको बेहतर विकल्प चुनने में मदद मिलती है कि कौन से बग के लिए सबकुछ छोड़ना उचित है और कौन से नहीं (अधिकांश नहीं हैं)।

क्या हमें कीड़ों की परवाह करना बंद कर देना चाहिए?

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

दुर्भाग्य से, वे परेशान करने वाले कीड़े अक्सर रास्ते में आ जाते हैं।

जैसा कि टॉम डी मार्को ने अपनी पुस्तक "पीपलवेयर" में लिखा है, यह समझा सकता है कि गुणवत्ता की परवाह करना बंद करना कठिन क्यों है:

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

– पीपलवेयर

क्या हमें बग रोकथाम में और अधिक प्रयास करना चाहिए?

जैसा कि मैंने पहले बताया, कई उद्योगों में आपके पास कोई विकल्प नहीं है। वहां, आपको गलतियों को होने से रोकने और उन्हें यथाशीघ्र सुधारने के लिए सभी आवश्यक कदम उठाने चाहिए।

लेकिन, अधिकांश ऐप्स के लिए, क्या अतिरिक्त प्रयास इसके लायक है?

PS आख़िरकार, भले ही हमारे पास एक जादू की छड़ी हो जो सभी बग्स को ठीक कर दे, फिर भी हमारे उपयोगकर्ता हमारे ऐप का दुरुपयोग करने का एक तरीका ढूंढ लेंगे 😅