कोड समीक्षाएं अक्सर विवाद का कारण बनती हैं। ऑल्टरकॉन्फ़ सम्मेलन में "हम कोड रिव्यू में विषाक्त व्यवहार से अनजान हैं" व्याख्यान की तैयारी में , मैं आपत्तियों और आलोचनाओं का एक समूह सुनने के लिए तैयार था। लेकिन उसने समुदाय से इस विचार के समर्थन की अपेक्षा नहीं की थी। मैंने प्रतिरोध मान लिया, लेकिन समुदाय ने बहुत अच्छी तरह से मुझे प्राप्त किया और अनुमोदित किया।

मुझे स्लाइड्स को साझा करने के लिए कहा गया था, लेकिन अब मुझे लगा कि स्लाइड्स का उपयोग बहुत कम था और इसे संदर्भ से बाहर ले जाया गया: उनके पास स्पष्टीकरण की कमी है। इसलिए, मैंने इस लेख को प्रकाशित करने का निर्णय लिया। बाद में, सम्मेलन के आयोजकों ने एक वीडियो अपलोड किया।

नीचे सूचीबद्ध कुछ प्रकार के अनुत्पादक कोड समीक्षा व्यवहार और सिफारिशें हैं कि कैसे प्रक्रिया को अधिक अनुकूल बनाया जाए और विषाक्तता को खत्म किया जाए। सभी व्यवहार मॉडल का परीक्षण मेरे द्वारा या मेरे द्वारा ज्ञात कंपनी में किया गया है। अतीत में, ऐसे पाप मेरे लिए भी लाए गए थे।

अनुत्पादक व्यवहार नंबर 1: एक तथ्य के रूप में राय का संचार करना

यदि आप इन बयानों के समर्थन में प्रलेखन, औपचारिक सिफारिशों और कोड उदाहरणों का उल्लेख नहीं कर सकते हैं, तो बयान न करें। लोगों को पता होना चाहिए कि उन्हें बदलाव करने के लिए क्यों कहा जा रहा है, और किसी अन्य डेवलपर की व्यक्तिगत प्राथमिकताएं एक अच्छा पर्याप्त तर्क नहीं हैं।

कहने के बजाय:

इस घटक को स्टेटलेस बनाया जाना चाहिए।

... कुछ संदर्भ प्रदान करना बेहतर है:

चूंकि इस घटक में जीवनचक्र या राज्य विधियां नहीं हैं, इसलिए इसे स्टेटलेस बनाया जा सकता है। इससे कोड प्रदर्शन और पठनीयता में सुधार होगा। * यहाँ - कुछ प्रलेखन।

एक तथ्य के रूप में राय का स्थानांतरण अक्सर शैली और वाक्यविन्यास की चर्चाओं में पाया जाता है। ये वास्तव में महत्वपूर्ण विषय हैं, लेकिन कोड समीक्षाओं के लिए नहीं, क्योंकि स्टाइल और सिंटैक्स का उस समस्या से कोई लेना-देना नहीं है जिसे डेवलपर शुरू में हल करता है।

इस तरह की चर्चाओं को अलग से आयोजित करना और पूरी टीम के लिए शैली निर्धारित करना बेहतर है। लाइनर और स्वचालित कोड सुधारों को लागू करें। फिर आप अपनी व्यक्तिगत राय नहीं बल्कि इन शैली सिफारिशों का उल्लेख करेंगे।

यह एक टीम या कंपनी में एक उच्च पद और अधिकार होने पर एक तथ्य के रूप में अपनी राय नहीं देने के लिए विशेष रूप से महत्वपूर्ण है। डेवलपर की धारणा है कि उसके पास आपकी आवश्यकताओं को पूरा करने के अलावा कोई विकल्प नहीं है।

अनुत्पादक व्यवहार # 2: टिप्पणियों का हिमस्खलन

जब कोई व्यक्ति गलती करता है, तो एक अच्छा मौका है कि यह त्रुटि कई स्थानों पर होती है। मैंने देखा कि समीक्षक कभी-कभी उपयोगी संसाधनों के लिंक के साथ एक विस्तृत नोट छोड़ने के बजाय प्रत्येक मामले को इंगित करते हैं।

टिप्पणियों का समेकन आपको लेखक को दबाने के बिना एक ही संदेश भेजने की अनुमति देता है। एक मुद्दे पर डुप्लिकेट टिप्पणियों का एक हिमस्खलन नाइटपैकिंग की तरह दिखता है।

