कोड निरीक्षण। परिणाम

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

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

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

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

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

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

कोड आधार अधिक हो गया है "का पालन किया । " यहां सुधारों की एक सूची दी गई है:

• जादू स्थिरांक परीक्षकों द्वारा अवरुद्ध होते हैं;
• कमी हुई कोड दोहराव (DRY);
• एल्गोरिदम सरल (चुंबन) कर रहे हैं;
• कक्षाओं और सार्वजनिक तरीकों के प्रलेखन में काफी सुधार हुआ है (लगभग हर सार्वजनिक वर्ग और विधि के लिए, निरीक्षकों को प्रलेखन को जोड़ने की आवश्यकता होती है);

कोड निरीक्षणों को लागू करने का एकमात्र दोष विकास के समय में वृद्धि है। कार्यान्वयन के प्रारंभिक चरण में, समय 50-100% बढ़ गया (कभी-कभी यह अधिक हुआ), लेकिन परिणामस्वरूप, समग्र रिपॉजिटरी बहुत कम गुणवत्ता वाले कोड, कम "स्लैग" बन गई है।

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

चेकलिस्ट

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

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

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

चेकलिस्ट - इंस्पेक्टर मेमो पॉजिटिव टेक्नोलॉजीज

1. विषय क्षेत्र के कार्यान्वयन की शुद्धता।

• कार्यक्षमता पूरी तरह से लागू है।
• विनिर्देशों के साथ अनुपालन।
• दिए गए स्थिरांक की निष्ठा।
• बनी मान्यताओं और समझौतों की वैधता।
• सही प्रसंस्करण अनुक्रम।

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

3. परीक्षण कवरेज की उपस्थिति और पूर्णता।

• सभी सार्वजनिक वर्गों और विधियों का परीक्षण किया जाता है।
• सीमा की स्थितियों का परीक्षण किया जाता है।
• निष्पादन की "सकारात्मक शाखाओं" के परीक्षण की पर्याप्तता।
• निष्पादन की "नकारात्मक शाखाओं" के परीक्षण की पर्याप्तता।

4. यह आपके गुल्लक में किसी और के कोड से अच्छी प्रथाओं को जोड़ने के लायक है।

5. बहु-थ्रेडेड कोड की शुद्धता।

• साझा डेटा तक पहुंच सिंक्रनाइज़ है।
• गतिरोध गायब है।
• सिंक्रनाइज़ेशन के लिए, मुहावरा RAII का उपयोग किया जाता है।
• त्रुटि हैंडलर में संसाधनों की वापसी सही ढंग से नियंत्रित की जाती है।
• कोई संसाधन रिसाव नहीं।

6. कोड संभावित त्रुटियों को सही ढंग से संभालता है।

7. सिस्टम के अन्य हिस्सों में कोई भी अवांछित अवांछित दुष्प्रभाव नहीं।

8. भाषा निर्माणों की शुद्धता।

• भाषा के सही मुहावरों और उपयोग की जाने वाली रूपरेखा को लागू किया जाता है।
• सही पुस्तकालयों का उपयोग करना।
• नए आविष्कृत "साइकिल" का अभाव।
• कोई कोड दोहराव नहीं।

9. सभी चर सही मानों के साथ शुरू होते हैं।

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

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

आपका ध्यान के लिए धन्यवाद! हम आपके सुखद निरीक्षण की कामना करते हैं :)