कोड समीक्षाओं में सकारात्मक प्रतिक्रिया कितनी महत्वपूर्ण है?

Question

क्या एक कोड समीक्षा के दौरान कोड के अच्छे हिस्सों को इंगित करना महत्वपूर्ण है और किन कारणों से यह अच्छा है? सकारात्मक प्रतिक्रिया डेवलपर की समीक्षा के लिए और समीक्षा में भाग लेने वाले अन्य लोगों के लिए उपयोगी हो सकती है।

हम एक ऑनलाइन टूल का उपयोग करके समीक्षा कर रहे हैं, इसलिए डेवलपर्स अपने प्रतिबद्ध कोड के लिए समीक्षा खोल सकते हैं और अन्य किसी दिए गए समय अवधि (जैसे 1 सप्ताह) में अपने कोड की समीक्षा कर सकते हैं। अन्य लोग कोड या अन्य समीक्षक की टिप्पणियों पर टिप्पणी कर सकते हैं।

क्या सकारात्मक और नकारात्मक प्रतिक्रिया के बीच संतुलन होना चाहिए?

Comments

अरे, अगर यह गुजरता है, तो यह सकारात्मक प्रतिक्रिया है। :)

— एड्रियन जे। मोरेनो

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

— मैट

एसई में उत्थान और चढ़ाव दोनों शामिल हैं, इसलिए सकारात्मक प्रतिक्रिया चीजों को अच्छी तरह से काम करने के लिए महत्वपूर्ण होनी चाहिए। यदि यह सबसे अच्छा है कि आपके प्रश्न और उत्तर यहाँ के लिए आशा कर सकते हैं तो यह शून्य कैसे होगा? यह पुरुषों और महिलाओं का एक टकसाली अंतर है: पुरुषों के लिए, किसी भी प्रतिक्रिया का मतलब "यह ठीक नहीं है"। महिलाओं के लिए इसका मतलब है: "कहने के लिए कुछ भी अच्छा नहीं था।" यह पुरुषों और महिलाओं के लिए इस क्षेत्र के सापेक्ष आकर्षण को समझाने में बहुत लंबा रास्ता तय कर सकता है।

Answer 1

पीयर कोड का उपयोग करके गुणवत्ता और मनोबल में सुधार करें
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

सभी को क्या करना चाहिए: कोड की समीक्षा
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

इन दोनों लेखों में कहा गया है कि कोड समीक्षा का एक उद्देश्य अच्छी विकास तकनीकों के बारे में ज्ञान साझा करना है, न कि केवल त्रुटियां ढूंढना।

तो मैं कहूंगा कि यह बहुत महत्वपूर्ण है। कौन एक बैठक में जाना चाहता है और केवल आलोचना की जाती है?

Comments

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

— जिमी होफा

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

— आर्सेनी मौरज़ेंको

@ मेनमा: मेरे लिए "ठीक लग रहा है" काम करता है, अगर कोई समस्या नहीं मिली। विशेष रूप से उपयोगी या अच्छी तरह से लिखे गए कोड के लिए: "यह उपयोगी हो सकता है। आइए इसे हमारे कोड साझाकरण संग्रह में कुछ नोट्स के साथ डालें, या इसे हमारे दैनिक कोडिंग प्रथाओं में शामिल करने का प्रयास करें।"

— रॉबर्ट हार्वे

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

— ब्रायन

@ मेरे कहने का मतलब है, अगर कोई थोड़ी आलोचना पर चिल्लाता है तो वे कंपनी की संस्कृति और कार्यालय के मनोबल को पूरी तरह से खत्म करने की संभावना रखते हैं, मुझे लगता है कि आप बेहतर हैं।

— जिमी हॉफा

Answer 2

जब मैं कोड की समीक्षा करता हूं तो मेरे पास बस एक चलित एकालाप होता है, इसलिए जैसा कि मैं समझ रहा हूं कि मैं जो कुछ पढ़ रहा हूं, वह बहुत कुछ होगा "ठीक है, मैं देखता हूं कि क्या करता है .. अच्छा यह इससे जुड़ता है और कॉल करता है यह ठीक है .. और यह टुकड़ा उन दोनों पर निर्भर करता है। "

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

मुझे लगता है कि समझ का सरल हस्तांतरण दूसरे इंजीनियर की प्रशंसा है क्योंकि हम चाहते हैं कि हमारा कोड दूसरों के द्वारा समझा जाए, यह निहित मान्यता का एक रूप देता है।

उस ने कहा, यदि आप कोड के कुछ हिस्सों को देखते हैं जो अच्छी या सकारात्मक विशेषताएं हैं (यहां तक ​​कि उबाऊ तुच्छ कोड अच्छा हो सकता है यदि यह स्वयं का न्यूनतम रूप है) तो मैं निश्चित रूप से उन विशेषताओं को बताता हूं, फिर भी मैं उन्हें "वाह" के रूप में विशेषता नहीं देता हूं। महान!" "जितना मैं देख रहा हूं कि यह एक न्यूनतम कार्यान्वयन है" या "ठीक है, इस जटिल एल्गोरिथ्म में बहुत सारी टिप्पणियां हैं", कोड की विशेषताओं पर ध्यान केंद्रित करें, ऐसा नहीं है कि यह अंतर्निहित अच्छाई या खराबता है।

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

