कोड समीक्षा में सकारात्मक चीजें कैसे ढूंढें?


184

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

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

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

तकनीकी रूप से हम मर्ज से इनकार कर सकते हैं, इसे विकास को वापस दे सकते हैं। वास्तव में यह लगभग हमेशा हमारे बॉस के साथ समाप्त होता है और यह मांग करता है कि इसे समय पर भेज दिया जाए।

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

वर्तमान में विकास एसवीएन में विकास शाखाओं में किया जाता है, डेवलपर के सोचने के बाद कि वह तैयार है, वह हमारे टिकट प्रणाली में हमारे प्रबंधक को टिकट पुन: सौंपता है। प्रबंधक इसके बाद हमें इसे सौंपता है।

कोड समीक्षाओं से हमारी टीम के भीतर कुछ तनाव पैदा हुए हैं। विशेष रूप से पुराने सदस्यों में से कुछ बदलावों पर सवाल उठाते हैं (यानी "हमने हमेशा इसे इस तरह किया था" या "विधि में एक समझदार नाम क्यों होना चाहिए, मुझे पता है कि यह क्या करता है?")।

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

दूसरी ओर, मैं अब प्रतिबद्ध कोड के साथ समस्याओं को इंगित करने के लिए एक गधा होने के लिए जाना जाता हूं।

मुझे नहीं लगता कि मेरे मानक बहुत अधिक हैं।

इस समय मेरी चेकलिस्ट है:

  • कोड संकलित करेगा।
  • कम से कम एक तरह से कोड काम करेगा।
  • कोड सबसे सामान्य मामलों के साथ काम करेगा।
  • कोड अधिकांश किनारे मामलों के साथ काम करेगा।
  • यदि सम्मिलित डेटा मान्य नहीं है तो कोड उचित अपवाद को फेंक देगा।

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

मेरे पास जो कमी है, वह है कुछ को "अच्छे" के रूप में इंगित करने की क्षमता। मैंने पढ़ा कि अच्छी खबर में बुरी खबर को सैंडविच करने की कोशिश करनी चाहिए।

लेकिन मुझे कुछ ऐसा करने के लिए कठिन समय मिल रहा है जो अच्छा है। "अरे इस बार आपने वास्तव में जो कुछ भी किया है वह अच्छा या मददगार है।"

उदाहरण कोड की समीक्षा

हे जो,

लायब्रेरी \ ACME \ ExtractOrderMail क्लास में आपके परिवर्तनों के बारे में मेरे कुछ प्रश्न हैं।

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

... (कुछ अन्य बिंदु जो काम नहीं करते हैं)

छोटे बिंदु:

  • "GetErrorMailBody" पैरामीटर के रूप में एक अपवाद क्यों लेता है? क्या मैं कुछ भुल गया? आप अपवाद को फेंक नहीं रहे हैं, आप बस इसे पास करते हैं और "ToString" कहते हैं। ऐसा क्यों है?
  • SaveAndSend विधि के लिए एक अच्छा नाम नहीं है। यदि मेल की प्रोसेसिंग गलत हो जाती है तो यह विधि त्रुटि मेल भेजती है। क्या आप इसे "SendErrorMail" या कुछ इसी तरह का नाम दे सकते हैं?
  • कृपया पुराने कोड पर टिप्पणी न करें, इसे एकमुश्त हटा दें। हमारे पास अभी भी यह तोड़फोड़ है।

8
कृपया बुरे और अच्छे के कुछ पौराणिक संतुलन को प्राप्त करने के लिए $ h! T सैंडविच की सेवा न करें। अगर उन्होंने कुछ अच्छा किया है तो उन्हें बताएं, अगर उन्होंने ऐसा कुछ किया है जिसमें सुधार की आवश्यकता है तो उन्हें बताएं। अच्छे और बुरे का मेल संदेश को पतला करता है। यदि उन्हें सकारात्मक की तुलना में बहुत अधिक नकारात्मक प्रतिक्रिया मिलती है, तो शायद उन्हें एहसास होगा कि उन्हें बदलने की आवश्यकता है। आपका सैंडविच दृष्टिकोण हर नकारात्मक के लिए एक 2: 1 अनुपात देता है, इसलिए वे शुद्ध सकारात्मक को समाप्त करते हैं, यह वह संदेश है जिसे आप भेजना चाहते हैं।
cdkMoose

14
2 व्यक्ति का उपयोग बंद करो। कोड विषय है, कोडर नहीं। उदाहरण के लिए, लिखें: SaveAndSend को अपने व्यवहार में बेहतर रूप से फिट होने के लिए नाम बदला जाना चाहिए, जैसे SendErrorMail । अभी, यह वास्तव में ऐसा लगता है कि आप अपने सहकर्मी को आदेश दे रहे हैं, यहां तक ​​कि सभी "आप कृपया कर सकते हैं" के साथ आप सभी को छोड़ दिया। मैं एक समीक्षक से इसे स्वीकार नहीं करूंगा। मैं किसी को पसंद करता हूं जो स्पष्ट रूप से कहता है "यह किया जाना चाहिए", बजाय मुझसे (यहां तक ​​कि विनम्रता से) कुछ करने के लिए।
आर्थर हैवेलिस

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

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

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

जवाबों:


124

कोड समीक्षा में सकारात्मक चीजें कैसे ढूंढें?

पिछले वर्ष में कुछ गंभीर गुणवत्ता की समस्याओं के बाद, मेरी कंपनी ने हाल ही में कोड समीक्षा पेश की है।

महान, आपके पास अपनी फर्म के लिए मूल्य बनाने का एक वास्तविक अवसर है।

