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