अनुत्पादक और भारी:



एक आवर्ती त्रुटि के लिए एकाधिक टिप्पणियां (पंक्ति के अंत में रिक्त स्थान)

एक अधिक उपयोगी विकल्प:


समेकित प्रतिक्रिया

मैं समझ सकता हूं कि कभी-कभी यह त्रुटि के हर स्थान पर इंगित करने के लिए उपयोगी होता है, क्योंकि टिप्पणी बाद में सही होने पर गायब हो जाती है। लेकिन अगर त्रुटि कई बार होती है, तो यह स्पष्ट है कि डेवलपर को एक विशिष्ट मार्गदर्शिका के बारे में पता नहीं था, और उसे सही संसाधनों को इंगित करना चाहिए।

अनुत्पादक व्यवहार नंबर 3: इंजीनियरों को अन्य लोगों की समस्याओं को हल करने के लिए कहें, "जब वे यहां हैं"

डेवलपर्स को उन समस्याओं से निपटने के लिए नहीं कहेंगे जो सीधे परिवर्तन के सेट से संबंधित नहीं हैं या समस्या जो इस कोड को हल करने की कोशिश कर रही है। यहां तक ​​कि अगर कोई डेवलपर खराब प्रथाओं की बहुतायत के साथ गंदे कोड का विस्तार या संशोधन करता है, तो उसे इस अजीब कोड को साफ करने और ठीक करने के लिए न कहें।

मैं डेवलपर्स को कोड के लिए जिम्मेदारी से वंचित करने का प्रस्ताव नहीं करता हूं क्योंकि उन्होंने शुरुआत में इसे नहीं लिखा था। वास्तव में, "किसी और का कोड मेरी समस्या नहीं है" ऐसा कुछ कहना अच्छा नहीं है। एक अलग टिकट बनाने और गंदे कोड को ठीक करने के लिए अनुरोध को खींचने के लिए यह अधिक उपयुक्त है। इस प्रकार, आप किसी के काम की मात्रा में तेज वृद्धि से बचते हैं, तकनीकी ऋण के साथ समस्या को हल करते हैं।

टीएल; डीआर : डेवलपर को समस्याओं को ठीक करने के लिए नहीं कहेंगे "जब वे यहां हैं।" यदि कोड वह करता है जो टिकट में आवश्यक है और कोड आधार में नई समस्याओं को पेश नहीं करता है, तो इसे अनुमोदित करें, और फिर कोड आधार को खाली करने के लिए टिकट बनाएं।

अनुत्पादक व्यवहार # 4: निंदा प्रश्न पूछें

इस तरह की निंदा करने वाले सवाल पूछने से बचें:

आपने यहां सिर्फ ____ क्यों नहीं किया?

इसका मतलब यह है कि कुछ सरल समाधान स्पष्ट होना चाहिए। यह डेवलपर को अपना बचाव करने के लिए मजबूर करता है।

अक्सर ये निंदा करने वाले सवाल सीधे तौर पर मांगे गए होते हैं। इसके बजाय, कठोर शब्दों को छोड़ते हुए एक सिफारिश (प्रलेखन और लिंक के साथ) प्रदान करें।

आप ____ कर सकते हैं, जिसमें ____ का लाभ है।

अनुत्पादक व्यवहार संख्या 5: सारभूत

समीक्षाओं में व्यंग्य के लिए कोई जगह नहीं है। एक नियम के रूप में, व्यंग्यात्मक टिप्पणियां संदर्भ और प्रभावी प्रतिक्रिया प्रदान नहीं करती हैं। इसके बजाय, समस्या का विस्तार से वर्णन करें और सिफारिशें प्रदान करें, लेकिन कास्टिक चुटकुले छोड़ दें।

उल्टा:

क्या आपने सबमिट करने से पहले इस कोड का परीक्षण भी किया है?

यह उपयोगी है:

ऋणात्मक संख्या दर्ज करने में विफलता। क्या आप ऐसा कर सकते हैं?

यहाँ एक कोड की समीक्षा में एक और उदाहरण टिप्पणी है जो न तो हास्यास्पद है और न ही उपयोगी है:

