कोड की समीक्षा: योगदानकर्ता और समीक्षक के लिए खराब सुझाव

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


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

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

चेतावनी: कहानी में व्यंग्य है।

एक योगदानकर्ता के लिए खराब सुझाव

किसी के साथ एक नई सुविधा पर चर्चा न करें

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

कभी तकनीकी दस्तावेज नहीं

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

जब आप "फ़ैक्टरी विधियों में सुधार और कुछ अन्य संवर्द्धन" के रूप में सुधारों के विवरण के साथ एक पैच [+5000; -3500] भेजते हैं, तो हर कोई इसे स्वयं समझ लेगा, और साथ ही यह समझ जाएगा कि आप कितने अच्छे हैं।

कभी भी परीक्षण न चलाएं

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

कैसे पढ़ें कभी नहीं

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

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

सार्वजनिक एपीआई को जटिल बनाने के लिए स्वतंत्र महसूस करें

नए सार्वजनिक एपीआई को विकसित करते समय, इसे यथासंभव सार और जटिल बनाने का प्रयास करें। एपीआई के गैर-स्पष्ट व्यवहार के बारे में किसी भी उपयोगकर्ता के सवालों का हमेशा जवाब दिया जा सकता है: “क्या आपने मैनुअल नहीं पढ़ा है? पृष्ठ 42, सब कुछ स्पष्ट रूप से लिखा गया है! इसे फिर से पढ़ें! ” गंभीर परियोजनाओं में, सब कुछ जटिल होना चाहिए। हमारे पास एक गंभीर परियोजना है?

समस्याओं के बारे में सलाह या बात न करें

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

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

एक बहुत अच्छा समीक्षक सब कुछ पा लेगा और वह आपसे विवरण मांगेगा। किसी भी मामले में उसे कुछ भी न बताएं।

यदि आपके कोई प्रश्न हैं, तो देव-सूची में लिखें

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

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

"मैं कार्य कैसे करूँ?" - एक और बढ़िया सवाल। किसी भी मामले में किसी भी विवरण को इंगित न करें: कार्य आईडी पर्याप्त होगा। सभी को इसकी आवश्यकता है जो अपने लिए देखेंगे।

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

एक पुल अनुरोध में सभी परियोजना समस्याओं को ठीक करें

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

• सभी मौजूदा कोड को रिफलेक्टर करें जिन्हें आप नहीं समझते हैं;
  
• अपनी राय में, सभी का नाम बदलकर, गलत तरीके से नामित चर;
  
• सभी मौजूदा javadoc टिप्पणियों को ठीक करें।
  

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

अग्रिम में एक कोड समीक्षा का अनुरोध करें

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

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

कार्य से थक गए - इसे छोड़ दें

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

समीक्षक आपका दुश्मन है

और उस व्यक्ति का नाम क्या है जो आपके और स्वामी के बीच खड़ा है? कोड की आलोचना व्यक्तिगत रूप से आपकी आलोचना है! वह कौन लगता है कि वह है? व्यक्तिगत संचार में, "बम" जितना संभव हो सके! अन्यथा, समीक्षक कैसे जानता है कि आप परवाह करते हैं? यह विकास का मूल नियम है!

मैं रोज़मर्रा के विकास में इस सलाह की सिफारिश करता हूं। यह परिणाम प्राप्त करने और सही करने में मदद करता है।

समीक्षक के लिए बुरी सलाह

नियमित जांच को स्वचालित न करें

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

• कोड स्वरूपण;
  
• चर नामकरण;
  
• जाँच करता है कि क्या उन चर को अंतिम रूप से चिह्नित किया गया है, जिन्हें उनके द्वारा चिह्नित किया जा सकता है;
  
• ... और सब कुछ।
  

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

बहुत अंत तक खेल के सभी नियमों को कभी भी प्रकट न करें।

आगे रहने के लिए, आपको हमेशा अपनी आस्तीन पर इक्के की एक जोड़ी रखने की जरूरत है। पिछड़े अनुकूलता की आवश्यकता के बारे में किसी को न बताएं। कमिटमेंट से ठीक पहले कहना बेहतर होगा: “यहाँ, हमारे नियमों के अनुसार, पिछड़ी संगतता सुनिश्चित की जानी चाहिए। कृपया सही करें। ” यदि आप पहले से ही पांच बार समीक्षा कर चुके हैं तो यह विशेष रूप से प्रभावी होगा। छठे पर अभी भी कह सकते हैं: "मैं एक विशेषज्ञ नहीं हूं, इसलिए आपको श्री एक्स की समीक्षा की प्रतीक्षा करने की आवश्यकता है, जो फिर से देखेंगे।"

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

भावनाओं, अधिकारियों और धन्यवाद नहीं

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

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

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

अब गंभीरता से: कोड की समीक्षा तैयार करते और करते समय आपको क्या सोचना चाहिए?

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



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

सामान्य ज्ञान का उपयोग करें

