संकेत और संदर्भ
साक्षात्कारकर्ता यह जानना चाहता है कि आप तकनीकी असहमति को कैसे संभालते हैं, न कि यह कि क्या आप कह सकते हैं "मैं अपने मानकों को लागू करता हूं।" ऐसे पुल अनुरोध पर विचार करें जहां आपको लगता है कि नई समवर्ती जटिलता (concurrency complexity), गोपनीयता जोखिम (privacy risk), या छूटा हुआ परीक्षण कोड की गुणवत्ता (code health) को कम कर देगा; लेखक इसे मामूली बताता है और पहले मर्ज करने के लिए कहता है। तथ्यों, चर्चा, निर्णय और परिणाम की व्याख्या करें।
Google Engineering Practices यह जांचने की सलाह देता है कि क्या लेखक के पास बेहतर संदर्भ है, और फिर कोड-हेल्थ के संदर्भ में चिंता को समझाएं। यदि जटिलता कोडबेस में बनी रहने वाली है, तो आम तौर पर इसे वर्तमान परिवर्तन में ही संबोधित करना बेहतर होता है; आपातकालीन स्थितियां एक अपवाद हैं। एक मजबूत उत्तर लेखक को 'कठिन' करार देने के बजाय सिद्धांत को एक सत्यापन योग्य सहयोग घटना पर आधारित करता है।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- आप अपने स्वयं के निर्णय की पुन: जांच करते हैं और लेखक के संदर्भ को स्वीकार कर सकते हैं।
- आप पद या व्यक्तिगत शैली के बजाय जोखिम, उपयोगकर्ता प्रभाव, परीक्षण और रखरखाव लागत के साथ चिंता की व्याख्या करते हैं।
- आप शुद्धता (correctness), सुरक्षा (security), गोपनीयता (privacy), या रिग्रेशन ब्लॉकर को फॉलो-अप कार्य और पसंद (preference) से अलग करते हैं।
- आप न्यूनतम व्यवहार्य परिवर्तन का प्रस्ताव करते हैं, सही समीक्षक को आमंत्रित करते हैं, और निर्णय या एस्केलेशन मार्ग को परिभाषित करते हैं।
- आप परिणाम को मापते हैं: रोके गए दोष, कम रोलबैक, समीक्षा समय, टीम का विश्वास और प्रक्रिया में सुधार।
पहले स्पष्ट करने योग्य प्रश्न
- क्या असहमति शुद्धता, सुरक्षा, गोपनीयता, प्रदर्शन, रखरखाव या कोडिंग पसंद के बारे में है?
- टिप्पणी किस स्तर से संबंधित है: कार्यान्वयन, परीक्षण, इंटरफ़ेस अनुबंध, रिलीज जोखिम, या टीम नीति?
- क्या लेखक ने नए साक्ष्य, ऐतिहासिक बाधाएं या समय सीमा प्रदान की? अंतिम तकनीकी निर्णय किसका है?
- क्या परिवर्तन अत्यावश्यक है, और क्या ग्रे रिलीज़ (gray release), रोलबैक, या फ़ीचर फ़्लैग (feature flag) जोखिम को कम कर सकता है?
- आप लेखक की गोपनीयता की रक्षा कैसे करेंगे और सार्वजनिक चर्चा को व्यक्तिगत निर्णय बनने से कैसे रोकेंगे?
30-सेकंड का उत्तर
"मैं पहले तथ्यों को पुनरुत्पादित या सत्यापित करता हूं और जांचता हूं कि क्या लेखक के पास ऐसा संदर्भ है जो मुझसे छूट गया था। यदि समस्या शुद्धता, गोपनीयता को प्रभावित करती है, या स्पष्ट रूप से कोड-हेल्थ को कम करती है, तो मैं कोड पथ, परीक्षण परिणाम और उपयोगकर्ता जोखिम का उपयोग करके समझाता हूं कि यह इस परिवर्तन से क्यों संबंधित है, और फिर सबसे छोटे समाधान का प्रस्ताव करता हूं। यदि यह पसंद का मामला है, तो मैं इसे गैर-अवरोधक (non-blocking) बनाता हूं। यदि हम अभी भी असहमत हैं, तो मैं एक डोमेन समीक्षक या तकनीकी लीड को आमंत्रित करता हूं और निर्णय व फॉलो-अप को रिकॉर्ड करता हूं। मैं डिलीवरी, गुणवत्ता और संबंधों के परिणामों की समीक्षा करके समाप्त करता हूं।"
चरण-दर-चरण समाधान
चरण 1: व्यक्तिगत निर्णय को एक परीक्षण योग्य दावे में बदलें
"यह कोड खतरनाक है" को "दो समवर्ती अपडेट नए मान को अधिलेखित (overwrite) कर सकते हैं क्योंकि कोई संस्करण जांच (version check) नहीं है" से बदलें। एक पुनरुत्पादन, लॉग, परीक्षण या बेंचमार्क प्रदान करें। टिप्पणी को कोड और जोखिम के बारे में रखें, लेखक की क्षमता के बारे में कभी नहीं। बिना सबूत के, ब्लॉक करने से पहले एक सवाल पूछें।
चरण 2: अपने छूटे हुए संदर्भ की जांच करें
इंटरफ़ेस अनुबंध, अनुकूलता (compatibility), रिलीज़ विंडो, निर्भर टीमों और रोलबैक के बारे में पूछें। Google का मार्गदर्शन बताता है कि लेखक कार्यान्वयन के अधिक करीब हो सकता है और उसके पास बेहतर जानकारी हो सकती है। यदि नए साक्ष्य आपके सुझाव को गलत साबित करते हैं, तो दृढ़ता को गुणवत्ता मानने के बजाय इसे स्वीकार करें और वापस लें।
चरण 3: टिप्पणियों को वर्गीकृत करें और न्यूनतम परिवर्तन का प्रस्ताव दें
प्रतिक्रिया को ब्लॉकर, गैर-अवरोधक सुझाव या सकारात्मक सुदृढ़ीकरण के रूप में वर्गीकृत करें। एक ब्लॉकर प्रतिलिपि प्रस्तुत करने योग्य शुद्धता, सुरक्षा, गोपनीयता या उच्च-संभावना वाले रिग्रेशन जोखिम से संबंधित होता है; एक शैली प्राथमिकता Nit या एक प्रलेखित परिपाटी हो सकती है। उसी पुल अनुरोध में असंबंधित रिफैक्टरिंग के बजाय एक छोटा पैच, परीक्षण या फ़ीचर फ़्लैग प्रदान करें।
चरण 4: कोड-हेल्थ के माध्यम से कारण समझाएं
समाधान को भविष्य की रखरखाव लागत, घटना की रोकथाम या उपयोगकर्ता अनुभव से जोड़ें। इस परिवर्तन के पथ, प्रभाव और स्वीकृति मानदंडों पर लागू किए बिना किसी नियम का लिंक पेस्ट न करें। यदि लेखक "बाद में इसे साफ करने" के लिए कहता है, तो मूल्यांकन करें कि क्या जटिलता को भुला दिया जाएगा या भविष्य की समीक्षाओं को कठिन बना दिया जाएगा।
चरण 5: एक निर्णय और एस्केलेशन मार्ग स्थापित करें
समीक्षा में समझौते और खुले प्रश्नों का सारांश दें। यदि आवश्यक हो, तो एक छोटी चर्चा निर्धारित करें या डोमेन अधिकार वाले समीक्षक को आमंत्रित करें। एक तकनीकी लीड को पद के आधार पर नहीं, बल्कि साक्ष्य, कोड-हेल्थ और डिलीवरी बाधाओं से निर्णय लेना चाहिए। एक मालिक और नियत तारीख के साथ एक अनसुलझे गैर-ब्लॉकर को ट्रैक करें।
चरण 6: परिणामों को सत्यापित करें और प्रक्रिया में सुधार करें
मर्ज करने से पहले, परीक्षण, स्थैतिक जांच (static checks), रोलआउट मेट्रिक्स और रोलबैक को सत्यापित करें। मर्ज के बाद, दोष, रोलबैक, समीक्षा राउंड और डिलीवरी समय का निरीक्षण करें। यदि वही असहमति दोहराई जाती है, तो हर बार केवल समझाने पर निर्भर रहने के बजाय डिज़ाइन समीक्षा, पुल-अनुरोध टेम्पलेट या दस्तावेज़ीकरण में सुधार करें। किसी आपात स्थिति के लिए समीक्षा को सीमित करें लेकिन जोखिम और समाधान का रिकॉर्ड रखें।
एक मजबूत नमूना उत्तर
"एक समवर्ती कैश माइग्रेशन के दौरान, मैंने टिप्पणी की कि राइट्स (writes) में संस्करण जांच का अभाव था। लेखक ने इसे सैद्धांतिक माना और मर्ज करने के लिए कहा। मैंने दो समवर्ती अपडेट के साथ पुराने मान द्वारा नए मान को अधिलेखित करने का पुनरुत्पादन किया और पुष्टि की कि एंडपॉइंट ने ऑर्डर की स्थिति बदल दी है, इसलिए यह इस परिवर्तन के लिए शुद्धता का ब्लॉकर था। मैंने स्वीकार किया कि लेखक लेगेसी संगतता फ़ील्ड को बेहतर जानता था, उन फ़ील्ड्स को बनाए रखा, सशर्त संस्करणित राइट्स जोड़े, और संघर्ष परीक्षण और मेट्रिक्स जोड़े।"
"हमने ऑर्डर-स्टोरेज समीक्षक से डिज़ाइन को सत्यापित करने के लिए कहा और ग्रे रिलीज़ के दौरान संघर्ष दर और रोलबैक पर नज़र रखने के लिए सहमत हुए। लेखक ने छोटे पैच को स्वीकार कर लिया, और रोलआउट में कोई अन्य ओवरराइट नहीं हुआ। मैंने समीक्षा में साक्ष्य की व्याख्या की और व्यापक कैश रिफैक्टर को अलग से ट्रैक किया। बाद में, टीम ने पुल-अनुरोध टेम्पलेट में समवर्ती-राइट परीक्षण जोड़े, जिससे इसी तरह के विवाद कम हो गए।"
सामान्य गलतियाँ
- वरिष्ठता या "मानक ऐसा कहता है" का उपयोग करना → लेखक जोखिम को नहीं देख सकता → कोड पथ, साक्ष्य और स्वीकृति परीक्षण दिखाएं।
- हर टिप्पणी को ब्लॉकिंग बनाना → डिलीवरी और विश्वास प्रभावित होते हैं → जोखिम, सुझाव और पसंद को अलग करें।
- मान लेना कि लेखक गलत है → कार्यान्वयन संदर्भ छूट जाता है → पुनः जांचें और साक्ष्य बदलने पर वापस लें।
- "बाद में साफ करें" को डिफ़ॉल्ट मानना → जटिलता बनी रहती है → अभी ठीक करें या एक मालिक और समय सीमा असाइन करें।
- सार्वजनिक समीक्षा में किसी व्यक्ति का मूल्यांकन करना → असहमति संघर्ष बन जाती है → कोड, प्रभाव और अगले कदमों पर चर्चा करें।
- परिणाम मेट्रिक्स छोड़ना → प्रभावशीलता नहीं दिखाई जा सकती → परीक्षण, रोलआउट, दोष, समीक्षा समय और प्रक्रिया परिवर्तनों को रिकॉर्ड करें।
अनुवर्ती प्रश्न और उत्तर
जब आपको पता चलता है कि आप गलत थे तो आप क्या करते हैं?
लापता तथ्य बताएं, ब्लॉकर को वापस लें, और नए साक्ष्य को सार्वजनिक रूप से समझाएं। संदर्भ के लिए लेखक को धन्यवाद दें और पद का बचाव करना बंद करें; यदि यह गलती को दोहराने से रोकता है तो एक छोटा रिकॉर्ड जोड़ें।
क्या होगा यदि लेखक कहता है कि समय सीमा के लिए तत्काल मर्ज की आवश्यकता है?
मूल्यांकन करें कि क्या जोखिम शुद्धता, सुरक्षा या अनुपालन को प्रभावित करता है। एक उच्च जोखिम वाले ब्लॉकर को बनाए रखें और एक छोटे दायरे, फ़ीचर फ़्लैग, ग्रे रिलीज़ और स्पष्ट रोलबैक का प्रस्ताव करें। एक कम जोखिम वाला सुझाव एक स्वामित्व वाले, दिनांकित फॉलो-अप के साथ गैर-अवरोधक हो सकता है।
क्या होगा यदि दोनों में से कोई भी पक्ष सहमत न हो?
दावा, साक्ष्य, स्वीकार्य जोखिम और विकल्पों को लिखें। निर्णय लेने के लिए किसी डोमेन समीक्षक या तकनीकी लीड को आमंत्रित करें, फिर पुल अनुरोध में तर्क दर्ज करें ताकि भविष्य के पाठक उसी तर्क को दोबारा न खोलें।
आप समीक्षा को बाधा (bottleneck) बनने से कैसे रोकते हैं?
डिज़ाइन पर जल्दी चर्चा करें, छोटे पुल अनुरोधों को विभाजित करें, और परीक्षणों और शैली जांचों को स्वचालित करें। पहले उच्च जोखिम वाले डिज़ाइन की समीक्षा करें, फिर स्थानीय सुझावों की। आपात स्थिति के लिए, न्यूनतम समीक्षा और एक समाधान रिकॉर्ड रखें।