मान लीजिए कि एक काल्पनिक कंपनी में काम करता है जिसमें कई डेवलपर्स हैं जो शायद ही कभी परियोजनाओं पर एक साथ काम करते हैं और बॉस ने यह नहीं माना कि कोड समीक्षा समय और लागत के लायक हैं।
इस परिदृश्य में विभिन्न दलीलें पेश की जा सकती हैं जो कि कोड समीक्षा का लाभ बताएंगी? इसके अलावा, यहां कोड की समीक्षा के खिलाफ संभावित तर्क क्या हैं और इन्हें कैसे काउंटर किया जा सकता है?
जवाबों:
अगर आपको ऐसे बुनियादी सामान के लिए खुद को सही ठहराना है, तो आपको एक बड़ी समस्या है।
आप विशेषज्ञ हैं, आपकी टीम को यह तय करना चाहिए कि आप किन प्रथाओं का उपयोग करते हैं। हो सकता है कि आपको अपने बॉस को उस महत्वपूर्ण सिद्धांत के बारे में बताना शुरू करना चाहिए।
अपने मालिक को तय करने के लिए माना जाता है क्या करना है और अधिक महत्वपूर्ण बात करने के लिए क्यों यह कर। आपको इसका निर्माण कैसे करना चाहिए, इसका ध्यान रखना चाहिए
(इसका मतलब यह नहीं है कि आप सुझाव नहीं दे सकते हैं कि आपकी कंपनी में क्या और क्यों चीजें हैं)। एक महान बॉस को अपने कर्मचारियों को उद्यम रणनीति में भाग लेने के लिए प्रोत्साहित करना चाहिए)
हालांकि यहां बताया गया है कि मैं सहकर्मी कोड समीक्षाएं कैसे देखता हूं:
क्योंकि प्रोग्रामिंग एक बहुत ही गहन बौद्धिक कार्य है, एक व्यक्ति यह सुनिश्चित नहीं कर सकता कि सब कुछ सही है। इसलिए कोड समीक्षा यह सुनिश्चित करती है कि:
हर कोई इसका प्रत्यक्ष लाभ ले रहा है:
कोड की समीक्षा कई डेवलपर्स को एक ही कोड से परिचित करा सकती है। यह एक अच्छी बात है। क्या होगा अगर मूल लेखक छोड़ने या बदतर करने का फैसला करता है, तो उसके साथ कुछ बुरा होता है। यदि कोड समीक्षा नियमित रूप से की जाती है, तो अन्य जल्दी से ले सकते हैं।
संभवतया कोड समीक्षा के दौरान पीयर संभावित बग्स या प्रदर्शन समस्याओं को हल करने में सक्षम हों। यह क्यूए और विकास के प्रयासों को कम करता है। यह कोड समीक्षाओं में शामिल अतिरिक्त लागत की भरपाई कर सकता है।
कोड समीक्षाएं ज्ञान साझा करने को बढ़ावा देती हैं। सहकर्मी बेहतर तरीके या सामान करने के वैकल्पिक तरीके बता सकते हैं। मैंने स्वयं अपने साथियों से कोड समीक्षाओं के माध्यम से बहुत कुछ सीखा है।
कोड समीक्षा टीम द्वारा पीछा कोडिंग दिशानिर्देशों को सुदृढ़ करने में मदद करती है। यदि टीम में एक नहीं है, तो उसे ठीक करने की आवश्यकता है। कोड एक बार लिखने और कई बार पढ़ने के लिए होता है। कोडिंग दिशानिर्देश पठनीय कोड की ओर एक कदम है। कोड का अर्थ है साथियों द्वारा पठनीय होना। पठनीयता सुनिश्चित करने के लिए कोड समीक्षाओं की तुलना में बेहतर तरीका क्या है?
बहुत बढ़िया जवाब यहाँ। कुछ चीजें मैं जोड़ूंगा:
जब आपको किसी और को कोड की व्याख्या करनी होती है, तो अक्सर स्पष्टीकरण के दौरान डेवलपर अचानक महसूस कर सकता है कि उसके पास एक बग है। मैंने देखा है कि यह बार-बार होता है कि देव अपनी पटरियों में मृत हो जाता है और कहता है कि "ओह इंतजार करना गलत है" इससे पहले कि समीक्षक ने बग को देखने के लिए अच्छी तरह से बात समझ ली हो।
यह जानने के बाद कि आपका कोड किसी और द्वारा निरीक्षण किया जाएगा, आपको कोडिंग मानकों (रखरखाव को आसान बनाना) या कम "काउबॉय" विधियों का उपयोग करने के लिए और अधिक प्रोत्साहन देता है जो कि आपके अलावा और कभी-कभी खुद को छोड़कर कोई भी नहीं समझेगा। जब आप अपना कोड किसी और को दिखाते हैं तो आप शर्मिंदा नहीं होना चाहते हैं, इसलिए आप इस पर बेहतर काम करते हैं। शर्मिंदगी कारक के कारण, यह कम कोड के साथ टिप्पणी करता है: "मुझे नहीं पता कि यह क्यों काम करता है लेकिन इसे गड़बड़ न करें।" कोड बेस में।
जिन डेवलपर्स को अधिक व्यापक पर्यवेक्षण या प्रशिक्षण की आवश्यकता होती है, उन्हें आसानी से पहचाना जाता है। तो एकमुश्त अक्षम हैं। जितनी जल्दी आप प्रदर्शन की समस्याओं का पता लगा सकते हैं और पता लगा सकते हैं, एक पूरे के रूप में टीम से बेहतर होगा और आवेदन की गुणवत्ता जितनी अधिक होगी। नए व्यक्ति को प्रशिक्षण लेने और उसे आपके आवेदन के सबसे कठिन, सबसे महत्वपूर्ण भाग के लिए नियुक्त करने से पहले यह जानकारी प्राप्त करना अच्छा है।
कभी-कभी यह केवल एक गलत धारणा को ठीक करने का मामला है जो अन्य स्थानों के एक समूह में एक ही गलती करने से बचाएगा। उदाहरण के लिए, हम हाल ही में जटिल रिपोर्टों के लिए कुछ एसक्यूएल की समीक्षा कर रहे थे और पाया कि हमारे नए देवों में से कई लोगों को एक ही गलतफहमी थी कि डेटाबेस में जानकारी का एक विशिष्ट टुकड़ा कहां पाया जाता है (माना जाता है कि उन्होंने जो स्थान उठाया था वह तार्किक लग रहा था जो एक डेटाबेस डिजाइन मुद्दा है। यह भी तय करना होगा) कि सभी रिपोर्टों को सही ढंग से लिखना महत्वपूर्ण होगा। समस्या का पता लगाकर और उनके द्वारा लिखी गई पहली रिपोर्टों में इसे सही करके, इसने उसी त्रुटि को बाकी रिपोर्टों में होने से बचाया। और कुछ पुराने (समय में काम कर रहे हैं, उम्र नहीं) देवों को इतना इस्तेमाल किया गया था कि उन्हें नहीं लगता था कि इसे समझाने की जरूरत थी।
जूनियर्स सीनियर्स द्वारा लिखे गए अधिक परिष्कृत कोड से सीख सकते हैं (जो उदाहरण के लिए बेहतर ट्रैपिंग और एज केस को समझना बेहतर समझते हैं) और सीनियर्स जूनियर्स द्वारा उपयोग की गई नई तकनीकों से सीख सकते हैं कि वे अभी तक उजागर नहीं हुए हैं।
कभी-कभी आवेदन के अलग-अलग लेकिन संबंधित हिस्सों में काम करने वाले लोगों को एहसास होता है कि वे दो अलग और पारस्परिक रूप से अनन्य दिशाओं में जा रहे हैं। ओह, अब ठीक करना आसान है।
कठिन-कोडित मूल्यों में चुपके करना इतना आसान नहीं है जो समय के साथ बदल जाएगा बस अब काम करने के लिए चीज़ मिलेगी। यह भविष्य के बहुत से कीड़े को रोकता है जैसे कि चीजें जो प्रत्येक वित्तीय वर्ष की शुरुआत में बदलती हैं।
मैं कभी-कभी कुछ करने के तरीके पर अटक गया हूं और एक नई तकनीक सीखी है, जो मुझे कोड से किसी और के सामान की समीक्षा करने के लिए मिली थी।
यदि आप इस बात से परिचित हैं कि आपकी टीम के अन्य सदस्य कैसे सोचते हैं (कौन सी कोड समीक्षा आपको उस समझ को देने में मदद करेगी), तो बाद में समस्याओं का निवारण करना आसान हो जाएगा क्योंकि आप इस बात की समझ के साथ शुरू करेंगे कि किस तरह से उस दृष्टिकोण से संपर्क किया होगा मुसीबत।
साथ ही दूसरों द्वारा बताए गए ज्ञान साझाकरण, एक कोड समीक्षा के दौरान बगों के उदाहरण मिलेंगे और उन्हें मापने में कितना समय लगेगा - इसमें समस्या पर शोध करने और पैच किए गए संस्करण को जारी करने के साथ-साथ समय भी शामिल है। वास्तविक समय बग फिक्सिंग।
इस लागत को लें, जो संभवत: कम से कम दो दिनों का प्रयास होगा, और यह उस समय के विपरीत होगा जब आपने एक कोड समीक्षा और परिणामों पर अभिनय करने में खर्च किया होगा।
यह आपके बॉस को दिखाएगा कि कोड समीक्षा व्यय के लायक है।
कोड समीक्षा कर सकते हैं:
विपक्ष
अगर यह सच है तो हम हमेशा एक ही ग्राहक के लिए दो या तीन बार चीजों को करने के लिए समय निकालते हैं, लेकिन हमारे पास इतना समय नहीं है कि हम इसे पहली बार सही कर सकें।
यदि आपको किसी दस्तावेज़ को संदर्भित करने की आवश्यकता है, तो मैं सम्मानित "कोड कम्पलीट" से आगे नहीं देखूँगा। इसमें, पुस्तक यह बताती है कि इकाई परीक्षणों बनाम सहकर्मी समीक्षा के साथ कितनी त्रुटियां पकड़ी गई हैं। यह अचरज की बात है। इकाई परीक्षण, यदि स्मृति मुझे सही कार्य करती है, तो सभी बगों के केवल ~ 30% को पकड़ें, जबकि औपचारिक सहकर्मी समीक्षाएँ ~ 70% पकड़ते हैं।
वह जानकारी लें, उसे पुस्तक में दिखाएं और उसके वित्तीय पक्ष में अपील करें। इससे अधिक समय लगता है और बग्स के माध्यम से अनुमति देने की तुलना में यह अधिक महंगा है कि उन्हें जल्दी पकड़ना है।
कैसे एक डेमो चलाने के बारे में (एक सप्ताह "मिकी माउस" प्रकार की परियोजना) दो टीमों द्वारा समानांतर में निष्पादित की जाती है, एक कोड समीक्षा का उपयोग कर, दूसरा नहीं।
सप्ताह के अंत में, प्रत्येक टीम के काम की गुणवत्ता का आकलन करें, मुझे पूरा यकीन है कि कोड समीक्षक उतना ही बेहतर होगा।
स्टीव मैकोनेल की कांस्ट्रेक्स द बिजनेस केस फॉर बेटर सॉफ्टवेयर प्रैक्टिसेज एंड सॉफ्टवेयर सॉफ्टवेयर डेवलपमेंट्स लो हैंगिंग फ्रूट (एलएचएफ) से संबोधित करते हैं। बाद के "एलएचएफ जो ऊपरी प्रबंधन द्वारा पुनर्वित्त नहीं किया जाएगा" से निरीक्षणों को सूचीबद्ध करता है।
इसे प्रस्तुत करते समय, बड़ी तस्वीर पर ध्यान केंद्रित करें।
लाभ की सूची (बेहतर कोड, कम बग, कम फिर से लिखता है, आदि) और उन तकनीकों में से एक के रूप में कोड समीक्षा का उल्लेख करें जिनकी आप सिफारिश करेंगे।
मैं इसे सॉफ्टवेयर कारीगर बनाने की एक बड़ी तस्वीर का हिस्सा बनाऊंगा
इन सिद्धांतों को बढ़ावा देने के लिए खुद बहुत काम करने के लिए तैयार रहें।
सब से अधिकांश अनुनय की उम्मीद एक "एक बैठक और किया" थोड़े बात नहीं है।
आपको समय के साथ शांति और लगातार मामले का निर्माण करना चाहिए। जब आप बग से सबसे अधिक परेशान होते हैं जो बेहतर तकनीकों द्वारा तय किया गया होता है, तो अक्सर आपके मामले को बनाने का सबसे खराब समय होता है क्योंकि आप अधिक भावुक और कम तर्कसंगत होने की संभावना रखते हैं। यह कुछ-कुछ उलझाने वाला लग सकता है, लेकिन यह वही है जो मैंने 30 साल की प्रोग्रामिंग में सीखा है। जाहिर है यम।