कोड रिव्यू से जुड़े अक्सर पूछे जाने वाले सवालों के जवाब

"कोड रिव्यू अच्छा है, यह समझ में आता है, लेकिन समय नहीं है। रिव्यू के अलावा भी बहुत काम हैं."

• कोड रिव्यू पर लेक्चर देने वाले लेखक को सबसे अधिक मिलने वाले ऊपर के सवाल का जवाब संक्षेप में

1. PR लेखक इस बात का प्रयास करे कि कोड रिव्यू में न्यूनतम समय लगे
2. जैसे रोज़ सुबह लगभग 10 मिनट की stand-up meeting होती है, वैसे ही सुबह 30 मिनट और दोपहर के भोजन के बाद 30 मिनट का तय रिव्यू समय रखें
3. गुणवत्ता और उत्पादकता:
   शुरुआत में निवेश करने से बाद में होने वाली लागत काफ़ी कम की जा सकती है, और भविष्य के बदलाव की लागत घटाकर उत्पादकता बढ़ाई जा सकती है
4. अन्य:
   अगर समय कम है, तो bug/incident जैसे गंभीर हिस्सों से ही शुरुआत करें और धीरे-धीरे दायरा बढ़ाएँ।
   रिव्यू में लगने वाले प्रयास को संगठन में उपलब्धि के रूप में मान्यता दें

"मैं चाहता हूँ कि हम कोड रिव्यू को अभी तुरंत किए जा सकने वाले growth-oriented sharing activity, और गुणवत्ता सुधार के जरिए उत्पादकता बढ़ाने के साधन के रूप में अपनाएँ."

[coremaker]

कोड review के समय को काम के समय के रूप में मान्यता देने वाली culture की ज़रूरत है.

अगर बहुत ही टाइट schedule में top-down तरीके से काम नीचे दे दिया जाए, तो इसका कोई जवाब नहीं होता. या फिर due date तय करके काम करवाया जाता है.

[cbk1411]

ऐसी कंपनियों में अक्सर कुल मिलाकर culture के top-down होने की संभावना ज़्यादा होती है.
अगर सिर्फ़ एक काम को adjust करना हो तो बदलाव अपेक्षाकृत आसान होता है, लेकिन पूरे माहौल के मामले में management को खुद तय करना पड़ता है, इसलिए यह मुश्किल होता है.

अगर workload पर चर्चा ही नहीं हो पा रही है, तो (overtime के ज़रिए समझाने की प्रक्रिया से गुज़रते हुए) culture बदलने की कोशिश कीजिए,
और अगर एक महीने बाद भी कुछ नहीं बदलता, तो किसी दूसरी team/company/industry की तलाश करना ज़्यादा efficient होता है.
उससे ज़्यादा कोशिश करेंगे, तो एक समय पर लगेगा कि आप भीतर से टूटते जा रहे हैं.

(यहाँ industry से मतलब SI, startup, और बड़े enterprise को अलग-अलग मानने का है. मुझे लगा कि इनका काम, काम करने का तरीका, और team members के बीच के संबंध पूरी तरह अलग होते हैं.)