हम दुष्ट नहीं हैं, हम निर्दयी हैं। जैसा कि आप देख सकते हैं, मैंने लिखा "बीप!" - आपके द्वारा स्पर्श की जाने वाली प्रत्येक फ़ाइल को आयात करने पर। मुझे निम्नलिखित बातों का ध्यान रखना था: "आपका आयात हमारे मानक सम्मेलन का उल्लंघन करता है, जो एक निश्चित क्रम को निर्धारित करता है: पहला, बिल्ट-इन मॉड्यूल, फिर तीसरा-पक्ष और फिर परियोजना स्तर," लेकिन यह वाक्यांश प्रत्येक मामले में टाइप किए जाने के लिए बहुत लंबा है।

उपरोक्त उदाहरण में, "बीप!" - पूरी तरह से उपयोगी और सार्थक नहीं। यह पांडित्य हास्य है जो लेखक की मदद नहीं करता है।

अनुत्पादक व्यवहार # 6: समस्या का वर्णन करने के बजाय इमोजी

कोड में समस्याओं को इंगित करते समय, बीमार आदमी के साथ अंगूठे या इमोजी के साथ इमोटिकॉन्स से बचें। यह उतने ही बेकार है, उतने ही कारणों से। इमोजी रहस्यमय हैं, गलत व्याख्या करना आसान है। लोग आपके विचारों को समझने के लिए समय बर्बाद कर रहे हैं।


कोडिंग समस्याओं को इंगित करने के लिए इमोजी का उपयोग न करें

किसी भी मामले में, आपको प्रोग्रामिंग त्रुटियों के लिए भावनात्मक प्रतिक्रिया नहीं होनी चाहिए।

सकारात्मक इमोटिकॉन्स, जैसे "अंगूठे ऊपर" या "चीयर्स!" का उपयोग करना काफी सामान्य है, लेकिन समस्याओं को इंगित करने के लिए नहीं, बल्कि एक अच्छे कोड की प्रतिक्रिया के रूप में।


स्वीकृत इमोटिकॉन्स महान हैं

अनुत्पादक व्यवहार # 7: सभी टिप्पणियों का जवाब न दें

लेखक भी चर्चा की विषाक्तता में योगदान करते हैं। यदि आप सभी टिप्पणियों का जवाब दिए बिना कोड को जोड़ते हैं, तो यह व्यक्ति के लिए आश्चर्य की बात है: उसने आपकी मदद करने की कोशिश की, और आप यह स्पष्ट करते हैं कि कुछ समीक्षा कोई फर्क नहीं पड़ता।

यदि टिप्पणी अप्रासंगिक है या आप कार्रवाई नहीं करेंगे, तो बस संक्षेप में बताएं कि क्यों।

सहकर्मियों की उपेक्षा न करें।


एक टिप्पणी के जवाब के बिना कोड का संयोजन

अनुत्पादक व्यवहार # 8: यदि शीर्ष पेशेवरों से आता है तो विषाक्त व्यवहार की उपेक्षा करना

विषाक्त व्यवहार को नजरअंदाज नहीं किया जाना चाहिए या कम करके आंका जाना चाहिए क्योंकि डेवलपर एक उत्कृष्ट पेशेवर और एक अत्यंत उत्पादक कर्मचारी है। यद्यपि वह एक शानदार काम करता है, लेकिन यह ध्यान रखना महत्वपूर्ण है कि उसके विषाक्त व्यवहार से अन्य डेवलपर्स के तनाव और जलन होती है।

विषाक्त व्यवहार प्रदर्शित करने वाले व्यक्ति के साथ अनुभव करें:

दूसरों को यह पता चलेगा कि इस व्यक्ति के साथ काम करना कम हो जाता है और गिर जाता है। वे उसके साथ बातचीत करने से बचने के लिए कुछ भी करेंगे, भले ही यह कार्य करने की उनकी क्षमता को नकारात्मक रूप से प्रभावित करता हो। पूरे संगठन में संचार बाधित हो जाएगा, और कर्मचारी अन्य स्थानों पर नौकरियों की तलाश करने लगेंगे। जब आप एक प्रतिभा रिसाव और असफल परियोजनाओं के परिणामों का सामना करते हैं, तो यह विशेष डेवलपर चुपचाप काम करना जारी रखेगा जैसे कि कुछ भी नहीं हुआ था। - जोसेफ गेफरो

यदि स्थिति को सुधारने के लिए कदम नहीं उठाए गए हैं, तो गंभीर परिणाम संभव हैं: डेवलपर्स को अधिभारित किया जाएगा, हमला किया जाएगा और ध्वस्त किया जाएगा। वे प्रतिक्रिया से डरना शुरू कर देंगे, जो वास्तव में उन्हें बढ़ने में मदद करनी चाहिए।