पहले कुछ हफ्तों के बाद मेरे सहयोगी ने चीजों को स्लाइड करना शुरू कर दिया, जिससे सहकर्मियों को परेशानी न हो (उसने मुझे खुद बताया, कि एक ग्राहक द्वारा बगरेपोर्ट दायर किए जाने के बाद, उसे बग के बारे में पता था, लेकिन उसे डर था कि डेवलपर यह इंगित करने के लिए उसके लिए पागल होगा)।

आपके सहकर्मी को कोड की समीक्षा नहीं करनी चाहिए, यदि वह डेवलपर्स को यह बताने में सक्षम नहीं कर सकता है कि उनके कोड में क्या गलत है। समस्याओं को खोजने और ग्राहकों को प्रभावित करने से पहले उन्हें ठीक करना आपका काम है ।

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

दूसरी ओर, मैं अब प्रतिबद्ध कोड के साथ समस्याओं को इंगित करने के लिए एक गधा होने के लिए जाना जाता हूं।

ठीक है, यह दुर्भाग्यपूर्ण है, आप कहते हैं कि आप स्पर्शशील हो रहे हैं। आप और अधिक प्रशंसा पा सकते हैं, यदि आपके पास देखने के लिए अधिक है।

लेखक की नहीं, कोड की आलोचना करें

आप एक उदाहरण दें:

आपके परिवर्तनों के बारे में मेरे कुछ प्रश्न हैं

"आप" और "अपने" शब्दों के उपयोग से बचें, कहते हैं, "" इसके बजाय बदल जाता है।

क्या मैं कुछ भुल गया? [...] ऐसा क्यों है?

अपने आलोचकों में अलंकारिक उत्कर्ष न जोड़ें। या तो मजाक मत करो। एक नियम है जो मैंने सुना है, "अगर यह आपको कहना अच्छा लगता है, तो यह मत कहो, यह अच्छा नहीं है।"

हो सकता है कि आप किसी दूसरे के खर्चे पर अपना अहंकार पाल रहे हों। इसे सिर्फ तथ्यों पर रखें।

सकारात्मक प्रतिक्रिया देकर बार उठाएं

यह अपने साथी डेवलपर्स की प्रशंसा करने के लिए बार उठाता है जब वे उच्च मानकों को पूरा करते हैं। तो इसका मतलब है कि प्रश्न,

कोड समीक्षा में सकारात्मक चीजें कैसे ढूंढें?

एक अच्छा एक है, और संबोधित करने लायक है।

आप यह इंगित कर सकते हैं कि कोड उच्च स्तरीय कोडिंग प्रथाओं के आदर्शों को कहां से पूरा करता है।

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

भाषा विशिष्ट सर्वोत्तम अभ्यास

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

  • क्या यह इन-हाउस भाषा शैली गाइड मानकों को पूरा करता है?
  • क्या यह भाषा के लिए सबसे अधिक आधिकारिक शैली मार्गदर्शिका को पूरा करता है (जो शायद घर की तुलना में अधिक सख्त है - और इस प्रकार अभी भी घर में शैली के अनुरूप है)?

सामान्य सर्वोत्तम अभ्यास

आप विभिन्न प्रतिमानों के तहत सामान्य कोडिंग सिद्धांतों पर प्रशंसा करने के लिए अंक पा सकते हैं। उदाहरण के लिए, क्या उनके पास अच्छे unittests हैं? क्या अधिकांश कोड एकतरफा होते हैं?

ढूंढें:

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

कार्यात्मक प्रोग्रामिंग

यदि भाषा कार्यात्मक है, या कार्यात्मक प्रतिमान का समर्थन करता है, तो इन आदर्शों की तलाश करें:

  • ग्लोबल्स और वैश्विक स्थिति से बचना
  • क्लोजर और आंशिक कार्यों का उपयोग करना
  • पढ़ने योग्य, सही और वर्णनात्मक नामों के साथ छोटे कार्य
  • एकल निकास बिंदु, तर्कों की न्यूनतम संख्या

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग (OOP)

यदि भाषा OOP का समर्थन करती है, तो आप इन सुविधाओं के उपयुक्त उपयोग की प्रशंसा कर सकते हैं:

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

OOP के तहत, SOLID सिद्धांत भी हैं (शायद OOP सुविधाओं के लिए कुछ अतिरेक):

  • एकल जिम्मेदारी - प्रत्येक वस्तु में एक हितधारक / मालिक होता है
  • खुला / बंद - स्थापित वस्तुओं के इंटरफेस को संशोधित नहीं करना
  • लिस्कोव प्रतिस्थापन - उपवर्गों को माता-पिता के उदाहरणों के लिए प्रतिस्थापित किया जा सकता है
  • इंटरफ़ेस अलगाव - रचना द्वारा प्रदान किए गए इंटरफेस, शायद मिश्रण
  • निर्भरता उलटा - परिभाषित इंटरफेस - बहुरूपता ...

यूनिक्स प्रोग्रामिंग सिद्धांत :

यूनिक्स सिद्धांत प्रतिरूपता, स्पष्टता, संरचना, पृथक्करण, सरलता, पारसमणि, पारदर्शिता, मजबूती, प्रतिनिधित्व, कम से कम आश्चर्य, मौन, मरम्मत, अर्थव्यवस्था, पीढ़ी, अनुकूलन, विविधता और विलक्षणता हैं।

सामान्य तौर पर, इन सिद्धांतों को कई प्रतिमानों के तहत लागू किया जा सकता है।

आपका मापदंड

ये बहुत तुच्छ हैं - अगर इसके लिए मेरी प्रशंसा की जाए तो मैं कृपालु महसूस करूंगा:

  • कोड संकलित करेगा।
  • कम से कम एक तरह से कोड काम करेगा।
  • कोड सबसे सामान्य मामलों के साथ काम करेगा।

