मैं समीक्षा के दौरान दूसरों के बुरी तरह से डिज़ाइन किए गए कोड में सुधार का सुझाव कैसे दे सकता हूं?

Question

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

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

Comments

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

— कोडर

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

— २०:०२ पर Yony

सवाल यह ध्वनि करता है जैसे कि परीक्षण के पूरा होने के बाद कोड की समीक्षा हो रही है । अगर ऐसा है, तो आप या तो परीक्षण समय बर्बाद कर रहे हैं (किसी भी बदलाव को फिर से परीक्षण करने की आवश्यकता है) या कोड समीक्षा (क्यों कोड पहले से ही काम करता है?

— विन्गंड्रोइड

@ बक्वेटा - जब आप अभी तक काम करते हैं तो आपको पता नहीं है कि क्यों कोड की समीक्षा करें और कई लोगों का समय बर्बाद करें?

— डंक

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

— कालेब

Answer 1

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

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

3. कोड कंक्रीट की तरह है: थोड़ी देर बैठने के बाद इसे बदलना अधिक कठिन है। यदि आप कर सकते हैं तो अपने परिवर्तनों को शीघ्रता से सुझाएं, ताकि परिवर्तनों की लागत और जोखिम दोनों कम से कम हो जाएं।

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

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

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

उपरोक्त सभी बिंदुओं को संक्षेप में प्रस्तुत करने के लिए: सुनिश्चित करें कि आपके प्रस्तावित परिवर्तन मूल्य जोड़ते हैं।

Comments

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

— विवानी

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

— जोर्जेन फॉग

आपकी बातों से लगता है कि यह गोल्फिंग ठीक है ... :-)

— फ्लोरियन मार्गाइन

+1 पूरे उत्तर के लिए, लेकिन विशेष रूप से "यदि कोड गड़बड़ है, तो इसकी प्रबल संभावना है कि इसमें कीड़े भी हैं"

— कोनामिमन

बिंदु (6) के लिए, दिलचस्प रूप से लगता है कि इंटरफ़ेस की गुणवत्ता कार्यान्वयन की गुणवत्ता से अधिक महत्वपूर्ण है

— ब्रैड थॉमस

Answer 2

रिफैक्टरिंग के माध्यम से मूल्य जोड़ने के लिए एक मीठा स्थान है। तीन चीजों को पूरा करने की जरूरत है:

• कोड में सुधार होगा जो बदलने की संभावना है
• स्पष्टता बढ़ाएं
• कम से कम प्रयास

बातें:

1. हम जानते हैं कि साफ कोड लिखने और बनाए रखने के लिए कम खर्चीला है, और काम करने में अधिक मजेदार है। आपका काम उस विचार को अपनी कंपनी के लोगों को बेचना है। एक सेल्समैन की तरह सोचें, एक घमंडी की तरह नहीं।
2. आप जीत नहीं सकते, आप केवल कम ढीले कर सकते हैं।
3. वास्तविक मूल्य जोड़ने पर ध्यान दें - न केवल सौंदर्य। मुझे अच्छा दिखने के लिए मेरा कोड पसंद है, लेकिन कभी-कभी उस सस्ती बात को अधिक स्वीकार करना पड़ता है।
4. स्वीट स्पॉट को खोजने का एक अच्छा तरीका है बॉय स्काउट सिद्धांत का पालन करना - जब आप कोड के एक क्षेत्र पर काम करते हैं, तो हमेशा इसे बेहतर आकार में छोड़ दें जितना आपने इसे पाया था।
5. एक छोटा सा सुधार किसी भी सुधार से बेहतर है।
6. स्वचालित उपकरणों का अच्छा उपयोग करें। उदाहरण के लिए, ऐसे उपकरण जो थोड़े से स्वरूपण को साफ करते हैं वे अंतर की दुनिया बना सकते हैं ।
7. अन्य विचारों को बेचें जो संयोगवश कोड स्पष्टता में सुधार करते हैं। उदाहरण के लिए, यूनिट परीक्षण बड़े तरीकों को छोटे लोगों में विघटित करने के लिए प्रोत्साहित करता है।

Comments

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

— स्पेंसर रथबुन

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

— क्रि।

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

— स्पेंसर रथबुन

Answer 3

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

Comments

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

— टिम अबेल

Answer 4

कोड समीक्षा में 3 उद्देश्य हैं:

1. कीड़े के लिए जाँच कर रहा है

2. यह देखने के लिए कि कोड में कहां सुधार किया जा सकता है