"ठीक है यह हिस्सा समझ में आता है, आह यहां एक जादू की संख्या है, उस मूल्य का अर्थ अगले इंजीनियर को छूने के लिए अच्छी तरह से नहीं समझा जा सकता है"

"मैं देख रहा हूँ कि आपको यहाँ एक DI कंटेनर मिला है ठीक है तो आप उस भंडार के साथ ढीले कपलिंग करेंगे"

"आह यहाँ एक स्थिर शब्दकोश है, अगर कई सूत्र उस शब्द को छू रहे हैं जो हम कुछ दौड़ स्थितियों में चला सकते हैं"

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

Comments

+1 के लिए "सरल समझ का हस्तांतरण दूसरे इंजीनियर की प्रशंसा है ... यह निहित मान्यता का एक रूप देता है"

— रॉय टिंकर

मैं इसे दो बार +1 करना चाहता हूं। @RoyTinker के रूप में एक ही कारण के लिए, और एक के लिए "कुछ मत कहो अच्छा या बुरा है, बल्कि कारण और प्रभाव के माध्यम से बात करें"। दोनों बहुत अच्छे अंक!

— बेन ली

Answer 3

अगर मुझे कोड समीक्षा में कुछ दिखाई दिया, जो मुझे वास्तव में पसंद आया और "अच्छा-पर्याप्त" कोड से ऊपर और परे था, तो मैं सकारात्मक प्रतिक्रिया दूंगा।

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

Answer 4

यह इतना प्रोग्रामिंग सवाल नहीं है क्योंकि यह एक सामान्य प्रबंधन और मानव-इंटरैक्शन प्रश्न है। कोड समीक्षाओं में सकारात्मक प्रतिक्रिया किसी भी प्रकार की समीक्षा में सकारात्मक प्रतिक्रिया के समान महत्वपूर्ण है।

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

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

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

Answer 5

मुझे लगता है कि सकारात्मक प्रतिक्रिया बहुत महत्वपूर्ण है और यह मुख्य रूप से एक व्यक्तिगत, रियलपोलिटिक गतिशील से है। हम सभी घंटों, दिनों, हफ्तों, महीनों के लिए बैठते हैं और कोड लिखते हैं, और हम में से अधिकांश हम क्या करते हैं पर गर्व करते हैं। कोड समीक्षाएँ दिखाने का एक मौका हैं।

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

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

Comments

यह मुझे "प्रशंसात्मक पूछताछ" नामक अवधारणा की याद दिलाता है, जो समस्याओं को हल करने पर ध्यान केंद्रित करने के बजाय पहले से ही काम करने के तरीके में सुधार और विस्तार करने के लिए दिखता है।

Answer 6

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

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

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

Answer 7

एकमात्र तरीका जो मैं सोच सकता हूं कि कोड के बारे में सकारात्मक प्रतिक्रिया प्रदान करने पर आप पर बैकफायर हो सकता है यदि आप "बैकग्राउंड तारीफ" से बचने के लिए सावधान नहीं हैं। ज्यादातर लोग इससे परिचित हैं ... यह "महान काम, लेकिन ..." जैसे वाक्यांशों से सूचित होता है।

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

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

वर्षों से मैंने जो सबसे अधिक सीखा है, वाक्यांश:

• "यह एक दिलचस्प तरीका है। अगर हमें [कुछ अन्य उपयोग मामला] समायोजित करना हो तो क्या होगा?"
• "अच्छी कोशिश! क्या आप जानते हैं कि हमारे पास ऐसा करने के लिए पहले से ही एक विधि है? हो सकता है कि हमें यह देखने के लिए कुछ बेंचमार्किंग करनी चाहिए कि कौन सा दृष्टिकोण अधिक कुशल है।"

Answer 8

कोड समीक्षाएँ के साथ जो वर्कफ़्लो मुझे सबसे ज्यादा पसंद आया वह यह था:

1. देव मेलिंग सूची / ऑनलाइन टूल पर पैच को सबमिट करता है।
2. हर किसी को देखभाल करने की आवश्यकता है जो पैच को देखता है, सुधार का सुझाव देता है।
3. देव # 1 पर वापस जाता है
4. यदि कोई सुधार की आवश्यकता नहीं है, तो लोग कहते हैं "अच्छा काम, कृपया प्रतिबद्ध करें।" <- सकारात्मक प्रतिक्रिया। स्वीकार किया गया सभी कोड अच्छा है। कम लोगों को आपको चीजों को बदलने के लिए कहना होगा, जो आप बेहतर कर रहे हैं।
5. देव कमिट करते हैं, अगले आइटम पर जाते हैं।

आमतौर पर क्या होता है कि नए देवों को कोडबेस से परिचित होने के साथ-साथ बहुत अधिक 'सुधारात्मक' प्रतिक्रिया मिलती है।

इस दृष्टिकोण के लाभ हैं:

1. हर कोई जानता है कि हर कोई क्या कर रहा है। कोई एकाधिकार या रहस्य नहीं है।
2. हर कोई दूसरे की प्रतिक्रिया से सीखता है। यह महत्वपूर्ण है। यदि युग्मन करते समय आमने-सामने की बातचीत में केवल 2 लोगों के बीच प्रतिक्रिया होती है, तो कमरे के दूसरी तरफ किसी को भी उसी तरह से लाभ नहीं होता है, जैसा कि मेलिंग सूची में हुआ था।
3. अन्य देवता आमतौर पर संस्करण नियंत्रण में होने से पहले कुछ कीड़े देख सकते हैं।

Comments

इसलिए, मूल रूप से, आप कोई प्रतिक्रिया नहीं मिलने की उम्मीद कर रहे हैं। काम पर जाने से क्यों परेशान? आप घर पर अदृश्य हो सकते हैं।

Answer 9

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

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

आपके पास उन लोगों के साथ भी समस्याएँ होंगी, जिन्हें कोई सकारात्मक प्रतिक्रिया नहीं मिलती है, शायद वे बहुत मेहनत कर रहे हैं और अंततः गड़बड़ कर रहे हैं "मुझ पर विश्वास करो, यह काम करता है।"

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

बैकस्लैपिंग को पब पर छोड़ दें।

Comments

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

— एक CVn

Answer 10

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

Answer 11

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

Comments

मेरा अनुभव यह है कि प्रोग्रामर जो कठिन प्रयास करते हैं, वे 'अच्छे लोग' हैं और एक सहायक टीम के साथ खुश हैं जो सॉफ्टवेयर लिखने का काम करती है।

— c_maker

चिकन और अंडा मुझे लगता है। लेकिन सवाल कोड समीक्षा के बारे में था ... जो मुझे नहीं लगता कि अहंकार को आघात

— पहुंचाने

कोड समीक्षा यह निर्धारित करने का समय नहीं है कि सॉफ्टवेयर के उपयोगकर्ता-दृश्यमान हिस्से कल्पना के अनुसार काम करते हैं या नहीं।

— एक CVn

Answer 12

मुझे लगता है कि पूरी तरह से उद्देश्यपूर्ण होना महत्वपूर्ण है। सकारात्मक टिप्पणी करके मनोबल बढ़ाने का प्रयास करना मेरे दिमाग में समय की बर्बादी है।

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

यदि आपको कोई टिप्पणी नहीं मिलती है तो आप विचार कर सकते हैं कि आपने अच्छा काम किया है।

Comments

शायद इसीलिए ज्यादातर प्रोग्रामर पुरुष होते हैं।

Answer 13

मंत्र सरल है: यदि कोई गुणवत्ता कोड चाहता है (जो वास्तविकता में कम है) तो उचित समीक्षा विधियों का अभ्यास किया जाना चाहिए। यह कहने के बाद, सकारात्मक प्रतिक्रिया एक डेवलपर / प्रोग्रामर को विचारों / समाधानों / सुधारों के साथ आने और सोचने में मदद करती है। बहुत कठोर मत बनो, लेकिन इस बिंदु पर दृढ़ रहो। प्रश्नोत्तर प्रबंधक को अच्छी कार्यप्रणाली और प्रथाओं के बारे में पता होना चाहिए ताकि वह सही दिशा में टीम (या सदस्य) का मार्गदर्शन कर सके। इससे गुणवत्ता में सुधार होता है। अवधि।

Answer 14

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

हालांकि, आप कार्यस्थल के माहौल में बात करते दिखते हैं, जहां कोड को फिर से लिखा जा सकता है। जिस स्थिति में, आप अपने सिस्टम से नरक को प्राप्त करने की कोशिश कर रहे हैं। तो, उस स्थिति में, केवल नकारात्मक कीड़े किसी भी मूल्य के होते हैं।

यदि आप इसके बारे में असहज महसूस करते हैं, तो एक साप्ताहिक कोड समीक्षा बैठक करें, जहां हर कोई अच्छे कोड और बुरे कोड दोनों पर चर्चा कर सकता है।

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

Comments

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

— Mat

मेरी ओर से खराब शब्द पसंद। जबकि अच्छा सामान बेकार नहीं है (मेरे समय में पर्याप्त सकल लिखा है), कीड़े हैं, सबसे अधिक संभावना है, ट्रैकर के लिए क्या निर्धारित किया गया था। ओपी कर सकता है, अगर वह ऐसा करता है, तो सकारात्मक टिप्पणी छोड़ दें। लेकिन, व्यक्तिगत रूप से, मैं इसे आमने-सामने बातचीत के लिए छोड़ दूंगा, क्योंकि यह ट्रैकर को बंद होने से रोकता है। इसके अलावा, मैं बहुत नाराज हूं मैं टिप्पणी नहीं कर सकता। :)

— केबीकर्मा

@KBKarma - यदि आपको लगता है कि आपका मूल उत्तर सही नहीं था और साथ ही साथ यह हो भी सकता है, तो कृपया वापस जाएँ और अपने उत्तर को ठीक से अपने विचारों को प्रतिबिंबित करने के लिए संपादित करें। अपने उत्तर के नीचे संपादित करें बटन को देखें।