दूसरी ओर, ये काफी उच्च प्रशंसा हैं, इस पर विचार करते हुए कि आप क्या व्यवहार करते हैं, और मैं ऐसा करने के लिए डेवलपर्स की प्रशंसा करने में संकोच नहीं करूंगा:

  • कोड अधिकांश किनारे मामलों के साथ काम करेगा।
  • यदि सम्मिलित डेटा मान्य नहीं है तो कोड उचित अपवाद को फेंक देगा।

कोड समीक्षा पास करने के लिए नियम लिखना?

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

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

निष्कर्ष

यदि आप भाषा का समर्थन करते हैं, तो आप कई प्रतिमानों के तहत और संभवतः उन सभी के तहत सर्वोत्तम प्रथाओं की प्रशंसा कर सकते हैं।


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

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

4
@ ऐरन: एप्रोच में आपसे सहमत हूं। यहाँ बहुत सारे उत्तर कहते हैं कि "चीनी का कोट मत करो", लेकिन मैं समझता हूं कि यह सभी को खुश करने के बारे में नहीं है। लोग अच्छे दृष्टिकोण का अनुसरण करने की अधिक संभावना रखते हैं जब वे जो अच्छे काम करते हैं, वे प्रबलित होते हैं, न कि जब उन्हें बताया जाता है कि वे गलत हैं। वे यहाँ महत्वपूर्ण है कि क्या करना है, लेकिन इसके बारे में सुसंगत होना है। ओपी के विवरण से, वह एक कम-से-परफेक्ट कोडिंग टीम में है, यहां तक ​​कि पुराने सदस्यों के साथ भी जो उनके रास्ते में उपयोग किए जाते हैं। वे सौम्य दृष्टिकोण के लिए अधिक ग्रहणशील होंगे।
लॉन्ग

@ HoàngLong हर 'पुराने टाइमर' जरूरी नहीं कि 'अधिक ग्रहणशील' हो। कहीं न कहीं कोई ना कोई हमेशा अनुचित होता है। उदाहरण के लिए, मैं एक ऐसे व्यक्ति के साथ काम करता था जिसने पायथन और तोड़फोड़ से लेकर गिट तक अपनी पर्ल की सर्वोत्तम प्रथाओं को 'पोर्टिंग' करने पर जोर दिया था, और हर बार किसी तरह की शिकायत होने पर इसे बाहर बुला लिया गया था, फिर चाहे वह कैसा भी हो। तर्क समझाया गया। चूँकि उस समय की ज़िम्मेदारी मेरी गोद पर थी (मैं पायथन और गिट दोनों के साथ एक ही अनुभवी था), मुझे लगता है कि कुछ लोगों को बस खतरा महसूस हो सकता है (?) और तदनुसार प्रतिक्रिया दें ...
code_dredd

104

जब तक इसका ठोस संक्षिप्त उदाहरण न हो और इसे सीधे ध्यान केंद्रित मुद्दे से संबंधित न हो, तब तक कुछ अच्छा चुनने की चिंता न करें

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

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

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

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

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

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


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

7
@GregBurghardt अरे, वे इसे कुछ भी नहीं के लिए कार्यालय राजनीति कहते हैं।
plast1k

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

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

2
"सुनिश्चित करें कि आप कोड को दोष दे रहे हैं और लेखक को नहीं"। सहमत, लेकिन असुरक्षित / अपरिपक्व प्रकार इसे इस तरह नहीं ले जाएगा।
मेटलमाइस्टर

95

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

इससे बचने का एकमात्र तरीका कोड समीक्षा पास करने के नियमों को लिखना है।

फिर यह एक ऐसा व्यक्ति नहीं है जो चेकइन को विफल या अनुमोदित कर रहा है। वे केवल जाँच कर रहे हैं कि नियमों का पालन किया गया है या नहीं।

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

यदि आपको नियम पसंद नहीं हैं, तो उन्हें बदलने के लिए एक बैठक करें।


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

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

20
-1 मुझे आपके "नीरद युद्धों" की आलोचना करने का तरीका पसंद है और फिर "इससे बचने का एकमात्र तरीका" कहना।
tymtam

33
हर संभव खराब डिजाइन निर्णय के लिए नियम को लिखना असंभव है। और यदि आपने जाते हुए एक बनाने की कोशिश की, तो आपको जल्दी से पता चल जाएगा कि दस्तावेज़ सरासर लंबाई से अनुपयोगी हो गया है। -1
jpmc26

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

25

मैं आपकी प्रतिक्रिया को शक्कर नहीं करूंगा क्योंकि इसे संरक्षण माना जा सकता है।

मेरी राय में, सबसे अच्छा अभ्यास हमेशा कोड पर ध्यान केंद्रित करना है और लेखक पर कभी नहीं।

यह एक कोड की समीक्षा है, डेवलपर की समीक्षा नहीं है , इसलिए:

  • "यह लूप कभी खत्म नहीं हो सकता", "आपका लूप कभी खत्म नहीं हो सकता"
  • "परिदृश्य X के लिए एक परीक्षण मामले की आवश्यकता है", "आपने इस परिदृश्य को कवर करने के लिए परीक्षण नहीं लिखा"

दूसरों के साथ समीक्षा के बारे में बात करते समय एक ही नियम लागू करना भी बहुत महत्वपूर्ण है:

  • "ऐनी, आप इस कोड के बारे में क्या सोचते हैं?", "ऐनी, आप जॉन के कोड के बारे में क्या सोचते हैं?"

