कोड रिव्यू और बेहतर हो सकता है

• डेवलपर्स GitHub के code review experience से काफ़ी असंतुष्ट हैं, और इसे बेहतर बनाने के लिए नए प्रयोग किए जा रहे हैं
• git-review नाम का एक experimental tool code review को browser web interface के बजाय, लोकल में सीधे code के साथ संभालने के लिए डिज़ाइन किया गया है
• रिव्यू को single commit के रूप में मैनेज किया जाता है, और code के अंदर comments की तरह review comments छोड़े जाते हैं; reviewer और author मिलकर इस commit को आगे सुधारते हैं
• लेकिन review के बीच code बदलने या rebase होने पर conflict handling और --force-with-lease के उपयोग जैसी दिक्कतें आती हैं, इसलिए इसे बड़ी सफलता नहीं मिली
• अंततः फिर से web-based review पर लौटना पड़ा, लेकिन review state को सीधे Git repository में शामिल करने का विचार अब भी आकर्षक है, और Gerrit-style Change-Id जैसी चीज़ों के साथ Git में भविष्य के सुधारों से बेहतर विकल्प आने की संभावना है

---

code review system को लेकर समस्या की पहचान

• इस समय बहुत से लोग GitHub के code review process से असंतुष्ट हैं
• मुख्य समस्याएँ हैं stacked pull requests और interdiff review के लिए पर्याप्त support का न होना, साथ ही
  • review state repository के अंदर store नहीं होती
  • review के लिए remote-first web interface अनिवार्य है
• मेरे लिए मुख्य समस्या है review का पर्याप्त decentralization न होना और interface की inefficiency

code लिखने और review workflow की तुलना

• लोग code लिखते समय लोकल में editor का उपयोग करते हैं
  • वहाँ memory और NVMe latency कम होती है, और environment उपयोगकर्ता के अनोखे workflow के लिए optimized होता है
• code review के लिए भी source branch को लोकल में pull करके काम करना ज़्यादा पसंद किया जाता है
  • Magit जैसे tools के ज़रिए सिर्फ diff ही नहीं बल्कि पूरे code context को भी explore किया जा सकता है
  • test चलाना, code definition पर जाना, refactoring आज़माना जैसी शक्तिशाली development environment की सुविधाएँ उपलब्ध होती हैं
• इसके उलट, PR पर feedback छोड़ने के लिए browser में जाकर धीमे web interface का इस्तेमाल करना पड़ता है, और बड़े diff में input latency भी काफ़ी बढ़ जाती है

आदर्श code review interface और storage structure

• असल में code में inline comments छोड़ना, या सीधे code को ठीक करना, सबसे स्वाभाविक तरीका है

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• जब data लोकल git repository के बजाय remote DB में store होता है, तो latency और vendor lock-in जैसी समस्याएँ भी पैदा होती हैं

git-review का विचार और वास्तविक अनुभव

