Code review के लिए पढ़ना ज़रूरी है

• Code review डिप्लॉयमेंट से पहले की कोई औपचारिक प्रक्रिया नहीं, बल्कि outage, security issues और data deletion की ज़िम्मेदारी को किसी एक व्यक्ति से हटाकर टीम की ज़िम्मेदारी में बदलने की प्रक्रिया है
• बेहतर evals, tests, feature flags, guardrails और observability बिना पढ़े गए code को deploy करने की चिंता कम करने के जवाब हो सकते हैं, लेकिन आलोचना यह है कि यह review के ज़िम्मेदारी बाँटने वाले मकसद को चूकता है
• बिना पढ़े approve करने की मांग करना किसी इंसान से बिना सोचे-समझे बटन दबवाने जैसा है, और इसी से सभी CI green वाले किसी भी random PR को merge कर देने वाली button roulette जैसी व्यंग्यात्मक कल्पना निकलती है
• Code review टीम के लोगों को बड़े codebase के अलग-अलग हिस्से देखने पर मजबूर करता है, जिससे bus factor कम होता है, और यह नए team members के लिए code और code culture सीखने का साधन भी बनता है
• अगर बिना पढ़े code को deploy करवाना है, तो bugs, security issues, downtime आदि के लिए लिखित liability waiver चाहिए होगा, और निष्कर्ष यह है कि ऐसा waiver मिलना मुश्किल है

---

review का मकसद approval से ज़्यादा ज़िम्मेदारी बाँटना है

• Charity Majors के लेख “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy” में उठाया गया सवाल — “बिना पढ़े गए code को production में deploy करने में सहज होने के लिए क्या चाहिए?” — इस चर्चा की शुरुआत है
• बेहतर evals, tests, feature flags, guardrails, observability, dependency isolation, blast radius कम करना, और critical path के बाहर छोटे बदलावों से शुरुआत जैसी प्रतिक्रियाएँ review के मूल बिंदु से भटकी हुई बताई गई हैं
• Review का उद्देश्य outages, security issues और accidental data deletion का बोझ किसी एक व्यक्ति पर छोड़ने के बजाय author और reviewers सहित पूरी टीम की साझी ज़िम्मेदारी बनाना है
• अगर “बिना पढ़े approve” करने को कहा जाए, तो किसी इंसान से manual button दबवाने की वजह कमजोर पड़ जाती है, और सभी CI green वाले assigned PRs में से किसी एक को random merge करने वाली button roulette जैसी व्यंग्यात्मक बात सामने आती है

बिना पढ़े होने वाली review क्या खो देती है

• Code review टीम के सदस्यों को codebase के दूसरे हिस्से देखने के लिए मजबूर करता है, जिससे उस सीमा की भरपाई होती है कि बहुत बड़े सिस्टम में कोई भी हर हिस्से को हमेशा नहीं जान सकता
• Review प्रक्रिया bus factor को कम करती है, और टीम के कई सदस्यों को codebase और code culture से अधिक परिचित होने में मदद करती है
• अगर सभी लोग बिना पढ़े approve करने लगें, तो यह सीखने वाला असर खत्म हो जाता है, bus factor 1 तक बढ़ जाता है, और समस्या किसी तीसरे पक्ष पर बाहर ठेल दी जाती है
• निष्कर्ष यह है कि बिना पढ़े गए code को production में deploy करने की मांग स्वीकार करने के लिए, यह निर्देश देने वाले व्यक्ति को bugs, security issues, downtime आदि पर लिखित liability waiver देना होगा

[GN⁺]

Lobste.rs की राय

• इस दावे से बहुत असहजता होती है कि review का उद्देश्य responsibility को बाँटना है
  अगर main में merge किया गया code production तोड़ देता है, तो वह लेखक की ज़िम्मेदारी है, मेरी या पूरी टीम की नहीं
  यह एक पेशेवर के रूप में अपने हस्ताक्षर वाला काम है; जैसे civil engineering में P.E. लाइसेंस के साथ मुहर लगी पुल की design से किसी की मौत हो जाए, तो वह भी उसी व्यक्ति के काम और ज़िम्मेदारी का मामला है
  टीम की ज़िम्मेदारी, developer और codebase के संरक्षक के रूप में, यह सुनिश्चित करने में है कि किसी का भी code production न तोड़ सके

  • मेरा मानना है कि main में merge किया गया code production तोड़ दे तो उसे सिर्फ व्यक्तिगत ज़िम्मेदारी मानना स्वस्थ संस्कृति नहीं है
    main merge का मतलब है कि किसी ने उसे review किया, बदलावों को परखा, design पर चर्चा की, कई बार संशोधन हुए, और फिर approve किया गया
    Eiffel Tower कोई अकेला नहीं बनाता, और workplace में व्यक्ति-दोष पर ज़ोर देने से सिर्फ resentment और toxic culture पैदा होती है
    अगर यह बार-बार दिखने वाला व्यवहार पैटर्न है, तो वह HR का विषय है
  • अगर reviewer की बिल्कुल भी ज़िम्मेदारी नहीं है, तो वह review न होने जैसा ही है
    अगर ज़िम्मेदारी 0 है, तो reviewer बेकार है और review करने की कोई खास वजह नहीं बचती
    responsibility का बँटवारा एक परिणाम के ज़्यादा करीब है; असली उद्देश्य errors पकड़ना है, जिन्हें अकेला व्यक्ति आसानी से छोड़ सकता है लेकिन दो या अधिक लोगों के लिए चूकना कठिन होता है
    फिर भी मेरा मानना है कि software में review का अत्यधिक उपयोग हो रहा है, और review engineering का विकल्प नहीं बन सकता