कोड समीक्षा प्रदर्शन की समीक्षा का समय नहीं है - इसे अलग से किया जाना चाहिए।


3
आप वास्तव में सवाल का जवाब नहीं दे रहे हैं। सवाल यह है कि "कोड समीक्षा में सकारात्मक चीजों को कैसे ढूंढें?" - और यह जवाब सिर्फ एक विरोधाभास है - आप जवाब दे रहे हैं, "मैं नकारात्मक प्रतिक्रिया कैसे दूं"।
एरोन हॉल

15

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

आप एक संदेश में संपूर्ण मर्ज अनुरोध की समीक्षा क्यों कर रहे हैं?

कोड समीक्षाओं के साथ मेरा अनुभव GitLab के माध्यम से है; मैंने हमेशा कल्पना की थी कि अन्य कोड समीक्षा टूल भी इसी तरह काम करेंगे।

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

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

इस वर्कफ़्लो के साथ, कोड समीक्षाएं बहुत अधिक मॉड्यूलर और कम एकजुट हो जाती हैं। एक कोड की समीक्षा से एक लाइन बस कह सकते हैं,

समर्पित दृष्टिकोण में इसे लपेटकर अच्छा तरीका!

या यह कह सकते हैं,

यह ऑब्जेक्ट नाम वास्तव में ऑब्जेक्ट के उद्देश्य से मेल नहीं खाता है; शायद हम इसके बजाय 'XYZ' जैसे नाम का उपयोग कर सकते हैं?

या अगर किसी सेक्शन के साथ बड़ी समस्याएं हैं, तो मैं लिख सकता हूं:

मैं देखता हूं कि यह कोड काम करता है (और मैं देखता हूं कि यह क्यों काम करता है) लेकिन इसे समझने के लिए केंद्रित अध्ययन की आवश्यकता होती है। क्या आप इसे अलग-अलग कार्यों में शामिल कर सकते हैं ताकि भविष्य में इसे बनाए रखना आसान हो जाए?

(उदाहरण: फ़ंक्शन एबीसी वास्तव में यहां तीन चीजें कर रहा है: फू को चकाचौंध करना, बोज़ को रोकना और ज़ोफ़ को फ्रोजन करना। वे सभी अलग-अलग कार्य हो सकते हैं।)

उपरोक्त सभी लिखने के बाद, मैं पूरे मर्ज के अनुरोध पर एक सारांश टिप्पणी कर सकता हूं, जैसे कुछ:

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


भले ही मर्ज अनुरोध एक पूर्ण कुत्ते का नाश्ता है, व्यक्तिगत टिप्पणियां प्रत्येक सरल हो सकती हैं। बस उनमें से अधिक होगा। फिर सारांश टिप्पणी कह सकते हैं:

मुझे क्षमा करें, लेकिन यह कोड वास्तव में सूंघने के लिए नहीं है। एक बहुत से किनारे मामले हैं (व्यक्तिगत टिप्पणियों में विस्तृत के रूप में) जो गलत तरीके से नियंत्रित किए जाएंगे और एक खराब उपयोगकर्ता अनुभव, या यहां तक ​​कि एक मामले में डेटा भ्रष्टाचार भी देंगे। (कमेंट 438a95fb734 पर टिप्पणी देखें।) यहां तक ​​कि कुछ सामान्य उपयोग के मामलों में भी बहुत खराब एप्लिकेशन प्रदर्शन होगा (विशेषकर somefile.c के लिए अलग-अलग टिप्पणियों में उल्लेखित)।

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

मैं मर्ज अनुरोध बंद कर रहा हूँ एक पूर्ण पुनर्लेखन लंबित।


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


12

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

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

अच्छे और बुरे अंक देने में निष्पक्ष रहने की कोशिश करना न केवल असंभव है बल्कि आपकी भूमिका से पूरी तरह से बाहर है।

आपकी समीक्षा से ली गई सामग्री के साथ सुधार के उदाहरण यहां दिए गए हैं:

  • इससे पहले कि हम लायब्रेरी \ ACME \ ExtractOrderMail वर्ग में परिवर्तन खींचते हैं, हमें कुछ समस्याएँ ठीक करने की आवश्यकता होती है।
  • जब तक मैं कुछ याद नहीं करता, "TempFilesToDelete" को स्थिर नहीं होना चाहिए।
  • भविष्य में, हम फ़ंक्शन को प्रति रन एक से अधिक बार कॉल कर सकते हैं, यही कारण है कि हमें (यहां क्या करना है) की आवश्यकता है।
  • मुझे यह समझने की आवश्यकता है कि "GetErrorMailBody" पैरामीटर के रूप में एक अपवाद क्यों लेता है। (और, मैं यहाँ बॉर्डरलाइन कर रहा हूँ, क्योंकि अब तक, आपके पास पहले से ही एक निष्कर्ष होना चाहिए )
  • SaveAndSend का नाम बदलकर उसके व्यवहार में सुधार करने के लिए उसका नाम बदल दिया जाना चाहिए, जैसे "SendErrorMail"
  • पठनीय उद्देश्य के लिए टिप्पणी कोड को हटा दिया जाना चाहिए। हम अंतिम रोलबैक के लिए तोड़फोड़ का उपयोग करते हैं।

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

अब, आप मानव कारक को समीकरण से बाहर निकालकर बहुत ही कारण कोड समीक्षाएं बढ़ा रहे हैं।


नमूना समीक्षा प्रश्न का एक हालिया जोड़ है, अधिकांश उत्तरदाताओं ने इसे नहीं देखा था
इज़्काटा

8

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

