टीम विकास में स्थिर कोड विश्लेषण का नियमित उपयोग

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

अमूर्त

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



लेख टीम विकास में स्थिर कोड विश्लेषण की तकनीकों का उपयोग करने के विभिन्न स्तरों पर चर्चा करता है, दिखाता है कि प्रक्रिया को एक स्तर से दूसरे स्तर पर "कैसे स्थानांतरित" किया जाए। एक उदाहरण के रूप में, लेख लेखकों द्वारा विकसित पीवीएस-स्टूडियो कोड विश्लेषक का उपयोग करता है।

परिचय

Static code विश्लेषक स्रोत कोड में सॉफ़्टवेयर त्रुटियों को खोजने के लिए एक उपकरण है। इस तरह के उपकरण का उपयोग विकास चरण में सॉफ़्टवेयर त्रुटियों का पता लगाने से बचने में मदद करता है, न कि परीक्षण या उपयोग के चरणों में।



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



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

स्थिर कोड विश्लेषण क्या है?

स्टेटिक कोड विश्लेषण, स्रोत कोड को पार्स करके और उसमें ज्ञात त्रुटियों के पैटर्न (टेम्प्लेट) की खोज करके कार्यक्रमों में त्रुटियों को खोजने की एक तकनीक है। यह तकनीक विशेष उपकरण द्वारा कार्यान्वित की जाती है जिसे स्टैटिक कोड एनालाइज़र कहा जाता है।



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



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



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



स्थिर कोड विश्लेषण के लिए उपकरण समर्थित प्रोग्रामिंग भाषाओं (जावा, सी #, सी, सी ++) के प्रकार, निदान की गई समस्याओं (सामान्य-उद्देश्य विश्लेषक या विशेष वाले, उदाहरण के लिए, 64-बिट या समानांतर कार्यक्रमों के विकास के लिए) द्वारा विभाजित हैं।

किन परियोजनाओं के लिए स्थैतिक कोड विश्लेषण प्रासंगिक है

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

स्थिर कोड विश्लेषक का उपयोग करने के भिन्न (परिदृश्य)

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



तो, मान लीजिए 5 लोगों की एक टीम 64-बिट कंप्यूटर पर काम करने के लिए एक सॉफ्टवेयर प्रोजेक्ट के लिए कोड के हस्तांतरण में शामिल है। यह भी मान लें कि प्रोजेक्ट कोड C / C ++ में लिखा गया है। हम पहले से कहते हैं कि इस तरह के पूर्वापेक्षाएँ उदाहरण में हमारे पीवीएस-स्टूडियो कोड विश्लेषक का उपयोग करने के लिए बनाई गई हैं। डेवलपर्स ने मुख्य संकलन त्रुटियों को ठीक किया, आवेदन, वितरण किट को इकट्ठा किया। उन्होंने परीक्षण शुरू किया और पता चला कि कार्यक्रम में अत्यंत रहस्यमय त्रुटियां हैं जो केवल कार्यक्रम के 64-बिट संस्करण में दिखाई देती हैं। डेवलपर्स Google पर जाते हैं, "++ मुद्दों के साथ 64-बिट प्लेटफ़ॉर्म" को पेश करते हैं और पहले पृष्ठ पर 8.5 मिलियन परिणामों के बीच वे हमारे लेख का लिंक पाते हैं "64-बिट प्लेटफॉर्म पर C ++ कोड को पोर्ट करने के 20 मुद्दे" (रूसी संस्करण में) 20 जाल C ++ कोड को 64-बिट प्लेटफ़ॉर्म पर "पोर्ट करना"), जिसमें से वे सीखते हैं कि 64-बिट प्रोग्राम्स को विकसित करते समय C / C ++ एप्लिकेशन में क्या होता है, विभिन्न पूर्व अदृश्य समस्याएँ दिखाई देती हैं। वहां उन्हें पता चलता है कि पीवीएस-स्टूडियो उपकरण है जो आपको इन समस्याओं को खोजने और ठीक करने की अनुमति देगा। इसके बाद, डेवलपर्स टूल को डाउनलोड करते हैं, मूल्यांकन संस्करण को देखते हैं, अगर यह उनके अनुरूप है, तो वे एक लाइसेंस खरीदते हैं, अपने कोड में कुछ त्रुटियों को खोजने के लिए टूल का उपयोग करते हैं, उन्हें ठीक करते हैं, और प्रोग्राम बिना त्रुटियों के निकलता है। उसके बाद, डेवलपर्स कार्यक्रम के 64-बिट संस्करण को पूरा करने के कार्य को मानते हैं और फिर विश्लेषक का उपयोग करने से इनकार करते हैं, क्योंकि वे मानते हैं कि उन्हें अब इसकी आवश्यकता नहीं है।



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



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



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

क्या एक स्थिर कोड विश्लेषक के पूर्ण उपयोग को रोकता है

हम कारण बताते हैं कि स्थैतिक विश्लेषण का उपयोग करने के लिए उपरोक्त तीन विकल्प सफल मामले नहीं हैं।



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



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



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



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

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

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



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

निष्कर्ष

यदि आपकी कंपनी स्थिर कोड विश्लेषण का उपयोग करने की योजना बना रही है, तो निम्नलिखित पर विचार करें:

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