Critique - Google डेवलपर संतुष्टि को 97% तक ले जाकर code review की तकलीफ़ कैसे कम करता है

• कई ex-Googlers Google के code review tool "Critique" को याद करते हैं
• Google के आंतरिक सर्वे के अनुसार 97% डेवलपर Critique से संतुष्ट हैं

Google की code review guidelines

• परफेक्शन से ज़्यादा लगातार सुधार को प्रोत्साहित करना
• codebase की स्थिति को बनाए रखना या बेहतर बनाना
• style guide का पालन करना
• हमेशा ज्ञान साझा करना: code review के ज़रिए language features, codebase और अन्य संबंधित artifacts के बारे में knowledge sharing को प्रोत्साहित करना
• बदलावों को छोटा रखना (लगभग 200 lines)
• तेज़ turnaround के लिए सख्त मानक (24 घंटे के भीतर code changes की समीक्षा, और संभव हो तो एक ही reviewer)
• विनम्रता और प्रोफेशनलिज़्म: trust और respect की culture को बनाए रखना महत्वपूर्ण है

Critique: Google का code review tool

• engineers code changes को कुशलता से review और submit कर सकते हैं
• हालिया शोधपत्र - Resolving code review comments with ML के अनुसार, Google एक comprehensive AI-based code review tool का उपयोग कर रहा है
  • reviewer जब code पर comment छोड़ता है, तो Critique ML-based edit suggestions दिखाता है
  • code review लेखक सिर्फ़ एक button क्लिक करके उस comment के अनुसार पूरे बदलाव लागू कर सकता है

code review flow

• चरण 1: बदलाव लिखना
  • CL (या Pull Request) Google के internal code editor Cider में लिखा जाता है
  • यह Critique और अन्य Google के internal tools के साथ क़रीबी integration में है, जिससे developer productivity बढ़ती है
  • Prereview tool: review से पहले बदलावों को polish करना, diff, build और test results, तथा style checks दिखाना
  • Diff view और visualization: syntax highlighting, cross-reference, intraline Diffing, whitespace ignore, और move detection features
  • static analyzers के results दिखाकर महत्वपूर्ण findings को highlight करना और fix suggestions देना. इसमें Critique के भीतर चलने वाले automated tests "presubmits" भी शामिल हैं
• चरण 2: review request
  • जब pull request review के लिए तैयार हो जाता है, तो code author reviewer जोड़कर उसे औपचारिक रूप से review के लिए भेजता है
  • review के लिए PR/CL भेजे जाने पर, अगर current code snapshot पर अभी तक नहीं चला है, तो "Presubmits" चलाए जाते हैं. इससे review में शामिल सभी लोग जान सकते हैं कि code में कोई समस्या है या नहीं
  • code review को anonymize भी किया जा सकता है ताकि code author reviewer से anonymous रहे. लेकिन Google को anonymous code review और 'वास्तविक' code review के बीच कोई उपयोगी अंतर नहीं मिला
• चरण 3 और 4: बदलाव समझना और comments करना
  • कोई भी बदलावों पर comment कर सकता है, और review progress track करने तथा comments resolve करने की सुविधा मिलती है
  • unresolved comments उन action items को दर्शाते हैं जिन्हें बदलाव के author को ज़रूर address करना चाहिए. जब code author सीधे comment का reply देता है, तो उन्हें 'resolved' के रूप में mark किया जा सकता है
  • resolved comments में optional या informational comments भी शामिल हो सकते हैं, जिन पर author को action लेने की ज़रूरत नहीं होती
  • review status देखने के लिए dashboard है, और "Attention Set" यह बताता है कि किसी विशेष code review में इस समय किसकी बारी है
• चरण 5: बदलाव approve करना
  • जैसा ऊपर बताया गया है, review दर्ज होने के लिए कम-से-कम एक reviewer से LGTM(Looks Good To Me) मिलना ज़रूरी है
  • code author comments को सीधे resolved mark कर सकता है, लेकिन unresolved comments की संख्या 0 होनी चाहिए
  • इसके अलावा, जिस codebase हिस्से में code जा रहा है उसके owner की approval और readability approval भी चाहिए
  • यह सारा काम एक ही reviewer भी कर सकता है
• चरण 6: बदलाव commit करना
  • बदलावों को Critique के भीतर ही submit और commit किया जाता है
  • बदलाव submit हो जाने के बाद भी Critique उपयोगी बना रहता है

  • "Google के शोधकर्ताओं ने मज़बूत सबूत पाए कि Critique का उपयोग सिर्फ़ code review से आगे तक फैला हुआ है. change authors Critique का उपयोग diff की समीक्षा करने और analysis tool results देखने के लिए करते हैं. कुछ मामलों में code review बदलाव development process का हिस्सा होता है, जहाँ reviewers implementation पूरा करने का तरीका तय करने के लिए अधूरे बदलाव भी भेज सकते हैं. साथ ही, approvals के बाद भी developers submitted changes का history review करने के लिए Critique का उपयोग करते हैं."

Google के नवीनतम code review आँकड़े

• change authoring frequency:
  • median: प्रति सप्ताह 3 बदलाव
  • 80% authors हर सप्ताह 7 से कम बदलाव करते हैं
• review frequency:
  • median: प्रति सप्ताह 4 बदलावों की review
  • 80% reviewers हर सप्ताह 10 से कम बदलाव संभालते हैं