आपकी टीम (प्रबंधक) को यह बताना चाहिए कि उत्पादक कीड़े गेम का हिस्सा हैं, लेकिन उन्हें खोजने और ठीक करने से हर किसी की नौकरी बच जाएगी ।

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

यह वास्तव में एक सांस्कृतिक चीज है, और इसे बहुत सारे विश्वास और संचार की आवश्यकता है। और परिणामों के साथ काम करने का समय।


2
"कोड की समीक्षा का पूरा बिंदु समस्याओं का पता लगाना है" - लेकिन इसमें से कोई भी पूछे गए प्रश्न का उत्तर नहीं देता है।
आरोन हॉल

3
वह गलत xy-problem पूछ रहा है, देखें meta.stackexchange.com/questions/66377/what-is-the-xy-problem
Eiko

1
आपकी टीम (प्रबंधक) को यह बताना चाहिए कि उत्पादक कीड़े गेम का हिस्सा हैं, लेकिन उन्हें खोजने और ठीक करने से हर किसी की नौकरी बच जाएगी । यह सच है और इसका मतलब है कि हर कोई एक हितधारक है। लेकिन किसी को बग (या, बस खराब स्पेगेटी कोड) को इंगित करने की ज़िम्मेदारी नहीं होनी चाहिए ताकि मूल कोडर को साबित करने के लिए एक टेस्ट केस लिखा जा सके कि यह एक बग है। (केवल अगर यह व्यापक रूप से विवादित है कि यह वास्तव में एक बग है।)
रॉबर्ट ब्रिस्टो-जॉनसन

6

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

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

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

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

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


4

यह कठोर हो सकता है, लेकिन अच्छी प्रतिक्रिया देने के बारे में चिंता न करें अगर मापने के लिए कुछ भी अच्छा नहीं है।

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

एक और बात; वहाँ एक रक्षात्मक हवा हो सकती है क्योंकि उन्हें लगता है जैसे उनके पास कोई कहने के लिए नहीं है। क्यों न उन्हें एक दूसरे के कोड की समीक्षा करने दें? उनसे विशिष्ट प्रश्न पूछें और उन्हें शामिल करने का प्रयास करें। यह आपको उनके विरुद्ध नहीं होना चाहिए; यह एक टीम प्रयास होना चाहिए।

  1. अगर आपके पास समय होता तो आप इस कोड के बारे में क्या बदलते?
  2. आप कोडबेस के इस क्षेत्र को कैसे सुधारेंगे?

कि अब पूछो, और पूछो कि अब से छह महीने। यहां सीखने का अनुभव है।

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


1
"अच्छी प्रतिक्रिया देने के बारे में चिंता न करें अगर मापने के लिए कुछ भी अच्छा नहीं है" मुझे यह विश्वास करना मुश्किल लगता है कि वह कम से कम कुछ सकारात्मक नहीं पा सका है जो अन्य पेशेवर प्रोग्रामर द्वारा लिखे गए कोड के बारे में कहना चाहता है, जबकि अभी भी हर किसी के लिए उम्मीदों पर बार उठा रहा है। कोड। इस सवाल का जवाब नहीं है - यह सिर्फ एक विरोधाभास है।
आरोन हॉल

2
@AaronHall: "आपका कोड एक अच्छा उदाहरण के रूप में सेवा कर सकता है कि कैसे कोड नहीं लिखा जाए"। क्या यह काफी सकारात्मक है?
gnasher729

1
@AaronHall यदि ओपी अन्य पेशेवर प्रोग्रामर द्वारा लिखे गए कोड के बारे में कहने के लिए कुछ सकारात्मक पा सकता है, तो हर तरह से उसे या उसे चाहिए। हालांकि, अगर वहाँ नहीं है, तो कुछ बनाने की कोशिश करने का कोई मतलब नहीं है। इसके बजाय, ओपी को डेवलपर प्रयास और सीखने पर ध्यान केंद्रित करना चाहिए, न कि स्वयं कोड।
लंचमीट 317

4

बिना तनाव के गुणवत्ता

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

"अच्छी खबर में बुरी खबर" सैंडविच की पुरानी चाल बैकफायर हो सकती है। डेवलपर्स को यह देखने की संभावना है कि यह क्या है: एक विरोधाभास।

आपकी संस्थाएँ टॉप-डाउन ट्रबल

आपके मालिकों ने आपको गुणवत्ता सुनिश्चित करने का काम सौंपा। आप कोड गुणवत्ता के लिए मापदंड की एक सूची के साथ आए थे। अब, आप अपनी टीम को प्रदान करने के लिए सकारात्मक सुदृढीकरण के लिए विचार चाहते हैं।

हमसे क्यों पूछें कि आपको अपनी टीम को खुश करने के लिए क्या करने की आवश्यकता है? क्या आपने अपनी टीम से पूछने पर विचार किया है?

ऐसा लगता है कि आप अच्छा बनने की पूरी कोशिश कर रहे हैं। समस्या यह नहीं है कि आप अपना संदेश कैसे दे रहे हैं। समस्या यह है कि संचार एक तरफ़ा है।

गुणवत्ता की संस्कृति का निर्माण

गुणवत्ता की संस्कृति का पोषण नीचे से ऊपर की ओर बढ़ने के लिए किया जाना है।

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

अपनी टीम के साथ मिलें अपनी टीम में आप जो व्यवहार देखना चाहते हैं, उसे मॉडल करें: विनम्रता, सम्मान और सुधार के लिए प्रतिबद्धता।

