AI को पठनीयता, बग और सुरक्षा पर एक कड़ा रिव्यूअर बनाएँ, और उसकी टिप्पणियों के खिलाफ़ अपने फैसलों का बचाव करके अपनी परख को धार दें।
इस पाठ को Kodokon में खोलेंसाथी द्वारा किया गया कोड रिव्यू इस क्षेत्र में विकास के सबसे बेहतर तरीके से दर्ज त्वरकों में से एक है - और अकेले काम करते हुए इस तक पहुँच पाना सबसे कठिन में से एक। AI चौबीसों घंटे उपलब्ध एक रिव्यूअर देता है, बस एक शर्त पर: आपको उसे विन्यस्त करना होगा। डिफ़ॉल्ट रूप से, मॉडल अनुपालक होता है: वह आपकी मेहनत की तारीफ़ करता है, दो मामूली बातें उठाता है, और निष्कर्ष देता है कि "कुल मिलाकर, यह अच्छा काम है।" यह रिव्यू नहीं, यह पीठ थपथपाना है। इसका उल्टा और उतनी ही बड़ी गलती है "मेरा कोड साफ़-सुथरा दोबारा लिखो" कहना: आपको ऐसा कोड मिलता है जिस पर आपने कभी तर्क नहीं किया, और आप कुछ नहीं सीखते। सही तरीका: एक संरचित आलोचना की माँग करें - पठनीयता, बग, सुरक्षा - अंशांकित गंभीरता और तर्कों के साथ।
तुम एक कड़े सीनियर रिव्यूअर हो, जैसे किसी टीम के कोड रिव्यू में। तुम्हारा लक्ष्य मुझे बेहतर बनाना है, मुझ पर नरमी बरतना नहीं।
यह रहा मेरा कोड ([भाषा], संदर्भ: [यह किसलिए है, प्रोजेक्ट की बाध्यताएँ]):
[कोड पेस्ट करो]
इसका तीन अक्षों पर विश्लेषण करो:
1. पठनीयता: नामकरण, संरचना, ग़ैरज़रूरी जटिलता, अस्पष्ट इरादा।
2. बग: अनसंभाले किनारे के मामले, मौन एरर, असंगत स्थितियाँ, समवर्तीता।
3. सुरक्षा: असत्यापित इनपुट, इंजेक्शन, उजागर संवेदनशील डेटा, अनुमतियाँ।
आउटपुट का प्रारूप: हर टिप्पणी के लिए - संबंधित लाइन या ब्लॉक, अक्ष, गंभीरता (अवरोधक / महत्वपूर्ण / मामूली), और एक-दो वाक्यों में क्यों।
बाध्यताएँ: मेरा कोड दोबारा मत लिखो। ज़्यादा से ज़्यादा 8 टिप्पणियाँ, सबसे गंभीर पहले। अगर कोई विवादास्पद फैसला संदर्भ के हिसाब से बचाया जा सकता है, तो उसे दोष गिनने के बजाय स्पष्ट रूप से यह कहो।8 टिप्पणियों की गंभीरता-क्रम में लगी सीमा पर ध्यान दें: इसके बिना, आपको 25 नुक्ताचीनियाँ मिलती हैं जहाँ एक छूटा हुआ इनपुट सत्यापन एक नामकरण की पसंद जितना ही भारी तौला जाता है। बचाव-योग्य फैसलों वाली शर्त पर भी ध्यान दें: यह मॉडल को वस्तुनिष्ठ दोष को विवादास्पद परिपाटी से अलग करने पर मजबूर करती है। फिर आता है सबसे सिखाऊ हिस्सा, जिसे लगभग हर कोई छोड़ देता है: अपने फैसलों का बचाव करना। रिव्यू कोई लागू करने का फैसला नहीं, यह एक संवाद है। जब कोई टिप्पणी अनुचित लगे, तो पलटकर बहस करें। या तो आपके कारण टिकते हैं और आपने आखिरकार उन्हें साफ़-साफ़ कह दिया, या वे ढह जाते हैं और आप पाते हैं कि यह "फैसला" महज़ एक आदत थी।
चलो तुम्हारी टिप्पणी नंबर [X] पर फिर से आते हैं: तुम मानते हो कि [टिप्पणी को दोहराओ]।
मैं असहमत हूँ, और ये रहे मेरे कारण: [तुम्हारे तर्क - मापी गई प्रदर्शन बाध्यता, बाकी कोड के साथ संगति, जानबूझकर की गई सादगी, समयसीमा...]।
1. मेरे हर तर्क का ईमानदारी से मूल्यांकन करो: कौन-से टिकते हैं, कौन-से महज़ बहाने हैं?
2. मेरी स्थिति के खिलाफ़ सबसे मज़बूत प्रति-तर्क दो, जैसे कोई असहमत अनुभवी सहकर्मी देता।
3. निष्कर्ष दो: मेरे विशिष्ट संदर्भ में, क्या यह बदलाव अपनी लागत के लायक है? हाँ या ना में जवाब दो, फिर ज़्यादा से ज़्यादा तीन वाक्यों में औचित्य बताओ।
मुझे सही साबित करने की कोशिश मत करो: अगर मेरे तर्क कमज़ोर हैं, तो बेबाकी से कह दो।AI रिव्यू के दो चिरपरिचित जाल। पहला जाल: आत्मविश्वास के साथ दी गई झूठी चेतावनियाँ - मॉडल किसी ऐसी रेस कंडीशन को उठा देता है जो आपके आर्किटेक्चर में असंभव है, या किसी ऐसे "बग" को जो आपके भाषा-संस्करण में बग है ही नहीं। हर टिप्पणी को ऐसे लें जैसे वह किसी शानदार सहकर्मी से आ रही हो जिसके पास पूरा संदर्भ नहीं है: प्रशंसनीय, पर सत्यापित की जाने वाली। दूसरा जाल: सुरक्षा का दिखावा। AI चिरपरिचित पैटर्न (SQL इंजेक्शन, XSS, सादे पाठ में सीक्रेट) पकड़ने में बहुत अच्छा है पर कारोबारी-तर्क के दोष चूक जाता है - किसी रूट पर छूटी हुई अनुमति जाँच, कोई शोषण-योग्य बीच की स्थिति। AI रिव्यू पूरक है, वह न किसी ऑडिट की जगह लेता है न आपके डोमेन ज्ञान की।