• प्रति सप्ताह reviews पर लगने वाला समय:
  • औसतन प्रति सप्ताह 3.2 घंटे
  • median प्रति सप्ताह 2.6 घंटे
• initial feedback waiting time:
  • छोटे बदलाव: औसतन 1 घंटे से कम
  • बहुत बड़े बदलाव: लगभग 5 घंटे
• पूरा review process time:
  • सभी code sizes में औसत latency: 4 घंटे से कम
  • अन्य कंपनियों से तुलना:
    • AMD: 17.5 घंटे (approval तक लगने वाला median समय)
    • Chrome OS: 15.7 घंटे
    • Microsoft projects: 14.7 घंटे, 19.8 घंटे, 18.9 घंटे
    • Microsoft (अन्य शोध): 24 घंटे

Googlers Critique को इतना क्यों पसंद करते हैं?

• static analysis: इनके पास full-featured static analysis tools का एक suite है, जो code पर automatically actionable feedback देता है. इससे author और reviewer दोनों का समय बचता है, और reviewer को obvious issues बार-बार बताने की ज़रूरत नहीं पड़ती
• सिर्फ़ सबसे हाल की बदली हुई files पर फ़ोकस: आप code के केवल नवीनतम 'snapshot' पर ध्यान दे सकते हैं. पुराने snapshots, commits और code changes नहीं दिखते, इसलिए UI ज़्यादा साफ़ रहता है
• परिचित Side-by-Side Diff interface: default रूप से "पिछली review से अंतर" दिखाया जाता है
• machine learning आधारित suggestions: Google की नई ML-based suggestion feature से code review बहुत तेज़ हो गया है
• अन्य Google tools के साथ क़रीबी integration: Critique, Google के IDE और bug tracker जैसे internal tools के साथ बहुत अच्छे से जुड़ा है, जिससे productivity बढ़ती है. इसमें code, comments और tickets को आसानी से जोड़ना शामिल है
• 'work set' tracking: यह पता चल जाता है कि अगला action किसे लेना है
• संतोषजनक gamification: Critique को gamified बनाने के लिए डिज़ाइन नहीं किया गया था, लेकिन Googlers कहते हैं कि जब Critique 'green' हो जाता था और PR submit करने के लिए तैयार होता था (सभी tests पास, reviewer LGTM approval), तो अच्छा लगता था
• Reddit पर आए comments
  • बहुत बड़ी मात्रा में code को efficiently review करने के लिए शानदार keyboard shortcuts
  • default रूप से "पिछली review से अलग" दिखाना
  • "code move detection" feature होने से code changes पर फ़ोकस करना आसान होता है
  • reviewer हो या author, किसे action लेना है यह बताने वाली शानदार सुविधा
  • Chrome extension के साथ इस्तेमाल करने पर notifications लेना और review queue देखना आसान
  • आंतरिक रूप से कोई भी code review data पर queries चलाकर insights इकट्ठा कर सकता है
  • code और comments का automatic linking (tickets और move/link सहित)
  • कई rounds वाले PRs में PR analysis, history और comments को table format में देखकर progress समझना बहुत आसान हो जाता है
  • optional, notes आदि जैसे comment terms/tags में बहुत consistency

विचार और संकेत

• इन features में से कई आज अन्य tools में भी मिल जाते हैं, लेकिन मुझे लगता है कि यह tool इसलिए पसंद किया जाता है क्योंकि यह Google के अपने workflow और codebase के साथ बेहद क़रीबी integration और अत्यधिक 'personalization' देता है
• साथ ही इसका मतलब यह भी है कि हर कंपनी Critique और उससे जुड़े tools की हूबहू नकल वास्तविक रूप से नहीं कर सकती. उदाहरण के लिए, कुछ tools monorepo structure से पैदा होने वाली समस्याओं के लिए खास तौर पर बने हैं
• Critique खुद open source के रूप में उपलब्ध नहीं होगा, लेकिन Gerrit Critique जैसा एक tool है. यह भी Google द्वारा बनाया और maintain किया जाने वाला open source code review tool है
• लेकिन मुझे लगता है कि Google developer productivity के लिए बहुत मेहनत और गंभीर सोच करता है. वे अपना शोध खुलकर प्रकाशित करते हैं, और उनके काम से उपयोगी insights लिए जा सकते हैं

[xguru]

Gerrit में ChatGPT जोड़ने की कोशिशें वाकई मौजूद हैं
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

[kkweon]

सबसे बड़ी बात जो महसूस होती है, वह यह है कि Critique में लगातार जुड़े हुए CLs की एक श्रृंखला को review किया जा सकता है। GitHub में PR chain को सीधे तौर पर support न करना असुविधाजनक है। इसलिए या तो एक बहुत बड़ा PR बन जाता है, या फिर पिछले PR के merge होने तक इंतज़ार करना पड़ता है।

[tested]

GitHub में भी कुछ ऐसा ही है, पता नहीं यह कब open होगा
> https://githubnext.com/projects/copilot-for-pull-requests

[winterjung]

स्टैटिक analysis और ML-आधारित सुझाव नहीं हैं, लेकिन लेख पढ़कर लगा कि यह GitHub review फीचर से काफी मिलता-जुलता है। GitHub review का काफी इस्तेमाल करने वाले के तौर पर, अच्छा होगा अगर Critique में दिए जाने वाले दूसरे फीचर भी और जोड़े जाएँ।

[xguru]

Google की code review guide [कोरियाई अनुवाद]