कुछ ऐसा कहें: “जैसा कि आप जानते हैं, [सहकर्मी] और मुझे कोड गुणवत्ता सुनिश्चित करने का काम सौंपा गया था, ताकि हम हाल ही में उत्पन्न हुए उत्पादन के मुद्दों को रोक सकें। मुझे नहीं लगता कि मैंने इस समस्या को हल किया है। मुझे लगता है कि मेरी सबसे बड़ी गलती शुरुआत में आप सभी को अधिक शामिल नहीं कर रही थी। [सहकर्मी] और मैं अभी भी कोड गुणवत्ता के लिए प्रबंधन के प्रति जवाबदेह हैं , लेकिन आगे जाकर, हम सभी एक साथ गुणवत्ता के प्रयास में हैं। ”

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

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

सहयोगात्मक कोड समीक्षा

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

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

सहकर्मी समीक्षा कोड का एक महत्वपूर्ण लक्ष्य यह सुनिश्चित करना है कि टीम के सभी सदस्यों द्वारा कोड को समझा जा सकता है। अस्पष्ट फ़ंक्शन नामों के अपने उदाहरण पर विचार करें: एक अधिक जूनियर डेवलपर से सुनने से पता चलता है कि वे फ़ंक्शन नाम को भ्रमित करते हुए वरिष्ठ देव से एक और "सुधार" को स्वीकार करना आसान हो सकता है।

गुणवत्ता एक यात्रा है

एक और बात यह है कि किसी भी धारणा को समाप्त करना है कि एक कोड समीक्षा पास / असफल प्रकार है। सभी को एक कोड समीक्षा के बाद कुछ संपादन करने की उम्मीद करनी चाहिए। (और यह सुनिश्चित करने के लिए आपका काम है।)

लेकिन अगर वह काम नहीं करता है ...

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


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

4

अभी तक एक और लंबे उत्तर के लिए क्षमा करें, लेकिन मुझे नहीं लगता कि अन्य लोगों ने इस मुद्दे के मानवीय तत्व को पूरी तरह से संबोधित किया है।

कभी-कभी सिर्फ यह पूछने पर भी कि कुछ को एक विशिष्ट तरीके से क्यों लागू किया गया। जब मुझे लगता है कि यह बुरा है, तो मैं इंगित करता हूं कि मैंने इसे दूसरे तरीके से विकसित किया होगा।

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

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

उदाहरण:

यह पूछने के बजाय कि "आपने इस मान के लिए निरंतर चर का उपयोग न करने का विकल्प क्यों चुना?", बस राज्य "इस हार्ड-कोडित मान को XYZफ़ाइल में निरंतर के साथ प्रतिस्थापित किया जाना चाहिए Constants.h" सवाल पूछने से पता चलता है कि डेवलपर ने सक्रिय रूप से उपयोग नहीं करने का चयन किया है पहले से ही परिभाषित स्थिरांक, लेकिन यह पूरी तरह से संभव है कि वे यह भी नहीं जानते थे कि यह अस्तित्व में है। एक बड़े पर्याप्त कोड आधार के साथ, बहुत सी चीजें होने जा रही हैं जो प्रत्येक डेवलपर को नहीं पता है। यह केवल उस डेवलपर के लिए एक अच्छा सीखने का अवसर है जो परियोजना के स्थिरांक से परिचित होता है।

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

अच्छा:

  • "इस चर का नाम हमारे कोडिंग मानक से मेल खाने के लिए बदलना होगा।"

  • "इस फ़ंक्शन नाम में 'बी' को पास्कलकेस होने के लिए पूंजीकृत करने की आवश्यकता है।"

  • "इस फ़ंक्शन का कोड ठीक से इंडेंट नहीं किया गया है।"

  • "यह कोड में पाया गया कोड का एक डुप्लिकेट है ABC::XYZ(), और इसके बजाय उस फ़ंक्शन का उपयोग करना चाहिए।"

  • "आपको कोशिश के साथ संसाधनों का उपयोग करना चाहिए ताकि इस फ़ंक्शन को ठीक से बंद करने की गारंटी दी जाए, भले ही त्रुटियां हों।" [मैंने केवल यहां एक लिंक जोड़ा है ताकि गैर-जावा उपयोगकर्ताओं को पता चले कि क्या-क्या-क्या-क्या साधन हैं।]

  • "हमारे एन-पथ जटिलता मानकों को पूरा करने के लिए इस फ़ंक्शन को फिर से तैयार करने की आवश्यकता है।"

खराब:

  • "मुझे लगता है कि आप हमारे मानक से मिलान करने के लिए चर नाम बदलकर इस कोड को सुधार सकते हैं"

  • " शायद इस फ़ंक्शन में चीजों को ठीक से बंद करने के लिए कोशिश-के-संसाधन का उपयोग करना बेहतर होगा"

  • " इस समारोह में सभी स्थितियों पर एक और नज़र डालना वांछनीय हो सकता है। इसकी एन-पथ जटिलता हमारे मानक की अधिकतम अनुमत जटिलता से अधिक है।"

  • "हमारे मानक 4 के बजाय यहाँ 2 स्थान क्यों हैं?"

  • "आपने ऐसा फ़ंक्शन क्यों लिखा जो हमारे n-path जटिलता मानक को तोड़ता है?"

बुरे वक्तव्यों में इटैलिकाइज्ड हिस्से ऐसी चीजें हैं, जिनका लोग आमतौर पर इस्तेमाल तब करते हैं, जब वे झटका नरम करना चाहते हैं, लेकिन यह सब वास्तव में एक कोड समीक्षा में होता है, जिससे आप खुद को अनिश्चित महसूस करते हैं। यदि आप, समीक्षक, कोड को बेहतर बनाने के बारे में निश्चित नहीं हैं, तो कोई आपकी बात क्यों सुनेगा?