यह सबसे महत्वपूर्ण सलाह है। सामान्य ज्ञान का उपयोग करें, यह स्टीयर करता है। यह मुझे लगता है कि यह सलाह सभी जीवन स्थितियों पर लागू होती है। यदि आप कुछ कर रहे हैं, तो विचार करें कि क्या यह सामान्य ज्ञान के सरल नियम से मिलता है?

मान लें ...

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

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

उत्पाद क्या मूल्य लाएगा?

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

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

अन्य विकल्प हैं। किसी भी मामले में, किसी समस्या को हल करने के लिए कुछ विकसित करना शुरू करना, आपको यह समझना चाहिए कि आप परियोजना में किस मूल्य को जोड़ेंगे।

पुनरीक्षण (सुविधा) ऐसा क्यों है?

कई उपयोगी प्रश्न पूछने हैं।

एक सुविधा क्यों बनाते हैं? इस सुविधा की आवश्यकता क्यों है? इस प्रश्न का उत्तर महत्वपूर्ण है।

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

काम पूरा होने की बात कहां है? काम को आदर्श कैसे बनाया जाना चाहिए? जहाँ आप जा रहे हैं, वहाँ शुरू से ही तैयार करना महत्वपूर्ण है।

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

इस तरह के चरणों में सुविधा क्यों टूट गई है? यह एमवीपी और उस सब के बारे में है। कृपया इस बारे में भी सोचें।

अब सार्वजनिक एपीआई के बारे में

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

सार्वजनिक एपीआई केवल तीसरे पक्ष के उपयोगकर्ताओं के लिए एक उपकरण नहीं है। यह और आंतरिक घटकों का एपीआई, जिसे आप स्वयं आपस में पुन: उपयोग करते हैं। सार्वजनिक एपीआई के महत्वपूर्ण गुण:

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

सबसिस्टम परिवर्तन

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

एक बॉक्सिंग उत्पाद के साथ काम करते समय, अपने आप से सवाल पूछना जरूरी है: परिवर्तन सिस्टम में मौजूदा प्रक्रियाओं को कैसे प्रभावित करते हैं? क्या एक पिछड़ी संगतता है? क्या यह प्रदर्शन को प्रभावित करता है? अगर यह प्रभावित करता है, तो क्या प्रदर्शन? यह उपयोगकर्ता के अनुभव को कैसे प्रभावित करता है?

मानक प्रणाली प्रक्रियाएं

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

• नोड स्टार्ट / स्टॉप (सर्वर / क्लाइंट, समन्वयक / नियमित) - प्रारंभ, एक नोड को रोकें, एक सर्वर या क्लाइंट नोड शुरू करें, एक समन्वयक या एक सामान्य नोड शुरू करें
  
• नोड जॉइन - एक नए नोड / समन्वयक / सर्वर / क्लाइंट के संदर्भ में
  
• क्लस्टर सक्रियण (और निष्क्रिय करना)
  
• समन्वयक का परिवर्तन
  
• कैश बनाएँ / हटाएं
  
• दृढ़ता / बीएलटी / एमवीसीसी
  

यह स्पष्ट है कि इन प्रक्रियाओं का सेट काफी बड़ा है। यह समझना महत्वपूर्ण है कि ऐसी प्रक्रियाएं मौजूद हैं और वे कैसे बदलती हैं।

कोने के मामले

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

• समन्वयक का परिवर्तन;
  
• नोड ड्रॉप;
  
• नेटवर्क समस्याएं - जब नेटवर्क संदेश नहीं पहुंचते हैं;
  
• टूटी हुई फाइलें।
  

हमें इन चीजों की जांच और सत्यापन करना होगा कि सब कुछ क्रम में है।

अच्छा कोड सुविधाएँ

तो हमें कोड मिला। मैं आपको सलाह देता हूं कि आप आलसी न हों और इसमें तलाश करें:

• सादगी,
  
• तानाना
  
• testability,
  
• विश्वसनीयता
  
• काम की उच्च गति।
  

संगामिति

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

• अपने संगामिति मॉडल को समझना कितना कठिन है?
  
• साझा डेटा संरचना - उनकी अखंडता की गारंटी कैसे दी जाती है?
  
• ताले - क्या और क्यों?
  
• थ्रेड्स - कौन से पूल का उपयोग किया जाता है? क्यों?
  
• परिवर्तनों की दृश्यता की गारंटी - वे किस लिए प्रदान किए जाते हैं?
  

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

प्रदर्शन परीक्षण। मानक

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

• क्या प्रदर्शन परीक्षण बिल्कुल आवश्यक है? शायद यह किसी प्रकार का परिशोधन है जिसे प्रदर्शन परीक्षणों की आवश्यकता नहीं है?
  
• यदि आवश्यक हो, तो कौन सा? कई माप तकनीक और तरीके हैं, आदि।
  
• कहां-कैसे-कैसे मापे जाने की जरूरत है?
  
• संकेत क्या संकेत हैं? नोड्स की संख्या? आयरन? प्रज्वलित विन्यास? लोड की प्रकृति?
  

कुल मिलाकर

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

व्याख्यान का वीडियो:

यहां प्रस्तुति उपलब्ध है ।