3. कोड लिखने वाले के लिए शिक्षण उपकरण।

# 2 और # 3 के बारे में निश्चित रूप से डिजाइन / कोड की गुणवत्ता का मूल्यांकन किया जाता है।

जहाँ तक # 2:

• यह बहुत स्पष्ट करें कि प्रस्तावित परिवर्तनों बनाम लागतों को ठीक करने के लिए क्या लाभ हैं। किसी भी व्यावसायिक निर्णय के रूप में, यह लागत / लाभ विश्लेषण के बारे में होना चाहिए।

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

  • इससे स्मार्ट टीम को प्रभावी ढंग से प्रबंधन करने में मदद मिलेगी। उदाहरण के लिए, वे पूर्ण जानकारी का उपयोग करके तर्कसंगत निर्णय लेंगे

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

  • और, बग जेड होता है, इस संभावित घटना में, आप सुझावों के अगले सेट पर सभी अधिक लाभ उठाते हैं।

जहाँ तक # 3:

• बहुत स्पष्ट रूप से delineate "से कीड़े / मुद्दों को ठीक करना चाहिए" यह एक सर्वोत्तम अभ्यास है और वास्तव में तय किया जाना चाहिए यदि हम संसाधनों को छोड़ सकते हैं - संलग्न प्रो / कांग्रेस विश्लेषण "डिजाइन में सुधार देखें (ऊपर # 2 के लिए वर्णित सामान संलग्न करें") ये सामान्य दिशानिर्देश हैं जो मुझे लगता है कि आपको अपने कोड की मजबूती को बेहतर बनाने में मदद करेंगे ताकि आप कोड को "वैकल्पिक परिवर्तनों" को आसानी से बनाए रख सकें। कृपया ध्यान दें कि - यह "जैसा मैं चाहता हूं कि आप अपना कोड बनाएं" के बारे में नहीं है - यह "यदि आप ऐसा करते हैं, तो आपको लाभ मिलता है a, b, c"। टोन और दृष्टिकोण मायने रखता है।

Comments

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

— कालेब

@ कालेब - अच्छी बात है। मैं कई बिंदु बनाना नहीं चाहता था, इसलिए यह एक रूपरेखा से संपादित हो गया, लेकिन यह अभी भी एक वैध बिंदु है।

— डीवीके

# 4 नई सुविधाओं पर क्रॉस ट्रेनिंग डेवलपर्स

— जुआन मेंडेस

# 5 - कोड समीक्षाओं का मुख्य उद्देश्य यह सुनिश्चित करना है कि डिज़ाइन दस्तावेज़ लागू किया गया है (सही ढंग से)

— Mawg

Answer 5

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

अतिरिक्त काम करने से पहले उन्हें मूल्य देखना चाहिए।

Comments

हमेशा क्षितिज पर समय सीमा नहीं है?

— FreeAsInBeer

Answer 6

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

मैं हमेशा एक कारण भी शामिल करता हूं।

" मैं पठनीयता के कारण इस ब्लॉक को एक विधि में निकालूंगा।"

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

मैं कारणों से एक आम भाषा स्थापित करने की कोशिश कर रहा हूं; पठनीयता, DRY, SRP, आदि।

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

लेकिन कुछ लोग वैसे भी नहीं सुनेंगे। फिर मैं पुलिंग रैंक के साथ छोड़ दिया गया। मैं डिजाइन लीड हूं। कोड की गुणवत्ता मेरी जिम्मेदारी है। यह परिवर्तन इसकी वर्तमान स्थिति में मेरी घड़ी के माध्यम से नहीं होगा।

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

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

Answer 7

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

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

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

दो विकल्पों (रिफ्लेक्टर या कोई रिफ्लेक्टर) के बीच की पसंद को देखते हुए, सोचें कि कौन सी चीज़ ज्यादा बिकती है:

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

या

अरे मालिक, हम रिलीज के लिए तैयार हैं। यदि हमें कभी सुविधा X पर जोड़ना है, तो हमें कुछ दिन अतिरिक्त लग सकते हैं।

यदि आप एक भी कहते हैं, तो आपके बॉस कहेंगे:

फीचर X के बारे में किसने कुछ कहा?

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

Comments

इसे YAGNI c2.com/cgi/wiki?YouArentGonnaNeedIt के

— जुआन मेंडेस

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

— थोर्सल

Answer 8