• git-review का विचार इस प्रकार था:
  • code review, PR branch के शीर्ष पर मौजूद single commit के रूप में किया जाता है
  • उस commit में special markers वाले code comments जोड़े जाते हैं
  • reviewer और author बारी-बारी से इस commit को edit करते हैं, और push --force-with-lease पर आधारित collaboration होता है
  • सभी comments को resolved के रूप में चिह्नित (//? resolved) किया जाता है और review समाप्त होने पर revert commit जोड़कर उसका रिकॉर्ड रखा जाता है
• विचार सरल और व्यावहारिक था, लेकिन व्यवहार में ये समस्याएँ सामने आईं
  • review के दौरान code बदलने पर नीचे के commits या नए commits में comments के साथ अक्सर conflicts हो जाते थे
  • force-push की प्रक्रिया में collaboration friction बढ़ती थी और काम अधिक जटिल हो जाता था
  • code change history और review progress के बीच असंगति तथा merge conflicts को संभालना कठिन हो जाता था

नए बदलाव और भविष्य की संभावनाएँ

• आगे चलकर Git upstream में Gerrit-style Change-Id आने की संभावना है
  • इससे commit-वार change history को track करना आसान होगा और interdiff review के support का दायरा बढ़ सकता है
  • हालांकि git-review के तरीके के साथ कुछ टकराव की उम्मीद है
  • नए Change-Id structure में commit के अंदर ही review comments जोड़ने जैसे अलग तरीके संभव हो सकते हैं

निष्कर्ष और देखने लायक systems

• फिलहाल स्थिति फिर से web interface आधारित code review पर लौट आई है
• बेहतर solution की ज़रूरत अब भी बनी हुई है
• देखने लायक संबंधित systems और tools
  • Fossil: ऐसा SCM system जो सारी जानकारी repository के भीतर रखता है
  • NoteDb: Gerrit के review state history को git में integrate करता है
  • git-bug: issue information को git में store करता है
  • git-appraise: review information को git के भीतर ही रखता है
  • prr: editor के भीतर GitHub API के साथ integrate होकर review interface देता है
  • How Jane Street Does Code Review: बेहतर वास्तविक उदाहरण का परिचय
  • git-pr: ऐसा project जो पूरे PR workflow को git की native capabilities से replace करना चाहता है

समापन

• अभी तक कोई पूर्ण समाधान नहीं है, और बेहतर developer experience के लिए प्रयोग जारी हैं
• आगे के विकास को लेकर काफ़ी उम्मीदें हैं

[roxie]

मुझे नहीं पता कि git-review का तरीका अच्छा है या नहीं, लेकिन मैं इस बात से सहमत हूँ कि GitHub-आधारित PR review बेहद खराब है..

[GN⁺]

Hacker News राय

• code review के बारे में मेरी लंबे समय से एक बड़ी शिकायत यह रही है कि सच में उपयोगी feedback, यानी मामूली style या पसंद-नापसंद वाली टिप्पणियों के अलावा, लगभग हमेशा बहुत देर से आता है। review का एकमात्र, या बहुत दुर्लभ, नतीजा अक्सर यह बन जाता है: "इसे पूरी तरह फिर से नए design के साथ शुरू करना होगा" या "असल में यह काम शुरू से करना ही नहीं चाहिए था"। ऐसा लगता है कि code review ही वह एकमात्र समय है जब सभी stakeholders सच में शामिल होते हैं और बदलाव पर गंभीरता से सोचते हैं। हो सकता है meeting या Jira ticket में कुछ चर्चा हुई हो, लेकिन अक्सर संगठन के किसी दूसरे team या department का कोई व्यक्ति code review notification मिलने पर ही इस बदलाव के बारे में जानता है। मेरे साथ भी ऐसा कई बार हुआ है कि किसी दूसरी team ने कुछ अजीब implement किया हो और मुझे उसका पता पहली बार code review notification से चला हो। यह उम्मीद करना अवास्तविक है कि हर सदस्य पहले से सब कुछ follow up करता रहेगा। 90s के university courses में design review भी हुआ करते थे, लेकिन असली industry में मैंने ऐसा शायद ही कभी देखा है। और मुझे नहीं लगता कि design review भी पहले से सभी issues पकड़ लेने की गारंटी देता है।

  • SW engineering की दुनिया में असल engineering बहुत कम है। एक तरह से industry सही engineering process की धीमी रफ्तार को स्वीकार ही नहीं कर पाती। ज़्यादातर software mission-critical नहीं होता, और bugs या errors को बाद में patch किया जा सकता है। पुल, factory, या airplane engine जैसी दूसरी disciplines में failure की कीमत और patch का मौका बिल्कुल अलग होता है।

  • हमारी team 4~6 developers का एक छोटा group है। जब भी कोई नई feature बनानी होती है, तो दिमाग में rough draft बनते ही मैं तुरंत teammates से बात कर लेता हूँ। क्योंकि सब लोग ऐसा ही करते हैं, इसलिए code review ज़्यादातर code smell जैसी छोटी चीज़ों पर केंद्रित रहता है, और overall architecture आमतौर पर 2~3 लोग पहले ही तय कर लेते हैं। अगर team members code से सहमत न हों, तो वे एक-दूसरे के code को छूने से भी कतराते हैं, और तब स्थिति खराब हो जाती है। मुझे लगता है कि scale बड़ा होने पर भी, अगर ownership अच्छी तरह share की जाए, तो यह बिना समस्या के चल सकता है।

  • अगर सभी stakeholders सिर्फ code review के समय ही शामिल होते हैं, तो यह Git या version control system की समस्या नहीं बल्कि संगठन की समस्या है। यानी PR बनने का context, ticket discussion, और decision-making process share नहीं हो रही। यह dysfunctional organization का उदाहरण है, जैसे किसी publishing process को सिर्फ इसलिए बुरा कहना कि सब लोग तभी इकट्ठा होकर गंभीरता से जुड़ते हैं जब printed book निकलने वाली होती है।

  • हमारे organization में fundamental design decisions के लिए RFC लिखना अनिवार्य है। क्या चीज़ fundamental design decision मानी जाएगी, यह team समय-समय पर खुद तय करती है। अगर Jira के epic stage पर implementation details तय नहीं हुई हों, तो पहले RFC लिखने का task assign किया जाता है। RFC सिर्फ हमारी team के लिए भी हो सकती है, या पूरी software team के लिए; दूसरे मामले में 2 हफ्ते में होने वाली meeting से पहले सभी लोग उसे पढ़कर comments छोड़ सकते हैं। मुश्किल ज़रूर है, लेकिन RFC-based collaborative design process न होने से यह कहीं बेहतर है।

  • design review को लेकर मैं अपने अनुभव से सहमत हूँ। पहले हम formal design documents और reviews किया करते थे, लेकिन बाद में prototyping और iterative design पर चले गए। design phase में महत्वपूर्ण details अक्सर छूट जाती थीं, और जब उस पर पहले ही काफी समय खर्च हो चुका होता था, तो बाद में लोग उसे बस यूँ ही आगे बढ़ा देते थे। पूरी team को review के लिए इकट्ठा करना भी inefficient था, इसलिए अंत में issues code review के दौरान ही सामने आते थे। बहुत से लोग design documents अच्छी तरह लिख नहीं पाते या उनमें motivation नहीं होती। नतीजे में, 5 से अधिक लोगों के साथ इस तरह की inefficiency से बचना मुश्किल है। PO, मुख्य users, और लगभग 5 developers वाला setup आदर्श लगता है।

• HN पर stacked pull request के बारे में पोस्ट देखना बहुत दिलचस्प था। जब मैंने पहले graphite.dev शुरू किया था, तब FB या Google background वाले लोगों के अलावा बहुत से लोग इस workflow से परिचित नहीं थे। पिछले 3~4 साल में code review trends इतनी तेजी से बदलते देखना दिलचस्प है।

  • pre-mercurial arcanist user होने के नाते, मैं अभी भी बड़े PRs और merge commits से जूझ रही teams को Graphite ज़ोर से recommend करता हूँ। खासकर PRs के साथ integration संभव बनाने की उनकी ambition और उसके results से मैं बहुत प्रभावित हूँ। अच्छा होगा अगर Graphite में ऐसा prescriptive mode हो जो hard-core setup के साथ repo initialize करे, ताकि वह और मजबूत assumptions ले सके।

  • Graphite एक शानदार solution है, लेकिन इसकी pricing काफ़ी महंगी है और buyers को मनाना आसान नहीं। उम्मीद है Graphite जैसा कोई बढ़िया tool open source हो जाए या GitHub में built-in आ जाए।

  • मुझे कभी-कभी fig workflow की याद आती है

  • CodeRabbit में हाल की security incident के बाद, LLM और codebase को integrate करने वाले नए tools को test करने में हिचक हो रही है। अक्सर चमकदार नए experiments जल्दी security risk में बदल जाते हैं।

  • stacked pull request मूल रूप से ऐसी complexity जोड़ता है जिसकी ज़रूरत नहीं होनी चाहिए। बार-बार, छोटे unit में changes करना कहीं बेहतर development practice है। trunk-based development या continuous integration उस लक्ष्य के लिए बेहतर fit हैं।

• अब ज़्यादा से ज़्यादा developers इस बात पर सहमत दिख रहे हैं कि "review tool कैसा होना चाहिए"। अब असली सवाल यह है कि कौन-सा organization और कौन-से players इसे सच में practical और sustainable बना पाएँगे। हाल में git change-id का आना अच्छा progress है, इसके लिए jj, git butler, gerrit आदि का धन्यवाद। Graphite या GitHub अपने-अपने users के लिए बने solutions पर केंद्रित हैं, इसलिए वे सबके लिए खुले रास्ते नहीं हैं। बहुत से client-based command-line tools भी खास असरदार नहीं हैं। सच में ज़रूरी चीज़ें ये हैं:

  • इसे पूरी तरह local पर इस्तेमाल किया जा सके
  • vscode के लिए official core team support हो, और सिर्फ vscode integration के लिए भी अच्छा UX मिले
  • vscode web जैसे web UI और दूसरे editors के साथ भी जितना हो सके UI assets reuse किए जा सकें
  • core functionality CLI या library के रूप में मिले, और extensibility के लिए साफ boundaries हों
  • commit/branch/stacked commit/agent snapshot/dev self-review सब supported हों
  • CI/CD signals native रूप से integrate हों, और meta ने जो बेहतरीन UI work दिखाया है उस पर आगे build किया जा सके
  • context के हिसाब से बहुत fine-grained हो और हर stage पर editable हो; जैसे cursor में line-by-line accept किया जा सकता है, वैसे ही human code review में भी granular editing चाहिए
  • यह पूरी तरह incremental हो, और PR update होने पर पूरे PR की जगह सिर्फ changed parts को review करने का आसान तरीका हो

• Github के बारे में मेरी सबसे बड़ी शिकायत यह है कि app बहुत slow है। सच में browser tab तक hang हो जाता है। Azure DevOps अब तक इस्तेमाल किए गए code review tools में सबसे अच्छा था।

  • Microsoft environment में .NET development करते समय मैंने Azure DevOps इस्तेमाल किया है, और यह सच में .NET ecosystem के लिए बहुत उपयुक्त tool है

  • सोच रहा हूँ कि क्या आपने GitLab को गंभीरता से इस्तेमाल किया है। big 4 में मुझे GitLab सबसे ज़्यादा पसंद है।

  • जानना चाहता हूँ कि DevOps में आपको ऐसा क्या खास पसंद आया। मैं इसे रोज़ इस्तेमाल करता हूँ, और यह मुझे github जैसा ही लगता है। उल्टा github की suggested changes को auto-apply करने वाली feature की कमी महसूस होती है।

  • JavaScript का भारी इस्तेमाल और fast release pressure मिलकर ऐसा slow environment बनाते हैं। फिर भी यह Atlassian से बेहतर है

• code review के लिए सीधे git का इस्तेमाल करने का विचार आकर्षक है। local पर changes को खुद छूकर देख पाना काफ़ी सुविधाजनक है। समझ नहीं आता कि review को ज़रूरी रूप से एक ही commit तक सीमित क्यों रखा जाए—ऐसा approach भी रोचक है जिसमें reviewer अपनी comments या fixes सीधे PR branch पर commit कर दे। यह पारंपरिक github flow और Linux के mailing list + patch workflow का hybrid है।

  • क्या github PR read-only होता है? मुझे याद है कि किसी teammate ने "suggestion" comment के रूप में सीधे fix propose किया था और एक button click से वह उसी commit में apply हो गया था

  • review commit का single होना अजीब है। अगर कई लोग review करें, तो concurrent editing की समस्या भी आएगी और यह code की प्रकृति से भी मेल नहीं खाता। ज़्यादा स्वाभाविक तो यह है कि review भी अलग-अलग branches पर अलग लोग करें, और अंत में squash & rebase हो। अगर discussion लंबी चले, तो comment commits भी chain की तरह छोड़ी जा सकती हैं। असली बात यह है कि यह data main branch के बाहर कहीं मौजूद रहना चाहिए

• code review करते समय मैं local branch में changes pull करके soft-reset करता हूँ, और फिर उन्हें ऐसे देखता हूँ जैसे मैंने खुद लिखा हो। अगर commits अच्छी तरह split न हों, तो collaborators को भी review के लिए उन्हें अपने-अपने तरीके से split करना पड़ता है, जो inefficient है। जब review का scope बहुत बड़ा हो, तो यह कहना मुश्किल है कि किसी ने उसे पूरी तरह समझ लिया। पूरा केवल parts का sum नहीं होता।

  • आसान code review के लिए एक shell function example साझा कर रहा हूँ। clean tree की स्थिति में यह preset review branch checkout करता है, nvim में diff दिखाता है, और काम पूरा होने पर branch cleanup तक automate करता है

  • अच्छे commits और उनसे बने अच्छे PRs तैयार करना भी उतना ही महत्वपूर्ण skill है जितना अच्छा code लिखना। लेकिन व्यवहार में PR split करना, commit messages लिखना आदि में बहुत से developers उम्मीद से कमज़ोर होते हैं

  • data science की parallel work करने वाली team में हम code review के लिए 2~3 branches checkout करके इस्तेमाल करते हैं

  • PR review के लिए मैं Neovim में https://github.com/sindrets/diffview.nvim इस्तेमाल करता हूँ। इसका UI vscode के diff जैसा है, लेकिन vim के diff mode का फायदा उठाता है। हल्के review के लिए git log -p --function-context भी उपयोगी है

• मुझे उस workflow में दिलचस्पी है जहाँ एक व्यक्ति पहला draft लिखता है और दूसरा उसे polish करके merge करता है। क्या किसी ने इसे व्यवहार में अपनाया है?

  • मैं उस style से सहमत हूँ जिसमें असली coding का 90% से ज़्यादा एक व्यक्ति करता है, और reviewer अंतिम integration और merge की ज़िम्मेदारी लेता है। मेरी पिछली नौकरी में reviewer ही हमेशा merge करता था, और अगर बदलाव बड़ा हो तो सिर्फ comments दे देता था। किसी से बार-बार approval click करवाने की तुलना में यह कहीं अधिक efficient है

  • अगर आप review किए जा रहे code को लिखने में खुद शामिल होते हैं, तो आप कहीं अधिक गहरा feedback दे सकते हैं। ऐसी संरचना "मेरा code/तुम्हारा code" की बजाय "हमारा code" वाली सोच को बढ़ावा देती है। यह TDD जैसी iterative और collaboration-centric culture के साथ बहुत अच्छी तरह मेल खाती है

  • यह तरीका asynchronous pair programming जैसा है

  • मैं ऐसे लोगों को जानता हूँ जो trunk-based development में pair programming का उपयोग करते हैं। दोनों मिलकर code लिखते हैं, फिर OK होने पर सीधे main में merge कर देते हैं, और tests pass होते ही तुरंत deploy कर देते हैं। यह व्यवहार में सच में काम करता है

• मैं VSCode में Github Pull Request extension plugin का उपयोग करके local review करता हूँ, और यह काफ़ी सुविधाजनक है। editor के अंदर ही सीधे comments करना और review करना संभव है

  • Github web में जब changed files बहुत ज़्यादा हों तो files छिपा दी जाती हैं, लेकिन VSCode में आप आराम से navigate कर सकते हैं, इसलिए अनुभव कहीं बेहतर है। चूँकि यह सुविधा VSCode/Github combination में implement हो चुकी है, मुझे लगता है कि यह दूसरे editors तक भी फैल सकती है

  • सुधार तो है, लेकिन Github और VSCode के बीच vendor lock-in अब भी गहरा है

  • Github web पर PR खोलकर “.” key दबाते ही सीधे VSCode web में review करना भी कहीं बेहतर अनुभव है

• Git में first class change ID आने की बात सुनकर बहुत खुशी हुई! यह Facebook के Phabricator diffs revision tracking जैसा लगता है। इसके बारे में और विस्तार से पढ़ने के लिए कोई link जानना चाहूँगा

  • मूल समस्या यह है कि git branch information को ठीक से manage नहीं कर पाता। Fossil को याद रहता है कि commit किस branch में बना था। task branch खुद change ID का काम करती है। बेशक git को history rewriting भी allow करनी होती है, इसलिए इसका समाधान आसान नहीं है

• Sourcehut का भी ज़िक्र करना चाहिए। यह classic patch/issue/bug/discussion को email के ज़रिए संभालने वाले workflow की परंपरा को आगे बढ़ाता है, और mailing list तथा CI के साथ integrate होता है। Drew Devault के git-send-email.io, git-am.io पर patches भेजने और प्राप्त करने के तरीकों के resources भी उपलब्ध हैं।