आप अपनी टीम से क्वालिटी की क्या कसौटी चाहते हैं, और उसे कैसे लागू करते हैं?

कसौटी एक जैसे नियम से नहीं, जोखिम से तय कीजिए। तय कीजिए कि कोड शिप होने से पहले क्या सच होना चाहिए (ऐसे tests जो असल में होने वाली नाकामियां पकड़ें, ऐसे व्यक्ति का review जो सच में चुनौती दे सके, नए रास्ते पर instrumentation, और वापस लौटने का लिखा हुआ रास्ता) और उसका जितना हो सके उतना पाइपलाइन में ऑटोमेट कीजिए। code review में टोकने की जगह डिफ़ॉल्ट और ऑटोमेशन से लागू कीजिए।

मैं इसे blast radius से तय करता हूं। payments रास्ते का बदलाव और मार्केटिंग पेज का बदलाव एक जैसी रस्म के हकदार नहीं हैं, और दोनों पर एक ही मानक लगाने का मतलब है कि आप या तो सब कुछ धीमा कर देंगे या वहां जलेंगे जहां असल में मायने रखता है। जो चीज़ मायने रखती है उसके लिए मेरी चेकलिस्ट है ऐसे tests जो सच में होने वाली नाकामी पकड़ें, coverage प्रतिशत का नाटक नहीं, ऐसा reviewer जो उस इलाके को इतना समझता हो कि असहमत हो सके, नए रास्ते पर instrumentation ताकि हम उसे प्रोडक्शन में देख सकें, और वापस लौटने का लिखा हुआ रास्ता। फिर मैं उसका जितना हो सके उतना पाइपलाइन में धकेलता हूं, क्योंकि जो मानक इंसानों के review में याद रखने पर टिके हैं वे महीने भर में सड़ जाते हैं। lint, test gates, migration जांचें, template में ज़रूरी rollback नोट। जब कोई सीनियर इसके इर्द गिर्द रास्ता निकाले तो मैं उसे उस व्यक्ति के बारे में नहीं, मानक के बारे में बातचीत मानता हूं, क्योंकि आमतौर पर उनके पास असली वजह होती है और मानक ही गलत होता है। अगर बिना वजह दो बार ऐसा हो, तो वह प्रोसेस की नहीं, परफॉर्मेंस की बातचीत है।