[यह जवाब मूल रूप से सामने आए प्रश्न की तुलना में थोड़ा व्यापक है, क्योंकि यह कोड समीक्षाओं पर इतने अधिक प्रश्नों के लिए पुनर्निर्देशित है।]

यहां कुछ सिद्धांत दिए गए हैं जो मुझे उपयोगी लगे:

निजी तौर पर आलोचना करें, सार्वजनिक रूप से प्रशंसा करें। किसी को अपने कोड के एक-एक बग के बारे में बताएं। यदि उन्होंने कुछ शानदार किया या किसी ऐसे व्यक्ति को नहीं लिया, जो समूह की बैठक में या टीम के लिए एक ईमेल cc'd में उनकी प्रशंसा करना चाहता था।

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

सकारात्मक टिप्पणी करना याद रखें। एक संक्षिप्त "अच्छा!" या "स्वच्छ चाल!" एक जूनियर या असुरक्षित प्रोग्रामर का दिन बना सकता है।

मान लें कि दूसरा व्यक्ति बुद्धिमान है लेकिन कभी-कभी लापरवाह है। मत कहो: "यदि आप वास्तव में इसे वापस नहीं करते हैं तो आप कॉलर से रिटर्न वैल्यू प्राप्त करने की अपेक्षा कैसे करते हैं ?!" कहो: "ऐसा लगता है कि आप रिटर्न स्टेटमेंट भूल गए।" याद रखें कि आपने अपने शुरुआती दिनों में भयानक कोड लिखा था। जैसा कि किसी ने एक बार कहा था, "यदि आप एक साल पहले से अपने कोड से शर्मिंदा नहीं हैं, तो आप सीख नहीं रहे हैं।"

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

Answer 9

जब एक चम्मच चीनी दवा को नीचे जाने में मदद करती है, और जो गलत है उसे आसानी से व्यक्त किया जा सकता है - 20 चीजें गलत नहीं हैं - मैं एक ऐसे फॉर्म के साथ नेतृत्व करूंगा जो बताता है कि मेरी कोई हिस्सेदारी नहीं है, मैं जो चाहता हूं उसमें कोई अहंकार निवेश नहीं करता है सुना जाना। आमतौर पर यह कुछ इस तरह है:

मुझे आश्चर्य है कि क्या यह बेहतर होगा ...

या

क्या इसका कोई मतलब है ...

यदि कारण स्पष्ट रूप से स्पष्ट हैं, तो मैं उन्हें नहीं बताता। इससे अन्य लोगों को सुझाव के कुछ बौद्धिक स्वामित्व ग्रहण करने का मौका मिलता है, जैसे:

"हाँ, यह एक अच्छा विचार है, क्योंकि < यहाँ आपका स्पष्ट कारण > है।"

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

मुझे आश्चर्य है कि अगर वहाँ एक रास्ता है ... <साझा मूल्य विवरण यहाँ>

यह केवल वास्तव में स्पर्श करने वाले लोगों के साथ काम करने के लिए है - मेरे अधिकांश साथियों के साथ, मैंने अभी इसे जाने दिया है!

Comments

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

— gnasher729

Answer 10

कोड समीक्षा हमेशा सुधार करने के उद्देश्य से नहीं होती हैं।

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

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

Answer 11

आपका प्रश्न है "कोड को बुरी तरह से डिज़ाइन किए गए कोड की समीक्षा कैसे करें?":

उत्तर IMO सरल है। कोड के डिजाइन के बारे में बात करें और डिज़ाइन कैसे त्रुटिपूर्ण है या आवश्यकताओं को पूरा नहीं करता है। यदि आप एक त्रुटिपूर्ण डिज़ाइन बताते हैं या "आवश्यकता पूरी नहीं करते हैं" तो डेवलपर को अपना कोड बदलने के लिए मजबूर होना पड़ेगा क्योंकि यह वह नहीं करता है जो उसे करने की आवश्यकता है।

यदि कोड "कार्यात्मक रूप से पर्याप्त है" और / या "कल्पना से मिलता है" और / या "आवश्यकताओं को पूरा करता है":

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

आपके लिए कुछ विकल्प शेष हैं:

1. आपको अपने स्वयं के व्यक्तिगत "प्रभाव" ("शक्ति" का एक प्रकार जो अप्रत्यक्ष है) और / या "प्रेरक" होने की आपकी क्षमता का उपयोग करना चाहिए
2. अपने संगठनों "कोड प्रक्रिया" समूह के साथ शामिल हों और "कोड रखरखाव" को एक उच्च प्राथमिकता बनाना शुरू करें।
3. बुलेट को काटें और गंदे कोड को तेजी से / अधिक-धाराप्रवाह तरीके से पढ़ना सीखें ताकि आप लटकाए नहीं जाएं (ऐसा लगता है जैसे आप भद्दे कोड पर जब आप भद्दे कोड का सामना करते हैं तो आपको लटका हुआ या धीमा हो जाता है)।
   • यह आपको एक मजबूत प्रोग्रामर भी बनाएगा।
   • और यह आपको भद्दा कोड सही करने देगा जब आप गंदे कोड पर काम कर रहे होंगे।
   • और यह आपको और अधिक परियोजनाओं पर काम करने देगा क्योंकि कई परियोजनाओं में गंदे कोड होते हैं जो कार्यात्मक होते हैं ... लेकिन बहुत सारे भद्दे कोड।
4. मिसाल पेश करके। अपने कोड को बेहतर बनाएं ... लेकिन पूर्णतावादी बनने की कोशिश न करें।
   • क्योंकि तब आप "धीमे आदमी जो समय सीमा को पूरा नहीं कर सकते हैं, हमेशा आलोचना कर रहे हैं, और सोचता है कि वह हर किसी से बेहतर है"।

मुझे लगता है कि कोई चांदी की गोली नहीं है। आपको तीनों का उपयोग करना होगा और आपको अपने तीनों के उपयोग में रचनात्मक होना होगा।

Comments

काश मैं # 3 सीख पाता, मैं खराब कोड से इतना निराश हो जाता कि मेरे पास इसे समझने की कोशिश में भी कठिन समय है ... इस पर लगातार काम कर रहा हूं ....

— जुआन मेंडेस

डिजाइन दोषपूर्ण है? क्या डिजाइन?

— gnasher729

Answer 12

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

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

एक बार जब आप घटकों के बीच की बाधाएं पकड़ लेते हैं, तो प्रमुख मुद्दों के कारण घटकों पर ध्यान केंद्रित करें।

समय सीमा तक दोहराएं या जब तक सिस्टम "सही" न हो।

Answer 13

किसी के कोड के सीधे उल्टा आलोचना के बजाय, कोड समीक्षा के दौरान हमारी टिप्पणियों में कॉसन्स्ट्रक्टिव होना हमेशा बेहतर होता है।

एक तरीका है कि मैं पालन है

1. यदि हम इसे इस प्रकार करते हैं तो यह इष्टतम होगा।
2. इसे इस तरह से लिखने से यह तेजी से चलेगा।
3. यदि आप "यह" "यह" और "यह" करते हैं तो आपका कोड अधिक पठनीय होगा

इस तरह की टिप्पणियों को गंभीरता से लिया जाएगा, भले ही आपकी समय सीमा समाप्त हो रही हो। और शायद अगले विकास चक्र में लागू किया जाएगा।

Answer 14

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

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

Answer 15

कोड समीक्षाओं की गुणवत्ता बढ़ाएं।

समीक्षा के तहत कोड की गुणवत्ता के अलावा, कोड समीक्षा की गुणवत्ता के रूप में ऐसी बात है:

• क्या प्रस्तावित परिवर्तन वास्तव में उस पर एक सुधार है?
• या सिर्फ राय की बात है?
• जब तक कुछ बहुत स्पष्ट न हो, समीक्षक ने ठीक से समझाया, क्यों ?
• इसके लिए कितना समय लगा? (मैंने महीनों से चली आ रही समीक्षाओं को देखा है, डेवलपर के साथ सभी कई मर्ज संघर्षों को हल करने के लिए प्रभारी की समीक्षा के साथ)।
• सुर?

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

Answer 16

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

युक्तिपूर्वक । मुझे लगता है कि आप समीक्षा के खिलाफ ब्रश किए गए अहंकार और नकारात्मक पुशबैक से बचना चाहते हैं। कुछ सुझाव:

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

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

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

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

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

वे क्षेत्र जो इकाई-परीक्षणों से आच्छादित हैं, कम जोखिम वाले हैं। आप हमेशा बाद में उन्हें ठीक कर सकते हैं। जो क्षेत्र नहीं हैं, लेकिन जो यूनिट-परीक्षण किया जा सकता है , वे उन क्षेत्रों की तुलना में कम जोखिम वाले हैं जो यूनिट-परीक्षण नहीं कर सकते हैं ।

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

लेकिन कृपया पहले स्थान पर इस परिदृश्य में समाप्त होने से बचने की कोशिश करें!