जब भी मुझे एक पूर्व सहकर्मी (अपने जहरीले, बेवजह की समीक्षा के लिए जाना जाता है) से मेरे अनुरोध पर टिप्पणियों के साथ एक ईमेल प्राप्त हुआ, तो मैंने व्यक्तिगत रूप से बहुत चिंतित महसूस किया। हालांकि विषाक्त व्यवहार हर किसी को अलग तरह से प्रभावित करता है, लेकिन निश्चित रूप से इस विषाक्तता से कोई भी लाभ नहीं होता है।

नोट : मैं यह स्पष्ट करना चाहता हूं कि यदि डेवलपर विरोध नहीं कर सकता है और एक बार ऐसा व्यवहार दिखाया गया है, तो यह उसे "विषाक्त" नहीं बनाता है। हम बार-बार अपमान और कास्टिक टिप्पणियों के बारे में बात कर रहे हैं।

उपयोगी कोड समीक्षा अभ्यास

नीचे कुछ सिफारिशें दी गई हैं जो किसी भी सामान्य संचार पर लागू होती हैं, हालांकि यहां हम प्रोग्रामिंग और कोड समीक्षाओं के संदर्भ में बोलते हैं।

उपयोगी व्यवहार # 1: संवाद बनाने के लिए प्रश्नों या सिफारिशों का उपयोग करें

कभी भी लोगों से सुधार करने के लिए न कहें या निराशाजनक सवाल न पूछें, क्योंकि यह आपके और दूसरे व्यक्ति के बीच संवाद में बाधा उत्पन्न करता है।

आपने लगातार इन रूपांतरणों को एक फ़ाइल में स्थिरांक के साथ क्यों नहीं जोड़ा?

औपचारिक रूप से, यह एक सवाल है, लेकिन यह आपके और वार्ताकार के बीच संवाद नहीं बनाता है। वह सिर्फ उसका बचाव करता है। इसके बजाय, पूछें कि दूसरा व्यक्ति आपके फैसले के बारे में क्या सोचता है:

आप इन रूपांतरणों को एक स्थिर फ़ाइल में खींचने के बारे में क्या सोचते हैं? उनमें से बहुत सारे हैं, इसलिए एक अलग फ़ाइल इस समय अच्छी तरह से समझ सकती है।

... या सिफारिश करें:

इस फ़ाइल में आपके पास "फ़ंक्शन x" के लिए कई अनुवाद कॉल हैं। यह अपने स्थिरांक के साथ एक अलग फ़ाइल बनाने के लिए समझ में आ सकता है।

उपयोगी व्यवहार # 2: सहयोग करें, छिपाएँ नहीं

जब आप एक साथ कार्यक्रम करते हैं, तो आपको आस-पास रहना होगा, सवाल पूछना, चर्चा करना और संसाधनों की ओर इशारा करना होगा।

"... जब आप मदद करना चाहते हैं या एक साथ काम करना चाहते हैं, तो आपको पूरी तरह से शामिल होना चाहिए, न कि कभी-कभी हस्तक्षेप करना चाहिए" - पुनर्खरीद केंद्र गाइड

उपयोगी व्यवहार # 3: प्रत्येक टिप्पणी का जवाब

यदि आप एक लेखक के रूप में एक समीक्षक की सलाह को लागू करने की योजना नहीं बनाते हैं, तो केवल रिपोर्ट करके एक नोट करें। उन लोगों को नजरअंदाज न करें जो आपकी मदद के लिए समय निकालते हैं।

उदाहरण के लिए:

व्यक्ति ए: - आप इस एपीआई कॉल के लिए एक सहायक समारोह बनाने के बारे में क्या सोचते हैं? नहीं तो सब ठीक है।

व्यक्ति बी: - यह लाइन मेरे बदलाव का हिस्सा नहीं थी। मैं कोड को जोड़ूंगा, गिटहब पर एक अलग टिकट बनाऊंगा और इसे हमारे समूह के लिए कार्य योजना में लिखूंगा।

उपयोगी व्यवहार # 4: यह जानना कि कब आमने-सामने की बैठक की व्यवस्था करना है

