AI से बने code का review करें

Summary से पहले requirement पढ़ें

माँगे गए व्यवहार और acceptance criteria से शुरू करें। फिर वास्तविक diff जाँचें। Agent की summary आपको रास्ता दिखा सकती है, लेकिन उसमें बदलाव छूट सकते हैं या checks गलत बताई जा सकती हैं।

Review की branch और commit की पुष्टि करें। Application code के साथ configuration, dependency, infrastructure और test changes भी जाँचें। छोटा दिखने वाला feature permissions या deployment के व्यवहार में बड़ा बदलाव शामिल कर सकता है।

सबसे अधिक असर वाले व्यवहार का review पहले करें। Formatting और naming जरूरी हैं, लेकिन उनके कारण छूटी डेटा सीमा से ध्यान नहीं हटना चाहिए।

Identity से resource तक का रास्ता जाँचें

इस अधूरे, काल्पनिक endpoint को देखें। उदाहरण review की समस्या समझाता है; यह production code नहीं है।

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

Function authenticated उपयोगकर्ता प्राप्त करता है। इसमें invoice के लिए authorization का निर्णय नहीं दिखता। Reviewer को जाँचना चाहिए कि दूसरी layer यह निर्णय लागू करती है या नहीं। इस्तेमाल न हुआ user value जाँच का कारण है, अपने आप किसी exploitable defect का प्रमाण नहीं।

वास्तविक system में request का रास्ता trace करें। Trusted user और organization पहचानें। जाँचें कि query माँगे गए record का access कैसे सीमित करती है। प्रतिबंधित अनुरोधों के लिए error का व्यवहार और tests देखें।

यह न मानें कि छिपा button API की सुरक्षा करता है। Caller interface इस्तेमाल किए बिना request भेज सकता है। यह भी न मानें कि मान्य record ID से access मिल जाता है।

पूछें कि कौन-सा प्रमाण बदलाव अस्वीकार कर सकता है

Pass हुआ test administrator fixture या mock authorization का उपयोग कर सकता है। जाँचें कि वह जरूरी सीमा परखता है या नहीं। जहाँ उचित हो, दूसरी organization और वास्तविक authorization path वाला case जोड़ें।

User interface बदलने पर rendered परिणाम देखें। Keyboard से संचालन, empty states, loading का व्यवहार और errors जाँचें। Type check यह सिद्ध नहीं कर सकती कि dialog keyboard से उपयोग किया जा सकता है।

Dependency बदलने पर उसकी जरूरत जाँचें। Version, license और security findings का review करें। केवल इसलिए असंबंधित upgrade स्वीकार न करें कि agent ने काम के दौरान उसे generate किया।

Review स्वतंत्र रखें

दूसरा मॉडल उपयोगी समस्याएँ पहचान सकता है। वह implementation की धारणाएँ भी दोहरा सकता है। Reviewer को requirement और diff दें। उसे यह न बताएँ कि बदलाव पहले से सही है।

Findings में विफलता का ठोस रास्ता और संबंधित code माँगें। अप्रमाणित warnings को जाँचने वाले प्रश्न मानें। महत्वपूर्ण दावों का प्रमाण मिलने तक आत्मविश्वास भरे approval को भी एक और राय मानें।

Human review में जिम्मेदारी का निर्णय बना रहता है। Reviewer बदलाव को इतना समझे कि उसका व्यवहार, जोखिम और verification बता सके। Diff बहुत बड़ा हो तो दायरा घटाएँ या उसे review किए जा सकने वाले बदलावों में बाँटें।

अंतिम revision पर review पूरा करें

सुधार के बाद प्रभावित checks फिर चलाएँ। जाँचें कि सुधार कोई नई समस्या तो नहीं बनाता। Repository की policy के अनुसार जरूरी review अंतिम revision पर लागू होना चाहिए।

स्वीकृति का निर्णय व्यवहार और प्रमाण के आधार पर लिखें। बची सीमा के साथ जिम्मेदार व्यक्ति और अगली कार्रवाई दर्ज करें। अनसुलझे issue को यह दावा न बना दें कि सभी checks pass हो गईं।

वास्तविक बदलाव जाँचने से पहले छूटा निर्णय पहचानने के अभ्यास के लिए code review अभ्यास इस्तेमाल करें।