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

• डेवलपर्स 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 के लिए प्रयोग जारी हैं
• आगे के विकास को लेकर काफ़ी उम्मीदें हैं