दर्जनों टिप्पणियों और प्रस्तावित समाधानों के बाद, यह स्पष्ट होना चाहिए कि ऑनलाइन संचार हाथ में समस्या के लिए अनुत्पादक हो गया है। अपने सभी सहयोगियों को एक बैठक का निमंत्रण भेजें।

इस प्रकार, समूह जल्दी से निर्णय लेने और इसे लागू करने में सक्षम होगा।

समस्याएँ जो घंटों और टन के टिप्पणियों को लेती हैं उन्हें आमतौर पर कुछ मिनटों की उत्पादक बातचीत में हल किया जा सकता है। - "नीट जावा"

उपयोगी व्यवहार # 5: सीखने के अवसरों का उपयोग करें और दिखावा न करें

कोड समीक्षा में भाग लेने से पहले, अपने आप से पूछें:

क्या आपकी टिप्पणी वास्तव में आपको सीखने में मदद करती है या आप गलती ढूंढ रहे हैं?

अपनी टिप्पणी के बारे में सोचें। याद रखें कि एक कोड समीक्षा का लक्ष्य अन्य डेवलपर्स को विकसित करने में मदद करना है। यह प्रदर्शन का मंच नहीं है।

उपयोगी व्यवहार # 6: आश्चर्य न दिखाएं

अगर कोई व्यक्ति कुछ नहीं जानता है तो आश्चर्यचकित न होने के लिए सावधान रहें। लोगों को परेशान न करें कि उन्हें पहले से ही इसकी जानकारी होनी चाहिए। इसके विपरीत, यह स्वीकार करने के लिए स्वतंत्र महसूस करें कि आपके पास विषय पर अनुभव की कमी है - यह मदद मांगने का एक शानदार तरीका है।

अधिक जानकारी के लिए पुनरावृत्ति केंद्र ट्यूटोरियल में " डोंट प्रिटेंड सरप्राइज़" नियम देखें।

उपयोगी व्यवहार # 7: स्वचालित सब कुछ आप कर सकते हैं

यह उन कीड़े पर चर्चा करने के लिए बहुत कम समझ में आता है जिन्हें लिंटर, गिट हुक या स्वचालित परीक्षणों द्वारा पकड़ा जा सकता है। यह अतिरिक्त टिप्पणियों का एक टन है जो नाइटपैकिंग की तरह दिखता है। लोग ऐसी त्रुटियों की पहचान करने में बहुत अच्छे नहीं हैं, और इसलिए स्वचालन उपकरण बनाए गए हैं।

नया कोड जोड़ते समय स्वचालित रूप से परीक्षण चलाने के लिए उपकरण भी हैं। यदि परिवर्तन का एक सेट परीक्षण का उल्लंघन करता है तो वे चेतावनी प्रदर्शित करते हैं। उदाहरण के लिए, टीमसिटी और जेनकिंस सीआई।

इसके अलावा, नए कोड पर परीक्षण और लिंटर चलाने के लिए Git हुक का उपयोग करें। यदि वे बग ढूंढते हैं तो वे प्रतिबद्ध करेंगे।

उपकरण को समस्याओं को इंगित करने दें, ताकि लोगों को न करना पड़े।

उपयोगी व्यवहार # 8: जहरीले व्यवहार से पीछे न हटें

आपके कोड की समीक्षा में विषाक्त व्यवहार को अपनाने की कोई आवश्यकता नहीं है, क्योंकि यह नए डेवलपर्स के लिए बदला लेने या कुछ हेकिंग अनुष्ठान जैसा दिखता है।

सहकर्मियों का पता लगाएं जो आपका समर्थन करेंगे।

यदि आप अनुत्पादक कोड समीक्षाओं को नोटिस करते हैं, तो एक सहकर्मी को बताने की कोशिश करें, सीधे और ईमानदारी से बोलें (यदि आप अपनी स्थिति या कंपनी में सुरक्षित महसूस करते हैं)।

उपयोगी व्यवहार नंबर 9: प्रबंधक, उम्मीदवारों पर ध्यान से विचार करें, टीम को सुनें और अपने अधिकार का उपयोग करें

प्रबंधकों के पास टीम में सकारात्मक और अनुकूल माहौल बनाने के लिए बहुत अच्छे अवसर हैं।

हम "विषैले डेवलपर्स के हानिकारक" लेख से युक्तियों को दोहराते हैं :

