From Generic to Personalized: Exploring Persona-Aware Code Review Explanations
यह शोधपत्र एक मिश्रित-पद्धति वाले उपयोगकर्ता अध्ययन से प्रारंभिक निष्कर्ष प्रस्तुत करके व्यक्तिगत कोड समीक्षा स्पष्टीकरणों की क्षमता की जांच करता है जो यह प्रकट करता है कि डेवलपर्स की फीडबैक शैलियों के प्रति प्राथमिकताएं उनके समस्या-समाधान दृष्टिकोणों, अनुभव और भूमिकाओं के आधार पर भिन्न होती हैं, जो अंततः उन मानव-केंद्रित एआई प्रणालियों का समर्थन करती है जो व्यक्तिगत आवश्यकताओं के अनुसार समीक्षा टिप्पणियों को अनुकूलित करती हैं।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक शेफ हैं जो नए रसोइयों को एक बिगड़ी हुई रेसिपी ठीक करना सिखाने की कोशिश कर रहे हैं। आप अपने किचन में दो बहुत अलग प्रकार के छात्रों के समूह को देख रहे हैं। एक छात्र है, जिसे हम "टिम" कह सकते हैं, जो एक आत्मविश्वासी, साहसी खोजकर्ता है जिसे सीधे आग में कूदना, नए मसालों के साथ प्रयोग करना और करके चीजों को समझना पसंद है। दूसरा छात्र है, "एबी", जो एक सावधान, प्रक्रिया-उन्मुख योजनाकार है जो तब तक अधिक सुरक्षित महसूस करती है जब तक कि आप उसे एक चरण-दर-चरण मानचित्र न दे दें, विस्तार से न समझा दें कि एक कदम क्यों महत्वपूर्ण है, और इससे पहले कि वह किसी पैन को छुए, उसे चेतावनी न दे दें कि गर्म चूल्हा कहाँ है।
वर्षों से, कोड रिव्यू (जहाँ डेवलपर्स एक-दूसरे के कंप्यूटर कोड की गलतियों की जाँच करते हैं) एक ही सामान्य निर्देश सबको देने जैसा रहा है: "इसे ठीक करो!" या "इसे छोटा करो!" यह लेख सुझाव देता है कि यह "एक ही आकार सबके लिए" (one-size-fits-all) वाला दृष्टिकोण वैसा ही है जैसे टिम और एबी को सिखाने के लिए एक ही रेसिपी कार्ड का उपयोग करना। यह अक्सर भ्रम, हताशा और कोड के बार-बार होने वाले विवादों के चक्र में फंसने का कारण बनता है बजाय इसके कि उसे ठीक किया जाए।
इन शोधकर्ताओं ने एक सरल प्रश्न पूछा: क्या होगा अगर हम जादुई रूप से फीडबैक को छात्र की शैली के अनुरूप फिर से लिख सकें? वे देखना चाहते थे कि क्या एक "टिम-शैली" का कमेंट (छोटा, कार्रवाई से भरपूर, स्वतंत्रता को प्रोत्साहित करने वाला) टिम के लिए बेहतर काम करेगा, और क्या एक "एबी-शैली" का कमेंट (विस्तृत, जोखिम-जागरूक, चरण-दर-चरण) एबी के लिए बेहतर काम करेगा।
इसकी परीक्षा करने के लिए, उन्होंने केवल अनुमान नहीं लगाया; उन्होंने एक छोटा, वास्तविक दुनिया का प्रयोग चलाया। उन्होंने 16 डेवलपर्स को इकट्ठा किया (छात्रों और पेशेवरों का मिश्रण, और कोड लिखने वाले और कोड रिव्यू करने वाले लोगों का मिश्रण)। उन्होंने इन डेवलपर्स को तीन अलग-अलग कोड दिखाए और उनसे प्रत्येक के लिए फीडबैक के दो संस्करण देखने के लिए कहा: एक जो "टिम" के लिए लिखा गया लगता था और एक जो "एबी" के लिए लिखा गया लगता था।
यहाँ अध्ययन द्वारा दिए गए सुझाव हैं, उनके मापन के आधार पर:
- "एबी" वाले समूह को मानचित्र पसंद आए: जब उन डेवलपर्स ने, जो खुद को "एबी" शैली के रूप में पहचानते थे (विशेष रूप से कम अनुभवी), विस्तृत, चरण-दर-चरण स्पष्टीकरण देखे जो जोखिमों और सीखने के अवसरों को उजागर करते थे, तो उन्होंने बहुत अधिक समर्थित महसूस किया। वे संक्षिप्त और प्रभावशाली फीडबैक नहीं चाहते थे; वे "क्यों" और "कैसे" जानना चाहते थे।
- "टिम" वाला समूह अधिक चयनात्मक था: "टिम" डेवलपर्स, जो आमतौर पर अधिक आत्मविश्वासी होते हैं, हमेशा उतनी उम्मीद के मुताबिक "टिम-शैली" के फीडबैक को पसंद नहीं करते थे जितनी कि अपेक्षित थी। वास्तव में, कम अनुभवी "टिम" प्रकार के लोग संक्षिप्त, केवल कार्रवाई वाले नोट्स के साथ संघर्ष करते थे क्योंकि उनमें अंतराल को भरने के लिए अनुभव की कमी थी। हालाँकि, विशेषज्ञ "टिम" डेवलपर्स ने विस्तृत शैली की तुलना में संक्षिप्त, प्रत्यक्ष शैली को अधिक सराहा।
- अधिकांश लोग गति के बजाय गहराई चाहते थे, लेकिन प्राथमिकताएं भिन्न थीं: डेटा में एक प्रमुख निष्कर्ष यहाँ है: जबकि डेवलपर्स ने संक्षिप्त होने के बजाय "सीखने के समर्थन", "व्यावहारिक सुझावओं" और "जोखिम जागरूकता" को अधिक महत्व दिया, लेकिन यह सभी के लिए सार्वभौमिक नियम नहीं था। "एबी" प्रतिभागियों ने संक्षिप्त कमेंट्स को दृढ़ता से नापसंद किया, लेकिन "टिम" प्रतिभागियों के संक्षिप्तता पर मिश्रित विचार थे; कुछ ने इसे स्वीकार्य पाया या पसंद किया, जबकि अन्य अनिश्चित थे। ऐसा लगता है कि कोड की दुनिया में, संक्षिप्त होने से अधिक महत्वपूर्ण स्पष्ट और सहायक होना है, लेकिन संक्षिप्तता की सराहना कितनी की जाएगी, यह इस पर निर्भर करता है कि आप कौन हैं।
यह पेपर इस विचार को खारिज करने का दावा नहीं करता है कि क्या कभी एक ही प्रकार का स्पष्टीकरण काम कर सकता है, बल्कि यह प्रस्तुत करता है कि एक एकल प्रकार का दृष्टिकोण सभी के लिए पूर्ण नहीं होने की संभावना है। अध्ययन स्पष्ट रूप से दिखाता है कि जो एक व्यक्ति के लिए स्पष्ट है, वह दूसरे के लिए भ्रमित करने वाला हो सकता है, जो यह सुझाव देता है कि एक "एक ही आकार सबके लिए" वाला दृष्टिकोण विविध टीमों के लिए अपर्याप्त है।
तो, मुख्य निष्कर्ष क्या है? शोधकर्ता सुझाव देते हैं कि हम कोड रिव्यू के लिए एक नए प्रकार के "स्मार्ट असिस्टेंट" बनाने की दहलीज पर हैं। कल्पना कीजिए कि एक AI है जो न केवल आपके कोड में त्रुटियों की जाँच करता है बल्कि यह भी जाँचता है कि आप कौन हैं। यदि आप एक सावधान योजनाकार हैं, तो यह आपको एक विस्तृत मार्गदर्शिका देता है। यदि आप एक साहसी खोजकर्ता हैं, तो यह आपको सही दिशा में एक हल्का सा धक्का देता है।
हालाँकि, लेखक सावधानी से कहते हैं कि यह अभी तो बस शुरुआत है। उन्होंने इन प्राथमिकताओं को 16 लोगों के एक छोटे समूह में मापा है, और हालांकि परिणाम आशाजनक हैं, यह अभी कोई अंतिम उत्पाद नहीं है। वे चेतावनी देते हैं कि हमें चीजों को बहुत सरल बनाने या दृष्टिकोणों की विविधता को खोने में सावधानी बरतनी चाहिए। लक्ष्य मानवीय निर्णय को बदलना नहीं है, बल्कि ऐसे उपकरण बनाना है जो मनुष्यों को एक-दूसरे को बेहतर ढंग से समझने में मदद करें, यह सुनिश्चित करते हुए कि कोई भी डेवलपर इसलिए पीछे न छूट जाए क्योंकि फीडबैक उस भाषा में लिखा गया था जिसे वह नहीं बोल पाता।
संक्षेप में, अध्ययन सुझाव देता है कि कोड रिव्यू का भविष्य तेज़ होने के बारे में नहीं है; यह अधिक व्यक्तिगत, अधिक सहानुभूतिपूर्ण और थोड़ा अधिक उस शिक्षक की तरह होने के बारे में है जो जानता है कि उसका छात्र सबसे अच्छा कैसे सीखता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।