GitHub Copilot से जेनरेट किए गए कोड के बग की वजह पकड़ना मुश्किल क्यों है
इनलाइन कम्प्लीशन का रिस्क प्रोफ़ाइल उस एजेंट से अलग होता है जो पूरी फ़ाइलें दोबारा लिखता है। हर सुझाव इतना छोटा होता है कि रिव्यू करने लायक लगता है, तो आप उसे एक सेकंड में देखकर आगे बढ़ जाते हैं। ध्यान का वह एक सेकंड आपके सामने वाली लाइन के लिए तो ईमानदार है, लेकिन उसके आसपास के सिस्टम के लिए अंधा है।
नतीजा यह होता है कि जब कुछ टूटता है, तो bisect करना तकलीफ़देह हो जाता है। कोई एक संदिग्ध कमिट नहीं होता, बस स्वीकार किए गए कम्प्लीशन की एक लंबी पूँछ होती है, जिनमें से हर एक उस वक़्त सही लगा था।
तीन ड्रिफ़्ट जिन पर नज़र रखनी चाहिए
कन्वेंशन ड्रिफ़्ट
कम्प्लीशन अपनी ट्रेनिंग और आसपास के कोड के पैटर्न पर चलते हैं, जो हमेशा आपके कोडबेस का असली कन्वेंशन नहीं होता।
एरर हैंडलिंग, null चेक और लॉगिंग अलग-अलग मॉड्यूल के बीच धीरे-धीरे एक-दूसरे से दूर होते चले जाते हैं।
डुप्लिकेट लॉजिक
मौजूदा हेल्पर ढूँढ़ने से तेज़ होता है जेनरेट किया हुआ हेल्पर स्वीकार कर लेना, इसलिए वही नियम तीन जगहों पर लागू हो जाता है।
बाद में उनमें से एक ठीक हो जाता है और बाकी दो नहीं।
सही लगने वाले डिफ़ॉल्ट
सुझाई गई कोई डिफ़ॉल्ट वैल्यू, टाइमआउट या सॉर्ट ऑर्डर वाजिब लगता है और आपके प्रोडक्ट के नियम से मेल नहीं खाता।
कुछ भी फेल नहीं होता। व्यवहार बस वह नहीं होता जो किसी ने चाहा था।
ये तीनों रिव्यू में अदृश्य रहते हैं और प्रोडक्ट के चलने पर दिखते हैं, और यही तय करता है कि जाँच की जगह कहाँ है।
व्यवहार की जाँच एक नियमित लय में करें, हर कम्प्लीशन पर नहीं
हर स्वीकार किए गए सुझाव को वेरिफाई करना न मुमकिन है, न उपयोगी। सही इकाई है pull request: तब तक बदलाव की एक पूरी-सी मात्रा जमा हो चुकी होती है, और फिर भी वह इतनी छोटी रहती है कि कुछ गलत हो तो उस पर सोचा जा सके।
आप जिसकी जाँच चाहते हैं वह नया कोड नहीं है, बल्कि वह व्यवहार है जिसके भीतर यह कोड बैठा है। जिस pull request ने इनवॉइस मॉड्यूल को छुआ हो, उसे इनवॉइसिंग को एंड-टू-एंड चलाकर देखना चाहिए — उन रास्तों समेत जिनके बारे में लिखने वाले ने सोचा ही नहीं, क्योंकि ठीक वहीं कोई सही लगने वाला डिफ़ॉल्ट छिपा होता है।
वेरिफिकेशन स्किल इंस्टॉल कर देने पर एजेंट यह काम खुद कर लेता है, किसी इंसान के याद रखने का इंतज़ार किए बिना।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
जो लोग लोकल इंस्टॉल नहीं चाहते, उनके लिए डैशबोर्ड भी यही सब कवर करता है, और पूरी कमांड सरफेस यहाँ मौजूद है — CLI रिपॉज़िटरी।
वह रिग्रेशन सवाल जो कोई भी काफ़ी पहले नहीं पूछता
कम्प्लीशन से भरे कोडबेस के बारे में काम का सवाल यह नहीं है कि "क्या यह कोड अच्छा है"। सवाल यह है कि "क्या प्रोडक्ट अब भी वही करता है जो पिछले महीने करता था"। ये दो अलग सवाल हैं और ड्रिफ़्ट सिर्फ़ दूसरा वाला पकड़ता है।
इसका जवाब देने के लिए ऐसी जाँचों का सेट चाहिए जो बदलाव से पहले से मौजूद हों, और यही वह हिस्सा है जिसे टीमें टालती हैं। पहले हफ़्ते में लिखे गए दस फ़्लो पहली घटना के बाद लिखे गए सौ फ़्लो से ज़्यादा कीमती हैं, क्योंकि सिर्फ़ वे पहले दस ही तब तय हुए थे जब किसी को पता नहीं था कि कौन-से मायने रखेंगे।
वह रिव्यू आदत जो स्केल करती है
हर कम्प्लीशन का रिव्यू करना मुमकिन नहीं है, और किसी का भी रिव्यू न करना वही तरीका है जिससे ड्रिफ़्ट जमा होती है। जो आदत काम करती है वह है लाइन के हिसाब से नहीं, कैटेगरी के हिसाब से रिव्यू करना।
जब कोई कम्प्लीशन कोई एरर पाथ जोड़े, तो जाँचें कि वह बाकी मॉड्यूल के एरर संभालने के तरीके से मेल खाता है या नहीं, क्योंकि यहाँ का फ़र्क सबसे आम ड्रिफ़्ट है और बाद में सुलझाने में सबसे झंझट वाला। जब वह कोई डिफ़ॉल्ट वैल्यू जोड़े, तो पूछें कि वह डिफ़ॉल्ट आया कहाँ से, क्योंकि सही लगने वाला डिफ़ॉल्ट व्यवहार बदलने का सबसे चुपचाप तरीका है। जब वह कोई हेल्पर जोड़े, तो दस सेकंड लगाकर देख लें कि पहले से कोई मौजूद तो नहीं, क्योंकि डुप्लिकेट लॉजिक ही बाद के किसी फ़िक्स को अधूरा बनाता है।
इन तीनों जाँचों में कुछ ही सेकंड लगते हैं और जो कुछ जमा होता है, उसका ज़्यादातर हिस्सा ये पकड़ लेती हैं। बाकी सब कोड पढ़कर नहीं, प्रोडक्ट को चलाकर बेहतर पकड़ में आता है।
इसे ऑटोमैटिक बना दें
ड्रिफ़्ट धीरे-धीरे बनती है, इसलिए जाँच का उबाऊ हद तक नियमित होना ज़रूरी है। जो भी चीज़ किसी के याद रखने पर टिकी हो, वह ठीक उसी व्यस्त हफ़्ते में छूट जाएगी जब सबसे ज़्यादा कम्प्लीशन स्वीकार किए जाते हैं।
अगर पाइपलाइन किसी और टीम की है, तो GitHub App सबसे कम रुकावट वाला रास्ता है: यह एक webhook है, आपकी रिपॉज़िटरी में कुछ नहीं बदलता, और तब चलता है जब आपका बिल्ड नए वर्ज़न के लाइव होने की रिपोर्ट करता है। अगर आप चाहते हैं कि जाँच रेपो में ही दिखे, तो यह काम एक GitHub Actions स्टेप कर देता है।
हर कम्प्लीशन पढ़े बिना ड्रिफ़्ट पकड़ना
हर स्वीकार किए गए सुझाव का रिव्यू करना मुमकिन नहीं है, इसलिए TestSprite इसके बजाय उस व्यवहार की जाँच करता है जिसके भीतर कोड बैठा है। कवरेज आपके प्रोडक्ट से जेनरेट होती है, हर pull request पर चलती है, और उसी सवाल का जवाब देती है जो कम्प्लीशन से भरे कोडबेस के लिए मायने रखता है: क्या यह अब भी वही करता है जो पिछले महीने करता था।
इससे तीनों ड्रिफ़्ट सीधे पकड़ में आती हैं। सॉर्ट ऑर्डर बदल देने वाला कोई सही लगने वाला डिफ़ॉल्ट किसी फ़्लो के अलग व्यवहार के रूप में सामने आ जाता है। डुप्लिकेट लॉजिक तब दिखता है जब एक कॉपी ठीक हो जाती है और दूसरी नहीं। एरर हैंडलिंग में कन्वेंशन ड्रिफ़्ट ऐसे पाथ के रूप में दिखती है जो अब चुपचाप फेल हो जाता है।
यह वहीं चलता है जहाँ बदलाव है — pull request पर कमेंट के रूप में या कमिट चेक के रूप में — ताकि कोई रिग्रेशन कम्प्लीशन के एक बैच की तरफ़ इशारा करे, न कि एक तिमाही भर के कम्प्लीशन की तरफ़।
क्या Copilot से जेनरेट किया गया कोड हाथ से लिखे कोड से खराब होता है?
ज़्यादातर मामलों में प्रति लाइन के हिसाब से नहीं। जोखिम मात्रा का है: रिपॉज़िटरी में हर घंटे उससे ज़्यादा कोड आता है जितने के लिए रिव्यू प्रोसेस बनाई गई थी, इसलिए वही डिफ़ेक्ट रेट ज़्यादा चूक पैदा करता है।
क्या सख़्त रिव्यू इसे ठीक कर देगा?
कुछ हद तक, और यह उसी वजह से टकराता है जिसके लिए लोग कम्प्लीशन इस्तेमाल करते हैं। जाँच को पढ़ने से हटाकर व्यवहार की वेरिफिकेशन पर ले जाने से रफ़्तार भी बनी रहती है और सेफ़्टी नेट भी वापस आ जाता है।
Copilot जो टेस्ट लिखता है, उनका क्या?
कवरेज के लिए उपयोगी, स्वतंत्र जाँच के तौर पर कमज़ोर। जिन्हीं मान्यताओं से कोड बना है, उन्हीं से बना टेस्ट बनावट के हिसाब से कोड से सहमत ही रहेगा।
पहले कितने फ़्लो कवर करने चाहिए?
उन गिने-चुने फ़्लो से शुरू करें जो आप किसी ग्राहक को डेमो में दिखाएँगे, साथ में हर वह पाथ जो पैसे या परमिशन से जुड़ा हो। किसी कवरेज टारगेट से नहीं, घटनाओं से आगे बढ़ाएँ।
क्या इसके लिए रिपॉज़िटरी का एक्सेस चाहिए?
वेरिफिकेशन डिप्लॉय किए गए एप्लिकेशन पर उसके इंटरफ़ेस के ज़रिए चलती है। रिपॉज़िटरी एक्सेस का इस्तेमाल सिर्फ़ pull request और कमिट पर नतीजे वापस पोस्ट करने के लिए होता है।
बग सुझाव में नहीं, ड्रिफ़्ट में है।
GitHub Copilot से जेनरेट किए गए कोड के बग कई छोटे-छोटे स्वीकार किए गए कम्प्लीशन में जमा होते हैं। हर सुझाव के बजाय हर pull request पर व्यवहार जाँचें, फ़्लो ज़रूरत पड़ने से पहले तय कर लें, और जाँच को अपने आप चलती रहने दें।