'अच्छे' कथन कुंद हैं, लेकिन वे डेवलपर पर आरोप नहीं लगाते हैं, वे डेवलपर पर हमला नहीं करते हैं, वे टकराव नहीं हैं, और वे सवाल नहीं करते हैं कि दोष क्यों मौजूद है। वह मौजूद है; यहाँ तय है। वे निश्चित रूप से उस अंतिम 'क्यों' प्रश्न के रूप में टकराव के रूप में नहीं हैं।


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

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

3

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

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

"विधि का एक समझदार नाम क्यों होना चाहिए, मुझे पता है कि यह क्या करता है?" कुछ ऐसा है जो मुझे विशेष रूप से परेशान करता है। वह जानता है कि यह क्या करता है, या कम से कम वह ऐसा कहता है, लेकिन मैं नहीं। किसी भी विधि में सिर्फ एक समझदार नाम नहीं होना चाहिए, इसमें एक ऐसा नाम होना चाहिए जो कोड के पाठक को तुरंत स्पष्ट कर दे कि वह क्या करता है। आप Apple की वेबसाइट पर जाना चाहते हैं और स्विफ्ट 2 से लेकर स्विफ्ट 3 तक के बदलावों के बारे में WWDC के वीडियो की तलाश कर सकते हैं - बड़ी संख्या में बदलाव सिर्फ हर चीज को पठनीय बनाने के लिए। हो सकता है कि उस तरह का वीडियो आपके डेवलपर्स को समझा सके कि जो डेवलपर्स बहुत अधिक होशियार हैं, उनके लिए सहज तरीके से नाम बहुत महत्वपूर्ण हैं।

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


+1 देव को पता चल सकता है कि उसका उप-नामाकार्य फ़ंक्शन क्या करता है, लेकिन जब वह किसी बस के नीचे जाता है तो क्या होता है?
मग

3

आपके द्वारा वर्णित कोड समीक्षा की विधि से मैं असहमत हूँ। दो कर्मचारी एक 'बंद कमरे' में जा रहे हैं और आलोचना के साथ आने से इस तरह की प्रतिकूल धारणा को संस्थागत रूप दिया गया है कि अच्छे कोड की समीक्षाओं से बचना चाहिए ।

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

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

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

विवरण के लिए, सामान्य मानक आवश्यक हैं। जो किया जा रहा है उसमें सभी को हिस्सेदारी दें। और अपने कोड आधार में नई, बेहतर तकनीकों को एकीकृत करने की अनुमति दें। पुरानी आदतों की गारंटी देने वाली विफलता "हम हमेशा से ऐसा ही करते हैं" की आड़ में कभी भी उत्तेजित नहीं होते हैं।

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

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


इलेक्ट्रॉनिक के बजाय इन-पर्सन कोड की समीक्षा के लिए +1 - जो आलोचना से किनारा कर लेगा
अलेक्जेंडरबर्ड

3

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

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

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


1

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

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


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

1

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

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

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


1

परिसर ...

प्रोग्रामर समस्या-समाधानकर्ता हैं। समस्या या त्रुटि के साथ प्रस्तुत होने पर हम डीबग करना प्रारंभ करने के लिए वातानुकूलित हैं।

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

कंप्यूटर द्वारा जनरेट किए गए एरर मैसेज पर शायद ही कभी सवाल उठाए जाते हैं और इसे कभी भी पर्सनल अफेयर के रूप में नहीं लिया जाता।

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

निष्कर्ष ...

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

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

उदाहरण कोड समीक्षा प्रतिक्रिया ...

इन तकनीकों को शामिल करते हुए दिए गए उदाहरण का पुनर्लेखन:

  • विषय:

    • लाइब्रेरी \ ACME \ ExtractOrderMail क्लास।
  • सिद्धांत मुद्दा ...

    • TempFilesToDelete स्थिर है
      • बाद में GetMails के लिए कॉल एक अपवाद फेंक क्योंकि फ़ाइलों को इसके साथ जोड़ा जाता है, लेकिन हटाने के बाद कभी नहीं हटाया गया। हालांकि अब केवल एक कॉल, कुछ समानता के साथ भविष्य में प्रदर्शन में सुधार किया जा सकता है।
      • TempFilesToDelete एक उदाहरण चर के रूप में कई वस्तुओं को समानांतर में उपयोग करने की अनुमति देगा।
  • माध्यमिक मुद्दे ...
    • GetErrorMailBody में एक अपवाद पैरामीटर है
      • चूंकि यह खुद एक अपवाद नहीं फेंकता है, और बस इसे ToString पास करता है, क्या यह आवश्यक है?
    • SaveAndSend नाम
      • भविष्य में इसे रिपोर्ट करने के लिए ईमेल का उपयोग किया जा सकता है या नहीं किया जा सकता है और इस कोड में एक सतत प्रतिलिपि संग्रहीत करने और किसी भी त्रुटि की रिपोर्ट करने के लिए सामान्य तर्क हैं। एक अधिक सामान्य नाम आश्रित तरीकों में बदलाव के बिना इस तरह के प्रत्याशित परिवर्तनों की अनुमति देगा। एक संभावना StoreAndReport है।
    • पुराने कोड पर टिप्पणी करना
      • टिप्पणी की गई और चिह्नित OBSOLETE छोड़ने वाली रेखा को डिबगिंग में बहुत मददगार हो सकती है, लेकिन "टिप्पणियों की दीवार" आसन्न कोड में त्रुटियों को भी अस्पष्ट कर सकती है। हम अभी भी इसे तोड़फोड़ में हैं। शायद सिर्फ एक टिप्पणी का संदर्भ देते हुए कि कहां तोड़फोड़ की गई है?

0

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