• “code पढ़े बिना approve करना” को “बिना सोचे approve करना” के बराबर मानना मुझे सही नहीं लगता
  उदाहरण के लिए, अगर किसी program के साथ correctness proof जुड़ा हो, PR में definitions और theorems पढ़े जा सकें, CI किसी deterministic tool से program और proof के मेल की पुष्टि करे, और contrast ratio, performance benchmark, tail latency जैसी non-functional requirements भी जाँची जाएँ, तथा UI changes के लिए prototype को आसानी से चलाकर देखा जा सके, तो क्या होगा
  ऐसे संसार में भी क्या code को पंक्ति-दर-पंक्ति पढ़ने पर आज जितना ज़ोर देना ज़रूरी होगा, इस पर संदेह है
  आज भी ज़्यादातर लोग SQL लिखते समय हर query plan को एक-एक कर यह नहीं जाँचते कि वह उनकी मंशा से पूरी तरह मेल खाता है
  मूल लेख मुझे “आइए उस आदर्श दुनिया को परिभाषित करें जहाँ code को शाब्दिक रूप से पढ़े बिना भी deploy करना ठीक लगे” के अधिक करीब लगता है, और फिर वह पूछता है, “हम वर्तमान से उस दुनिया तक smoothly कैसे पहुँचे?”
  industry, किसी खास company, या किसी codebase की उस बिंदु से दूरी कितनी है, इस पर बहस हो सकती है, लेकिन अगर उस आदर्श दुनिया की गंभीरता से कल्पना करें, तो ज़्यादातर लोग कुछ न कुछ मानदंड ज़रूर सोच पाएँगे
  मौजूदा industry trend को देखते हुए इसे “बिना सोचे” मान लेने की भावना समझ में आती है, लेकिन मुझे नहीं लगता कि Charity के लेख का आशय वही है

  • मूल लेख का मुख्य बिंदु PR में समस्या पकड़ना नहीं, बल्कि codebase से परिचित होना और जवाबदेही बनाना है
    यह ऐसी चीज़ है जो tests कितने भी अच्छे हों, code पढ़े बिना संभव नहीं
    अगर Alice code डालती है, Bob उसका review करता है, और फिर Alice छुट्टी पर चली जाती है, तो Bob को उस हिस्से की इतनी समझ और जिम्मेदारी महसूस होनी चाहिए कि वह fix कर सके या नया feature जोड़ सके
    अगर Bob केवल correctness proof पर मुहर लगाता है, तो वह बाद में उस codebase पर काम करने के लिए तैयार नहीं होगा
    अगर commit process में शामिल होने के बाद भी ज्ञान या ownership नहीं बढ़ा, तो वह लगभग शामिल न होने जैसा ही है
  • यह व्याख्या एक सामान्य compiler जैसी लगती है
    फर्क बस इतना है कि compiler deterministic होता है, जबकि LLM ऐसा non-deterministic tool है जो संभावित रूप से संदिग्ध tests पैदा कर सकता है
    हमारे पास पहले से ऐसे program हैं जो मनुष्यों द्वारा लिखे गए निर्देशों या code को machine-readable code या intermediate representation में बदलते हैं, और वे यह गारंटी देते हैं कि generated output का input से कैसा संबंध है, इसलिए अक्सर output को अलग से जाँचे बिना भी उस पर भरोसा किया जा सकता है
    optimization के लिए कभी-कभी Godbolt जैसे tools में compiler output पढ़ा जाता है, लेकिन उसके अलावा आम तौर पर इसकी ज़रूरत नहीं पड़ती
    इसे किसी non-deterministic abstraction level पर करने की कोशिश ऊपर-ऊपर से आकर्षक लग सकती है, लेकिन वह compiler द्वारा दी जाने वाली correctness guarantees की नकल भर है और अंततः समस्या पैदा करेगी
    अधिक बुनियादी स्तर पर, मेरा मानना है कि LLM पर बहस इस बात का लक्षण है कि मौजूदा deterministic programming languages पर्याप्त रूप से expressive नहीं हैं और tools भी पर्याप्त प्रभावी नहीं हैं
    LLM ऐसा महसूस करा सकता है कि वह उस समस्या का समाधान है, लेकिन वह वास्तविक समाधान नहीं; वह बस पहले से सीमित आधार पर एक और layer of indirection और performance cost जोड़ देता है
    यह interpreter के ऊपर, और फिर compiled machine code के ऊपर चलने वाले महंगे और buggy pseudo-compiler के अधिक करीब लगता है
    इसलिए मुझे यह एक तकनीकी dead end लगता है
    companies के लिए यह short-term profit का रास्ता हो सकता है, लेकिन मुझे नहीं लगता कि यह software या software का उपयोग और निर्माण करने वाले मनुष्यों के संबंध को बेहतर बनाएगा
    software सिर्फ product ship करने की technology से बढ़कर है

• इसे use case के हिसाब से बाँटकर सोचना मददगार है
  अगर बात internal application UI के लिए नया JavaScript डालने भर की है, तो मुझे लगता है कि CSS तक ज़रूर-ज़रूर देखना आवश्यक नहीं है