• जहरीले डेवलपर्स को टीम में आने से रोकें। काम पर रखने पर, न केवल तकनीकी प्रशिक्षण पर ध्यान दें। पता करें कि उम्मीदवार कैसे सहयोग करता है और संचार करता है। गंभीर रूप से उसके काम का विश्लेषण करें और देखें कि वह कैसे प्रतिक्रिया करता है। सुनिश्चित करें कि प्रत्येक उम्मीदवार कंपनी की संस्कृति में सुधार करता है, और न केवल उसमें फिट होता है।
  
• जब एक विषैले विकासकर्ता अभी भी राज्य में आ गए हैं या विरासत में मिले हैं, तो प्रत्येक कर्मचारी से व्यक्तिगत बातचीत में इस बारे में राय मांगें। यदि डेवलपर विषाक्त है, तो यह उसके बारे में समीक्षाओं में पॉप अप करेगा।
  
• जहरीले डेवलपर से बात करें। एक कोड समीक्षा में प्रभावी टिप्पणियों के विशिष्ट उदाहरण दें। लगातार उसके साथ काम करते हैं, अपने सहयोगियों और प्रबंधक के साथ व्यक्तिगत बातचीत में जानकारी एकत्र करना जारी रखते हैं।
  
• विषाक्त डेवलपर को अलग न करें। (*)
  
• अनुकूल वातावरण की आवश्यकता के बारे में कर्मचारियों को दोहराएं।

(*) यद्यपि लेख विषैले डेवलपर्स को अलग करने का प्रस्ताव करता है, मैं विषाक्त डेवलपर को टीम के साथ काम करने के लिए प्रोत्साहित करना महत्वपूर्ण मानता हूं, लेकिन अधिक स्वस्थ तरीकों से। इन्सुलेशन समस्या का समाधान नहीं करेगा। यदि आप इसे एक अलग नौकरी देते हैं, तो अल्पावधि में विषाक्तता कम हो जाएगी, लेकिन डेवलपर अपने अनुत्पादक व्यवहार को नहीं देगा। वह इसे प्रदर्शित करने के लिए केवल पोडियम खो देगा।

उपयोगी व्यवहार # 10: टीम के छोटे और बढ़ने पर मानक सेट करें

छोटी टीमें नए विचारों को स्वीकार करने और उन्हें लागू करने में सक्षम हैं। भले ही आप मानकों को निर्धारित करने के लिए आवश्यक नहीं मानते हैं, क्योंकि अब कोई समस्या नहीं है, लेकिन जब पुनरावृत्ति आती है तो अच्छी सहयोग प्रथाओं को बनाए रखना महत्वपूर्ण है।

उपयोगी व्यवहार # 11: समझें कि आप समस्या का हिस्सा हो सकते हैं

अधिक अनुकूल वातावरण बनाने के लिए, अपने आप के साथ ईमानदार होना और किसी भी अप्रभावी व्यवहार को प्रतिबिंबित करना महत्वपूर्ण है।

एक जूनियर के रूप में, मैंने किसी के कोड में कई बार गलती देखी और खुश था, क्योंकि मैं एक टिप्पणी छोड़ सकता था! अब मैं समझता हूं कि मैंने इस अवसर का उपयोग किया, और मदद करने के लिए नहीं। आपको अपने कार्यों का सावधानीपूर्वक मूल्यांकन करने की आवश्यकता है।

मुझे लगता है कि इस कठिन आत्मनिरीक्षण के लिए समय निकालना सभी के लिए उपयोगी है।

और आखिरी ...

हम समीक्षाओं की सामग्री के बारे में बात नहीं कर रहे हैं, लेकिन केवल टोन के बारे में

मुझे पता है कि समीक्षा महत्वपूर्ण है, और हम उनके खिलाफ नहीं लड़ रहे हैं। मैं आपको कोड की गुणवत्ता से समझौता करने के लिए नहीं कहता। कोड की समीक्षा की उदार संस्कृति और कोड की उच्च गुणवत्ता परस्पर अनन्य नहीं होनी चाहिए।

मैं बस आशा करता हूं कि लोग रचनात्मक, प्रभावी प्रतिक्रिया प्रदान करने के लिए कदम उठाएंगे और अधिक अनुकूल परिस्थितियां बनाएंगे, जिसमें डेवलपर्स सहज महसूस करेंगे, सीखेंगे, बढ़ेंगे और गलतियाँ करने से डरेंगे नहीं। हम सब मिलकर सुधार कर सकते हैं।