एक कार्यात्मक परिवर्तन या बगफिक्स के लिए एक पैच में, एक ही पैच में बंडल किए गए अन्य परिवर्तन (नाम बदलना, रीफैक्टरिंग, जो भी हो) के लिए उपयोगी नहीं है। यह बग को ठीक करने वाला परिवर्तन करना चाहिए या फीचर को जोड़ना चाहिए, और कुछ नहीं।

जहां नाम बदलने, रिफैक्टरिंग और अन्य परिवर्तनों को इंगित किया जाता है, उन्हें पहले या बाद में एक अलग पैच में करें।

  • यह बहुत बदसूरत है, लेकिन मुझे लगता है कि यह हमारे सभी अन्य गंदा कोड के अनुरूप है। चलो बाद में साफ करें (एक पैच के साथ, आदर्श रूप से, कोई कार्यात्मक परिवर्तन नहीं)।

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

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

आदर्श रूप से योजना (आप किस प्रकार एक फिक्स परीक्षण कर सकते हैं, या क्या रिफ्लेक्टर और कब) काम पूरा होने से पहले चर्चा की जानी चाहिए, इसलिए उन्हें यह पता लगाने से पहले कि आपके पास कोई समस्या है, प्रयास का भार नहीं उठा है।

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


अलग-अलग पैच में या नहीं, एक टूटी हुई विंडो नीति को विरासत कोड के साथ इंस्टाल करने की आवश्यकता है, चाहे वह पॉलिसी "टूटी हुई खिड़कियों को ठीक न करें" या "केवल [विधियों / वर्गों / फाइलों में?] जो वर्तमान पैच द्वारा छुआ हो? "। मेरे अनुभव में, डेवलपर्स को टूटी खिड़कियों को ठीक करने से रोकना टीम मनोबल के लिए विषाक्त है।
डेवी मॉर्गन

1
यह सच है, लेकिन एक-पंक्ति परिवर्तन पास समीक्षा से पहले मॉड्यूल में प्रत्येक टूटी हुई खिड़की को ठीक करने के लिए उन्हें मजबूर करना समान रूप से विषाक्त है।
बेकार

माना! एक नीति जो बाहरी रूप से थोपने की बजाए टीम द्वारा थ्रो आउट की गई है, केवल एक ही प्रकार है जो काम कर सकती है, मुझे लगता है।
डेवी मॉर्गन

0

मुझे लगता है कि यह मान लेना एक गलती है कि एक तकनीकी या आसान समाधान है: "जब मैं अपने मानकों से अपने काम का न्याय करता हूं, तो मेरे सहकर्मी परेशान हैं, और इसे लागू करने के लिए कुछ शक्ति है"।

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

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

यदि आप सही हैं, बिना किसी झगड़े के कमरे में, यह इंगित करना एक हमला है: किसी ने गड़बड़ कर दी। यदि नहीं: आपका एक और एमबीए जो इसे प्राप्त नहीं करता है। किसी भी तरह, अपने बुरे आदमी होने जा रहा है।

हालांकि, अगर समीक्षा क्या दिख रही है और क्यों , स्पष्ट और सहमति है, तो आपके पास बुरे आदमी नहीं होने का एक अच्छा मौका है। तुम द्वारपाल नहीं हो, सिर्फ एक प्रमाणक हो। इस समझौते को प्राप्त करना [1] को हल करने के लिए एक कठिन समस्या है। मैं आपको सलाह देना चाहूंगा, लेकिन मुझे अभी तक यह लटका नहीं है ...

[१] यह सिर्फ इसलिए हल नहीं हुआ क्योंकि लोगों ने "ठीक" कहा, या इसके बारे में लड़ना बंद कर दिया। कोई भी व्यक्ति यह नहीं कहना चाहता कि एक्स केवल हमारे {बुद्धिमत्ता, अनुभव, मानव-शक्ति, समय सीमा, आदि} के लिए व्यावहारिक नहीं है, लेकिन इसका मतलब यह नहीं है कि यह वास्तव में एक्स करने के कुछ विशिष्ट उदाहरण के लिए आता है ...


-1

कोड समीक्षाएं परस्पर होनी चाहिए। सबने सबकी आलोचना की। मान लें कि "पागल मत बनो, यहां तक ​​कि जाओ।" हर कोई गलतियाँ करता है और एक बार लोगों ने एक हॉट शॉट को बताया कि कैसे अपने कोड को ठीक करना है, वे समझेंगे कि यह सिर्फ सामान्य प्रक्रिया है न कि उन पर हमला।

अन्य लोगों का कोड देखना शैक्षिक है। कोड को उस बिंदु पर समझना जहां आप इसके कमजोर स्थान को इंगित कर सकते हैं और यह समझा सकते हैं कि कमजोरी आपको बहुत कुछ सिखा सकती है !

एक कोड की समीक्षा में प्रशंसा के लिए बहुत कम जगह है, क्योंकि पूरे बिंदु को खामियों का पता लगाना है। हालाँकि, आप फ़िक्सेस पर प्रशंसा प्राप्त कर सकते हैं । समयबद्धता और नीरसता दोनों की प्रशंसा की जा सकती है।


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

2
@DewiMagon मैं "newbies थोड़ी देर के लिए समीक्षाएँ नहीं लेनी चाहिए" से असहमत हूं। कोड्स आधार के साथ परिचित होने के लिए उनके लिए समीक्षाएँ करना एक नया तरीका है। उस ने कहा, वे केवल समीक्षक नहीं होना चाहिए ! और कहा कि, मैं किसी भी मामले में केवल एक ही समीक्षक होने से सावधान हूं।
मोहभंग हुआ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.