कई सॉफ्टवेयर डेवलपर अपने ग्राहकों के डेटा का विश्लेषण करने के लिए डेटा साइंस सीख रहे हैं। बढ़ती संख्या में लोग यह समझ रहे हैं कि वे उन्हीं तकनीकों का उपयोग अपने ही सवालों के जवाब देने के लिए कर सकते हैं, जैसे:
- यह प्रोजेक्ट कब तक शिप करने के लिए तैयार होगा?
- हमारे एप्लिकेशन के कौन से घटकों की सबसे ज्यादा टेस्टिंग की जरूरत है?
- यह बग किसे ठीक करना चाहिए?
- मेरे API के किन हिस्सों का उपयोग लोगों को सबसे कठिन लगता है?
पिछले 15 वर्षों में, सॉफ्टवेयर इंजीनियरिंग में इन प्रश्नों की पड़ताल के लिए अनुभवजन्य शोध में तेज़ी आई है, आंशिक रूप से GitHub और Stack Overflow जैसी साइटों से डेटा की उपलब्धता के कारण। यह ब्लॉग पोस्ट कुछ प्रतिनिधि परिणाम प्रस्तुत करता है, फिर तीन के पीछे की विधियों का विस्तार से अन्वेषण करता है।
यदि आप यह जानना चाहते हैं कि अपने प्रोजेक्ट्स में ऐसे इनसाइट्स पाने के लिए डेटा साइंस का उपयोग कैसे करें, तो कृपया मुझे बताएं।
डेटा साइंस और सॉफ्टवेयर इंजीनियरिंग: उदाहरण
आइए एक ऐसे निष्कर्ष से शुरुआत करें जो बड़े पैमाने पर डेटा साइंस करने वाले सभी लोगों को प्रभावित करता है: वितरित डेटा-इंटेंसिव सिस्टम्स में अधिकांश गंभीर विफलताएँ साधारण टेस्टिंग से रोकी जा सकती हैं—Yuan इत्यादि की खोज। उन्होंने Cassandra, Hadoop MapReduce और समान प्रणालियों में विफलताओं की जाँच की और पाया कि:
- लगभग सभी विफलताओं को 3 या उससे कम कंप्यूट नोड्स पर पुन: उत्पन्न किया जा सकता था। यानी, आमतौर पर आपको क्लस्टर को डीबग करने के लिए क्लस्टर की आवश्यकता नहीं होती।
- एरर लॉग में आमतौर पर पुनरुत्पादन के लिए पर्याप्त डेटा होता था।
- विनाशकारी विफलताओं का अधिकांश भाग एरर हैंडलिंग कोड पर साधारण टेस्टिंग करके आसानी से रोका जा सकता था।
आखिरी बिंदु सबसे अप्रत्याशित है। पेशेवर आमतौर पर यह टेस्ट करते हैं कि जब सब कुछ ठीक चल रहा हो तो उनका विश्लेषण कोड काम करता है या नहीं, लेकिन वे शायद ही यह टेस्ट करते हैं कि समस्या आने पर वह सही काम करता है या नहीं। विकास के दौरान ऐसे कुछ टेस्ट जोड़ देने से आगे चलकर बहुत सी परेशानियाँ टल सकती हैं।
एक और बड़े पैमाने का परिणाम Altadmri और Brown के काम से आता है, जिन्होंने यूनाइटेड किंगडम में हाई स्कूल के छात्रों द्वारा कार्यक्रमों को कंपाइल करने के 3.7 करोड़ प्रयासों को देखा। फिर उन्होंने शिक्षकों से पूछा कि उनके छात्रों की सबसे आम गलतियाँ क्या हैं, और पाया कि:
- शिक्षक इस बात पर आपस में सहमत नहीं थे कि छात्र किस तरह की गलतियाँ सबसे ज्यादा करते हैं।
- और भी महत्वपूर्ण, शिक्षकों की भविष्यवाणियाँ इस बात से केवल कमजोर रूप से सहसंबद्ध थीं कि छात्र वास्तव में कहाँ गलत हो रहे थे।
बेशक, प्रोग्रामिंग में उपयोगी साक्ष्य-आधारित इनसाइट्स पैदा करने का एकमात्र तरीका डेटा माइनिंग नहीं है। 2013 में, Andreas Stefik की टीम ने इस पर श्रृंखला की दूसरी स्टडी प्रकाशित की कि क्या कुछ भाषाएँ अन्य की तुलना में सीखने में आसान हैं। एक बेसलाइन के रूप में, उन्होंने अपने अध्ययन में एक मनगढ़ंत भाषा शामिल की थी जिसके कीवर्ड्स को यादृच्छिक रूप से जनरेट किया गया था।
उनके आश्चर्य के लिए, Java और Perl जैसी कर्ली-ब्रेस भाषाएँ शुरुआती लोगों के लिए एक यादृच्छिक रूप से जनरेट की गई भाषा जितनी ही कठिन थीं। Python और Ruby दोनों सीखने में काफी आसान थीं, और Quorum, जो हर नए फीचर के सिंटैक्स को जोड़ने से पहले A/B टेस्ट करता है, उससे भी आसान निकली। Andreas इस परिणाम और इस बात के कारणों पर कि प्रोग्रामिंग भाषा डिज़ाइनर उपयोगिता पर इतना कम ध्यान क्यों देते हैं, इस रोचक पॉडकास्ट में चर्चा करते हैं।
सुरक्षा बग रिपोर्ट की पहचान
यह स्टडीज़ कैसे की जाती हैं, इसका एक उदाहरण यह है कि Fayola Peters ने LERO में बड़े सिस्टम्स के बग ट्रैकर्स में सुरक्षा बग की रिपोर्ट्स खोजने के लिए टेक्स्ट-आधारित प्रिडिक्शन मॉडल्स का उपयोग किया ताकि उन पर काम को प्राथमिकता दी जा सके। एक अध्ययन में, उन्होंने Chromium, Wicket, Ambari, Camel और Derby प्रोजेक्ट्स से डेटा का उपयोग किया; इनमें कुल 45,940 बग रिपोर्ट्स थीं, लेकिन इनमें से सिर्फ 0.8% सुरक्षा बग रिपोर्ट्स थीं।
कुछ सुरक्षा बग्स को मैन्युअली लेबल किया गया है, और इन्हें बिना लेबल वाले बग्स का पता लगाने के लिए क्लासिफायर प्रशिक्षित करने में उपयोग किया जा सकता है। Naïve Bayes और Random Forests जैसी तकनीकें शुरुआती बिंदु हैं, लेकिन विशेष कीवर्ड्स को फ़िल्टर करने से जनरल मॉडल्स की दक्षता में अक्सर सुधार किया जा सकता है। सबसे महत्वपूर्ण जाँच यह है कि लेबल किए गए सुरक्षा बग्स वाले प्रोजेक्ट्स पर बने मॉडल्स अन्य प्रोजेक्ट्स में समान बग्स को कितनी अच्छी तरह खोज सकते हैं। परिणाम उत्साहजनक थे: Peters ने पाया कि उनके क्लासिफायर व्यावहारिक उपयोग के लिए पर्याप्त रूप से अच्छे काम करते हैं।
क्या मेरा पैच स्वीकार किया जाएगा?
दूसरे उदाहरण के रूप में, कंपनियाँ चाहती हैं कि उनके संशोधन प्रोजेक्ट्स में शामिल हों ताकि उन्हें खुद कोड मेंटेन न करना पड़े, और स्वयंसेवक भी यह संकेत चाहते हैं कि उनके पैच के स्वीकार होने की कितनी संभावना है। चूँकि पैच सबमिशन और स्वीकृति के बीच अक्सर लंबा समय होता है, Bram Adams और उनकी टीम Polytechnique Montréal में ऐसे मॉडल्स बना रही है जो यह भविष्यवाणी करें कि किन्हें स्वीकार किया जाएगा।
कई डेटा साइंस प्रोजेक्ट्स की तरह, यह भी कई स्रोतों—Git रिपॉज़िटरीज़ और Gerrit कोड रिव्यूज़ सहित—से डेटा लेने और साफ़ करने से शुरू होता है। हालाँकि, जिन प्रोजेक्ट्स में ईमेल-आधारित रिव्यू होता है, जैसे Linux कर्नेल, वहाँ डेटा एकत्र करना मेलिंग लिस्ट आर्काइव्स को स्क्रैप करने और पैच के चेकसम्स या बदली गई लाइनों के सेट-आधारित इंटरसेक्शन जैसी हीयूरिस्टिक्स का उपयोग कर पैच को वार्तालापों से मिलान करने का काम होता है। GrimoireLab जैसे टूल्स की मदद के बावजूद, हमेशा ऐसे पैच होंगे जिनके अनेक संस्करण रिव्यू हुए हों, और ऐसे पैच जो कई भागों में विभाजित होकर अलग-अलग रिव्यू हुए हों। हर डेटा साइंस की तरह, मॉडल बनाना विश्लेषक पर निर्भर है, और उसमें किए गए अनुमानों का अंतिम निष्कर्षों पर गहरा असर पड़ता है।
दूसरा कदम यह तय करना है कि किन परिवर्तनीयों को देखना है और प्रत्येक के लिए कौन-सा मैट्रिक उपयोग करना है, जैसे:
- पैच की गुणवत्ता
- पैच डेवलपर का अनुभव
- रिव्यू प्रक्रिया (उदाहरण के लिए, रिव्यू टिप्पणियाँ और समीक्षकों की संख्या)
- रिव्यू की गुणवत्ता (उदाहरण के लिए, रिव्यू का विस्तार स्तर)
- रिव्यू का समय
- पैच लेखक और समीक्षकों की परस्पर क्रिया (उदाहरण के लिए, सौम्य बनाम आक्रामक)
सिर्फ यह आधा दर्जन ही सर्वाइवल स्टैटिस्टिक्स से लेकर सेंटिमेंट एनालिसिस तक सब कुछ उपयोग कर सकते हैं। एक बार तय कर लेने के बाद कि क्या मापा जाएगा, आप वे डेटा साइंस टूल्स लागू कर सकते हैं जिन्हें DataCamp के कोर्स सिखाते हैं। चूँकि आपका वास्तविक लक्ष्य भविष्य के पैच की स्वीकृति का पूर्वानुमान लगाना है, सबसे सीधी पद्धति लॉजिस्टिक रिग्रेशन है, लेकिन और भी कई तरीके हैं।
अंत में, आप वेरिएबल इंपॉर्टेंस मापकर पैच स्वीकृति पर प्रत्येक परिवर्तनीय के प्रभाव का निर्धारण कर सकते हैं। यह आंशिक रूप से गुणात्मक होगा, क्योंकि आपका लक्ष्य यह पहचानना है कि डेवलपर्स क्या कर सकते हैं ताकि उनके काम के प्रॉडक्ट में शामिल होने की संभावना बढ़े। हमेशा की तरह, सहसंबंध और कारण-कार्य संबंध को गड़बड़ाने से सावधान रहना होगा, लेकिन कुछ सरल सिफारिशें (जैसे "अपने कमिट संदेशों में ALL CAPS का उपयोग न करें") भी वास्तविक फर्क ला सकती हैं।
मदद ढूँढ़ना
पिछले 20 वर्षों में प्रोग्रामरों के काम करने के तरीके में सबसे बड़ा बदलाव उनकी भाषाओं में नहीं, बल्कि सवाल पूछने और जवाब पाने के लिए लगभग सर्वव्यापी रूप से Stack Overflow पर निर्भरता रहा है। एडिलेड विश्वविद्यालय में Christoph Treude और उनके सहयोगी ऐसे तरीकों का विकास कर रहे हैं जो इस तरह की साइटों को और अधिक उपयोगी बनाएँ।
उनका शुरुआती बिंदु है Stack Overflow डेटा डंप। शब्दों और वाक्यों की संख्या, सबसे आम शब्द, टर्म फ्रीक्वेंसी–इनवर्स डॉक्यूमेंट फ्रीक्वेंसी (TF-IDF) इत्यादि पर कुछ खोजपरक आँकड़े करने के बाद, अगला कदम यह देखना है कि Stack Overflow थ्रेड्स में कौन-से शब्द उच्च वोट, उच्च स्वीकृति दर और उच्च व्यू काउंट के साथ सह-अस्तित्व में होते हैं।
चूँकि सॉफ्टवेयर दस्तावेज़ों में कई अपूर्ण वाक्य और कोड तत्व होते हैं, ऑफ-द-शेल्फ नैचुरल लैंग्वेज प्रोसेसिंग लाइब्रेरीज़ अक्सर चीज़ें गलत कर देती हैं। अंग्रेज़ी के अलावा अन्य भाषाओं में लिखे सॉफ्टवेयर दस्तावेज़ों को पार्स करना और भी कठिन है क्योंकि तकनीकी शब्दावली के लिए वे अभी भी प्रायः अंग्रेज़ी का उपयोग करते हैं। यानी, वे दो प्राकृतिक भाषाओं और कोड तत्वों का मिश्रण होते हैं। ऐसे मामलों को संभालने के लिए एड-हॉक हीयूरिस्टिक्स और अधिक उन्नत मॉडलिंग तकनीकों का सम्मिलित उपयोग करना पड़ता है।
इन टुकड़ों को जोड़कर ऐसा टूल बनाना संभव हो जाता है जो इनपुट के रूप में किसी Python मॉड्यूल का नाम ले और Stack Overflow थ्रेड्स से इस मॉड्यूल के बारे में सार्थक वाक्य उत्पन्न करे। इससे आगे बढ़ते हुए, Treude और उनके सहयोगियों ने शब्दों के बीच व्याकरणिक निर्भरताओं का उपयोग कर स्वतः ऐसे सॉफ्टवेयर दस्तावेज़ ढूँढ़े जो बताती हैं कि कोई कार्य कैसे करना है, और फिर स्वतः ऐसे कोड स्निपेट्स की पहचान की जो उस कार्य को पूरा कर सकें।
निष्कर्ष
अक्सर सॉफ्टवेयर विकास के बारे में व्यापक रूप से मानी जाने वाली सच्चाइयाँ साक्ष्य के बजाय ठोस राय और ऊँची आवाज़ों पर आधारित होती हैं। जैसा कि शुरुआत में बताया गया, यह बदल रहा है क्योंकि हर साल सैकड़ों उच्च-गुणवत्ता वाले अध्ययन सामने आ रहे हैं जो कुछ मान्यताओं का समर्थन करते हैं, जैसे "कोड रिव्यू वास्तव में बग ढूँढ़ने का सबसे अच्छा तरीका है", और कुछ अन्य को चुनौती देते हैं, जैसे "टेस्ट-ड्रिवन डेवलपमेंट उतना प्रभावी नहीं जितना कुछ लोग मानते हैं, और goto स्टेटमेंट वास्तव में हानिकारक नहीं हैं"।
"इंजीनियरिंग" को "उपयोगी चीज़ें बनाने के लिए वैज्ञानिक विधि का अनुप्रयोग" के रूप में परिभाषित किया गया है। यदि यह सही है, तो डेटा साइंस की बदौलत सॉफ्टवेयर विकास अंततः एक वास्तविक इंजीनियरिंग अनुशासन बनने की राह पर हो सकता है। यदि आप ऐसे कोर्स देखना चाहेंगे जो आपको दिखाएँ कि सॉफ्टवेयर विकास में डेटा साइंस कैसे लागू करें, तो कृपया हमें बताएं।
आगे की पढ़ाई
शोधकर्ता हर साल Mining Software Repositories जैसी कॉन्फ्रेंसों में इस क्षेत्र में दर्जनों नए निष्कर्ष प्रस्तुत करते हैं। इनमें से कुछ प्रोसिडिंग्स अब भी शैक्षणिक पेवॉल्स के पीछे बंद हैं, लेकिन अधिक से अधिक शोधकर्ता प्रीप्रिंट उपलब्ध करा रहे हैं।
सारांश की तलाश कर रहे लोगों के लिए, 2010 की किताब Making Software उस समय के सबसे दिलचस्प परिणामों का "ग्रेटेस्ट हिट्स" संग्रह थी। एक नई त्रयी—Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data, और Sharing Data and Models in Software Engineering—उन्हीं विषयों का अधिक व्यापक और अद्यतन कवरेज है, और अलग से, Derek Jones Empirical Software Engineering Using R शीर्षक से नई किताब पर काम कर रहे हैं।