लीगेसी प्रोजेक्टमध्ये टीमला डिमोटिव्ह न करता स्टॅटिक कोड अॅनालायझर कसे अंमलात आणायचे

स्थिर कोड विश्लेषक वापरून पाहणे सोपे आहे. परंतु त्याची अंमलबजावणी करण्यासाठी, विशेषत: मोठ्या जुन्या प्रकल्पाच्या विकासासाठी, कौशल्य आवश्यक आहे. चुकीच्या पद्धतीने केले असल्यास, विश्लेषक कार्य जोडू शकतो, विकास कमी करू शकतो आणि संघाला कमी करू शकतो. विकास प्रक्रियेत स्थिर विश्लेषणाचे एकत्रीकरण कसे करावे आणि ते CI/CD चा भाग म्हणून कसे वापरावे याबद्दल थोडक्यात चर्चा करूया.

परिचय

अलीकडेच माझे लक्ष प्रकाशनाकडे वेधले गेले "संघाला दडपल्याशिवाय स्थिर विश्लेषणासह प्रारंभ करणे". एकीकडे, हा एक चांगला लेख आहे जो परिचित होण्यास योग्य आहे. दुसरीकडे, मला असे वाटते की ते अद्यापही एका प्रकल्पात स्थिर विश्लेषण कसे वेदनारहितपणे लागू करायचे याचे संपूर्ण उत्तर देत नाही. लेगसी कोडचा लेख म्हणतो की तुम्ही तांत्रिक कर्ज स्वीकारू शकता आणि फक्त नवीन कोडवर काम करू शकता, परंतु या तांत्रिक कर्जाचे नंतर काय करायचे याचे उत्तर नाही.

आमची PVS-स्टुडिओ टीम या विषयावर आपले मत मांडते. स्टॅटिक कोड विश्लेषक लागू करण्याची समस्या प्रथम कशी उद्भवते, या समस्येवर मात कशी करायची आणि तांत्रिक कर्जे हळूहळू कशी दूर करायची ते पाहू या.

मुद्दे

स्थिर विश्लेषक कसे कार्य करते ते लाँच करणे आणि पाहणे सहसा कठीण नसते [1]. तुम्हाला कोडमध्ये मनोरंजक त्रुटी किंवा भयानक संभाव्य भेद्यता दिसू शकतात. आपण काहीतरी निराकरण देखील करू शकता, परंतु नंतर बरेच प्रोग्रामर सोडून देतात.

सर्व स्थिर विश्लेषक खोटे सकारात्मक उत्पन्न करतात. हे स्थिर कोड विश्लेषण पद्धतीचे वैशिष्ट्य आहे आणि त्याबद्दल काहीही केले जाऊ शकत नाही. सर्वसाधारण बाबतीत, ही एक न सोडवता येणारी समस्या आहे, ज्याची पुष्टी राइसच्या प्रमेयाने केली आहे [2]. मशीन लर्निंग अल्गोरिदम देखील मदत करणार नाहीत [3]. जरी एखादी व्यक्ती हा किंवा तो कोड चुकीचा आहे की नाही हे नेहमी सांगू शकत नसला तरीही, आपण प्रोग्रामकडून याची अपेक्षा करू नये :).

जर स्थिर विश्लेषक आधीच कॉन्फिगर केले असेल तर खोटे सकारात्मक समस्या नाहीत:

• अक्षम असंबद्ध नियम संच;
• काही असंबद्ध निदान अक्षम केले गेले आहेत;
• जर आपण C किंवा C++ बद्दल बोलत असाल, तर मॅक्रो चिन्हांकित केले जातात ज्यामध्ये विशिष्ट रचना असतात ज्यामुळे अशा मॅक्रो वापरल्या जातात त्या प्रत्येक ठिकाणी निरुपयोगी इशारे दिसू लागतात;
• स्वतःची फंक्शन्स चिन्हांकित केली जातात जी सिस्टम फंक्शन्स प्रमाणेच क्रिया करतात (त्याचे स्वतःचे ॲनालॉग मेमकपी किंवा printf) [4];
• खोटे सकारात्मक विशेषतः टिप्पण्या वापरून अक्षम केले जातात;
• आणि याप्रमाणे.

या प्रकरणात, आम्ही सुमारे 10-15% कमी खोट्या सकारात्मक दराची अपेक्षा करू शकतो [5]. दुसऱ्या शब्दांत, 9 पैकी 10 विश्लेषक चेतावणी कोडमधील खरी समस्या किंवा किमान "तीव्र वास असलेला कोड" दर्शवतील. सहमत आहे, ही परिस्थिती अत्यंत आनंददायी आहे आणि विश्लेषक हा प्रोग्रामरचा खरा मित्र आहे.

प्रत्यक्षात, मोठ्या प्रकल्पात, प्रारंभिक चित्र पूर्णपणे भिन्न असेल. विश्लेषक लेगसी कोडसाठी शेकडो किंवा हजारो चेतावणी जारी करतात. यापैकी कोणते इशारे संबंधित आहेत आणि कोणते नाहीत हे पटकन समजणे अशक्य आहे. बसून या सर्व इशाऱ्यांना सामोरे जाणे अतार्किक आहे, कारण या प्रकरणात मुख्य काम काही दिवस किंवा आठवडे थांबेल. सामान्यतः, संघाला अशी परिस्थिती परवडत नाही. बदलाचा इतिहास खराब करणाऱ्या मोठ्या संख्येने मतभेद देखील असतील. आणि कोडमधील अनेक तुकड्यांचे जलद मोठ्या प्रमाणावर संपादन केल्याने अपरिहार्यपणे नवीन टायपो आणि त्रुटी निर्माण होतील.

आणि सर्वात महत्त्वाचे म्हणजे, चेतावणींविरूद्धच्या लढाईत अशा पराक्रमाला काही अर्थ नाही. सहमत आहे की हा प्रकल्प अनेक वर्षांपासून यशस्वीरित्या चालत असल्याने, त्यातील बहुतेक गंभीर त्रुटी आधीच दुरुस्त केल्या गेल्या आहेत. होय, हे निराकरण खूप महाग होते, त्यांना डीबग करावे लागले, बगबद्दल नकारात्मक वापरकर्त्याचा अभिप्राय प्राप्त झाला आणि असेच बरेच काही. एक स्थिर विश्लेषक यापैकी बऱ्याच त्रुटी कोडिंग टप्प्यावर, जलद आणि स्वस्तपणे दुरुस्त करण्यात मदत करेल. परंतु या क्षणी, एक किंवा दुसर्या मार्गाने, या त्रुटी निश्चित केल्या गेल्या आहेत आणि विश्लेषक मुख्यत्वे जुन्या कोडमधील गैर-गंभीर त्रुटी शोधतो. हा कोड वापरला जाऊ शकत नाही, तो फार क्वचितच वापरला जाऊ शकतो आणि त्यातील त्रुटीमुळे लक्षात येण्याजोगे परिणाम होऊ शकत नाहीत. कदाचित कुठेतरी बटणाची सावली चुकीचा रंग आहे, परंतु यामुळे कोणाच्याही उत्पादनाच्या वापरामध्ये व्यत्यय येत नाही.

अर्थात, अगदी किरकोळ चुका अजूनही चुका आहेत. आणि काहीवेळा चूक खरी भेद्यता लपवू शकते. तथापि, सर्वकाही सोडून देणे आणि स्वतःला क्वचितच प्रकट होणाऱ्या दोषांना सामोरे जाण्यासाठी दिवस/आठवडे घालवणे ही एक संशयास्पद कल्पना दिसते.

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

त्यांच्या स्वत: च्या मार्गाने, ते बरोबर आहेत. त्यांना असे वाटते की प्रथम त्यांना या सर्व इशाऱ्यांपासून मुक्त करावे लागेल. तरच त्यांना कोड ॲनालायझरच्या नियमित वापराचा फायदा मिळू शकेल. अन्यथा, नवीन इशारे जुन्यामध्ये बुडतील आणि कोणीही त्यांच्याकडे लक्ष देणार नाही.

हे कंपाइलर चेतावणी प्रमाणेच समानता आहे. कंपाइलर चेतावणींची संख्या 0 वर ठेवण्याची शिफारस ते करतात हे विनाकारण नाही. जर 1000 चेतावणी असतील, तर 1001 असतील तेव्हा कोणीही त्याकडे लक्ष देणार नाही आणि ही नवीन चेतावणी कोठे शोधायची हे स्पष्ट नाही.

या कथेतील सर्वात वाईट गोष्ट म्हणजे या क्षणी वरून कोणीतरी तुम्हाला स्थिर कोड विश्लेषण वापरण्यास भाग पाडत असेल. हे केवळ संघाला निराश करेल, कारण त्यांच्या दृष्टिकोनातून अतिरिक्त नोकरशाही जटिलता असेल जी केवळ मार्गात येते. कोणीही विश्लेषकाच्या अहवालाकडे पाहणार नाही आणि सर्व वापर फक्त "कागदावर" असेल. त्या. औपचारिकपणे, विश्लेषण हे DevOps प्रक्रियेमध्ये तयार केले जाते, परंतु व्यवहारात याचा कोणालाच फायदा होत नाही. आम्ही परिषदेच्या उपस्थितांकडून बूथवर तपशीलवार कथा ऐकल्या. असा अनुभव प्रोग्रामरना दीर्घकाळ स्थिर विश्लेषण साधने वापरण्यापासून परावृत्त करू शकतो, जर कायमचा नाही.

तांत्रिक कर्जाची अंमलबजावणी आणि निर्मूलन

खरं तर, एका मोठ्या जुन्या प्रकल्पातही स्थिर विश्लेषणाचा परिचय करून देण्यात काही अवघड किंवा भितीदायक नाही.

सीआय / सीडी

शिवाय, विश्लेषक त्वरित सतत विकास प्रक्रियेचा भाग बनविला जाऊ शकतो. उदाहरणार्थ, PVS-स्टुडिओ वितरणामध्ये तुम्हाला आवश्यक असलेल्या फॉरमॅटमध्ये अहवाल सोयीस्करपणे पाहण्यासाठी उपयुक्तता आणि कोडचे समस्याप्रधान विभाग लिहिलेल्या विकासकांना सूचना आहेत. ज्यांना CI/CD सिस्टीमवरून PVS-Studio लाँच करण्यात अधिक स्वारस्य आहे त्यांच्यासाठी, मी शिफारस करतो की तुम्ही स्वतःला संबंधितांशी परिचित व्हा विभाग दस्तऐवजीकरण आणि लेखांची मालिका:

• PVS-स्टुडिओ ढगांवर जातो: Azure Devops
• पीव्हीएस-स्टुडिओ ढगांवर जातो: ट्रॅव्हिस सीआय
• PVS-स्टुडिओ क्लाउडवर जातो: GitLab CI/CD
• PVS-स्टुडिओ ढगांवर जातो: CircleCI

परंतु कोड विश्लेषण साधनांच्या अंमलबजावणीच्या पहिल्या टप्प्यावर मोठ्या संख्येने खोट्या सकारात्मकतेच्या मुद्द्यावर परत येऊ.

विद्यमान तांत्रिक कर्ज निश्चित करणे आणि नवीन इशारे हाताळणे

आधुनिक व्यावसायिक स्थिर विश्लेषक तुम्हाला नवीन किंवा बदललेल्या कोडमध्ये दिसणाऱ्या केवळ नवीन चेतावणींचा अभ्यास करण्याची परवानगी देतात. या यंत्रणेची अंमलबजावणी बदलते, परंतु सार समान आहे. पीव्हीएस-स्टुडिओ स्टॅटिक ॲनालायझरमध्ये, ही कार्यक्षमता खालीलप्रमाणे लागू केली जाते.

स्थिर विश्लेषणाचा वापर त्वरीत सुरू करण्यासाठी, आम्ही सुचवितो की पीव्हीएस-स्टुडिओ वापरकर्त्यांनी चेतावणी मोठ्या प्रमाणात दाबण्यासाठी यंत्रणा वापरावी [6]. सर्वसाधारण कल्पना खालीलप्रमाणे आहे. वापरकर्त्याने विश्लेषक लाँच केले आणि अनेक इशारे प्राप्त केले. अनेक वर्षांपासून विकासात असलेला प्रकल्प जिवंत, विकसनशील आणि पैसे कमावणारा असल्याने, बहुधा अहवालात गंभीर दोष दर्शविणारे अनेक इशारे नसतील. दुसऱ्या शब्दांत, अधिक महाग पद्धती वापरून किंवा ग्राहकांच्या अभिप्रायामुळे गंभीर बग आधीच एक किंवा दुसर्या मार्गाने निश्चित केले गेले आहेत. त्यानुसार, विश्लेषकाने सध्या शोधलेल्या प्रत्येक गोष्टीला तांत्रिक कर्ज मानले जाऊ शकते, जे ताबडतोब दूर करण्याचा प्रयत्न करणे अव्यवहार्य आहे.

तुम्ही PVS-Studio ला या इशाऱ्यांना सध्या अप्रासंगिक मानण्यास सांगू शकता (नंतरसाठी तांत्रिक कर्ज जतन करा), आणि ते यापुढे त्यांना दाखवणार नाही. विश्लेषक एक विशेष फाइल तयार करतो जिथे तो अद्याप मनोरंजक नसलेल्या त्रुटींबद्दल माहिती जतन करतो. आणि आता PVS-Studio फक्त नवीन किंवा बदललेल्या कोडसाठी चेतावणी जारी करेल. शिवाय हे सर्व हुशारीने राबवले जाते. जर, उदाहरणार्थ, स्त्रोत कोड फाइलच्या सुरूवातीस रिक्त ओळ जोडली गेली असेल, तर विश्लेषकाला समजते की, प्रत्यक्षात काहीही बदललेले नाही आणि ते शांत राहतील. ही मार्कअप फाइल आवृत्ती नियंत्रण प्रणालीमध्ये ठेवली जाऊ शकते. फाईल मोठी आहे, परंतु ही समस्या नाही, कारण ती बर्याचदा संग्रहित करण्यात काही अर्थ नाही.

आता सर्व प्रोग्रामर फक्त नवीन किंवा बदललेल्या कोडशी संबंधित चेतावणी पाहतील. अशा प्रकारे, आपण विश्लेषक वापरणे सुरू करू शकता, जसे ते म्हणतात, दुसऱ्या दिवसापासून. आणि आपण नंतर तांत्रिक कर्जावर परत येऊ शकता आणि हळूहळू त्रुटी सुधारू शकता आणि विश्लेषक कॉन्फिगर करू शकता.

तर, मोठ्या जुन्या प्रकल्पात विश्लेषकांच्या अंमलबजावणीची पहिली समस्या सोडवली गेली आहे. आता तांत्रिक कर्जाचे काय करायचे ते शोधूया.

दोष निराकरणे आणि रीफॅक्टरिंग

सर्वात सोपी आणि सर्वात नैसर्गिक गोष्ट म्हणजे मोठ्या प्रमाणावर दाबलेल्या विश्लेषक चेतावणींचे विश्लेषण करण्यासाठी थोडा वेळ बाजूला ठेवणे आणि हळूहळू त्यांना सामोरे जाणे. कुठेतरी तुम्ही कोडमधील त्रुटी दूर कराव्यात, कुठेतरी तुम्ही विश्लेषकाला कोड समस्याप्रधान नाही हे सांगण्यासाठी रिफॅक्टर केले पाहिजे. साधे उदाहरण:

if (a = b)

बहुतेक C++ संकलक आणि विश्लेषक अशा कोडबद्दल तक्रार करतात, कारण त्यांना खरोखर लिहायचे होते अशी उच्च संभाव्यता आहे (a == b). परंतु एक न बोललेला करार आहे, आणि हे सहसा दस्तऐवजीकरणात नोंदवले जाते, की जर तेथे अतिरिक्त कंस असतील तर असे मानले जाते की प्रोग्रामरने मुद्दाम असा कोड लिहिला आहे आणि शपथ घेण्याची गरज नाही. उदाहरणार्थ, निदानासाठी पीव्हीएस-स्टुडिओ दस्तऐवजीकरणात V559 (CWE-481) हे स्पष्टपणे लिहिले आहे की खालील ओळ योग्य आणि सुरक्षित मानली जाईल:

if ((a = b))

दुसरे उदाहरण. या C++ कोडमध्ये ते विसरले आहे का? ब्रेक किंवा नाही?

case A:
  foo();
case B:
  bar();
  break;

PVS-स्टुडिओ विश्लेषक येथे एक चेतावणी जारी करेल V796 (CWE-484). ही त्रुटी असू शकत नाही, अशा परिस्थितीत तुम्ही विशेषता जोडून पार्सरला इशारा द्यावा. [[पडणे]] किंवा, उदाहरणार्थ, __विशेषता__((फॉलथ्रू)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

असे म्हटले जाऊ शकते की असे कोड बदल बगचे निराकरण करत नाहीत. होय, हे खरे आहे, परंतु ते दोन उपयुक्त गोष्टी करते. प्रथम, विश्लेषक अहवाल खोट्या सकारात्मकतेपासून मुक्त होतो. दुसरे म्हणजे, कोड त्याच्या देखभालीमध्ये गुंतलेल्या लोकांसाठी अधिक समजण्यायोग्य बनतो. आणि हे खूप महत्वाचे आहे! फक्त यासाठी, कोड स्पष्ट आणि देखरेख करणे सोपे करण्यासाठी किरकोळ रिफॅक्टरिंग करणे फायदेशीर आहे. विश्लेषकाला "ब्रेक" आवश्यक आहे की नाही हे समजत नसल्यामुळे, हे सहकारी प्रोग्रामरसाठी देखील अस्पष्ट असेल.

दोष निराकरणे आणि रीफॅक्टरिंग व्यतिरिक्त, तुम्ही स्पष्टपणे चुकीचे विश्लेषक चेतावणी दडपून टाकू शकता. काही असंबद्ध निदान अक्षम केले जाऊ शकते. उदाहरणार्थ, एखाद्याला वाटते की इशारे निरर्थक आहेत V550 फ्लोट/दुहेरी मूल्यांची तुलना करण्याबद्दल. आणि काही त्यांचे वर्गीकरण महत्त्वाचे आणि अभ्यासासाठी योग्य म्हणून करतात [7]. कोणते इशारे संबंधित मानले जातात आणि कोणते नाहीत हे विकास कार्यसंघाने ठरवायचे आहे.

खोट्या सूचना दडपण्याचे इतर मार्ग आहेत. उदाहरणार्थ, मॅक्रो मार्कअपचा उल्लेख आधी केला होता. हे सर्व दस्तऐवजीकरणात अधिक तपशीलवार वर्णन केले आहे. सर्वात महत्वाची गोष्ट हे समजून घेणे आहे की जर तुम्ही हळूहळू आणि पद्धतशीरपणे चुकीच्या सकारात्मक गोष्टींसह कार्य करत असाल तर त्यात काहीही चुकीचे नाही. कॉन्फिगरेशननंतर बहुसंख्य रस नसलेल्या चेतावणी अदृश्य होतात आणि ज्या ठिकाणी खरोखर काळजीपूर्वक अभ्यास करणे आवश्यक आहे आणि कोडमधील काही बदल शिल्लक आहेत.

तसेच, काही अडचणी आल्यास आम्ही आमच्या ग्राहकांना PVS-Studio सेट करण्यात नेहमी मदत करतो. शिवाय, अशी प्रकरणे होती जेव्हा आम्ही स्वतः खोट्या चेतावणी काढून टाकल्या आणि चुका सुधारल्या [8]. फक्त बाबतीत, मी हे नमूद करण्याचा निर्णय घेतला की विस्तारित सहकार्यासाठी हा पर्याय देखील शक्य आहे :).

रॅचेट पद्धत

स्थिर विश्लेषक चेतावणी काढून टाकून कोड गुणवत्ता हळूहळू सुधारण्यासाठी आणखी एक मनोरंजक दृष्टीकोन आहे. तळ ओळ अशी आहे की चेतावणींची संख्या फक्त कमी होऊ शकते.

स्थिर विश्लेषकाद्वारे जारी केलेल्या चेतावणींची संख्या रेकॉर्ड केली जाते. गुणवत्ता गेट अशा प्रकारे कॉन्फिगर केले आहे की आता आपण फक्त एक कोड प्रविष्ट करू शकता जो ऑपरेशन्सची संख्या वाढवत नाही. परिणामी, ॲनालायझर समायोजित करून आणि चुका सुधारून हळूहळू अलार्मची संख्या कमी करण्याची प्रक्रिया सुरू होते.

जरी एखाद्या व्यक्तीला थोडीशी फसवणूक करायची असेल आणि त्याने त्याच्या नवीन कोडमधील इशारे काढून टाकून नव्हे तर जुन्या तृतीय-पक्षाच्या कोडमध्ये सुधारणा करून गुणवत्ता गेट पार करण्याचा निर्णय घेतला तरीही हे भयानक नाही. सर्व समान, रॅचेट एका दिशेने फिरते आणि हळूहळू दोषांची संख्या कमी होईल. जरी एखाद्या व्यक्तीला स्वतःचे नवीन दोष दुरुस्त करायचे नसले तरीही त्याला शेजारच्या कोडमध्ये काहीतरी सुधारावे लागेल. काही क्षणी, चेतावणींची संख्या कमी करण्याचे सोपे मार्ग संपतात आणि एक बिंदू येतो जेव्हा वास्तविक दोष निश्चित केले जातील.

इव्हान पोनोमारेव्हच्या एका अतिशय मनोरंजक लेखात या पद्धतीचे अधिक तपशीलवार वर्णन केले आहे "बग शोधण्यासाठी ते वापरण्याऐवजी प्रक्रियेमध्ये स्थिर विश्लेषण लागू करा", जे मी कोड गुणवत्ता सुधारण्यात स्वारस्य असलेल्या कोणालाही वाचण्याची शिफारस करतो.

लेखाच्या लेखकाकडे या विषयावर एक अहवाल देखील आहे: "सतत स्थिर विश्लेषण".

निष्कर्ष

मला आशा आहे की या लेखानंतर, वाचक स्थिर विश्लेषण साधनांचा अधिक स्वीकार करतील आणि विकास प्रक्रियेत त्यांची अंमलबजावणी करू इच्छित असतील. आपल्याला काही प्रश्न असल्यास, आम्ही नेहमी तयार आहोत सल्ला आमच्या स्थिर विश्लेषक PVS-Studio चे वापरकर्ते आणि त्याच्या अंमलबजावणीत मदत करतात.

स्थिर विश्लेषण खरोखर सोयीस्कर आणि उपयुक्त असू शकते की नाही याबद्दल इतर वैशिष्ट्यपूर्ण शंका आहेत. मी यापैकी बहुतेक शंका दूर करण्याचा प्रयत्न "विकास प्रक्रियेत पीव्हीएस-स्टुडिओ स्टॅटिक कोड विश्लेषक सादर करण्याची कारणे" [9].

आपले लक्ष दिल्याबद्दल धन्यवाद आणि या скачать आणि PVS-स्टुडिओ विश्लेषक वापरून पहा.

अतिरिक्त दुवे

1. आंद्रे कार्पोव्ह. PVS-Studio विश्लेषक C आणि C++ कोडसाठी तयार करत असलेल्या मनोरंजक चेतावणी मी पटकन कसे पाहू शकतो?
2. विकिपीडिया भाताचे प्रमेय.
3. आंद्रे कार्पोव्ह, व्हिक्टोरिया खानिएवा. प्रोग्राम सोर्स कोडच्या स्थिर विश्लेषणामध्ये मशीन लर्निंग वापरणे.
4. पीव्हीएस-स्टुडिओ. दस्तऐवजीकरण. अतिरिक्त निदान सेटिंग्ज.
5. आंद्रे कार्पोव्ह. ईएफएल कोअर लायब्ररीचे उदाहरण वापरून पीव्हीएस-स्टुडिओ विश्लेषकची वैशिष्ट्ये, 10-15% खोटे सकारात्मक.
6. पीव्हीएस-स्टुडिओ. दस्तऐवजीकरण. विश्लेषक संदेशांचे सामूहिक दडपशाही.
7. इव्हान अँड्रियाशिन. एक्स-रे एंडोव्हस्कुलर सर्जरीच्या शैक्षणिक सिम्युलेटरच्या आमच्या प्रकल्पावर आम्ही स्थिर विश्लेषणाची चाचणी कशी केली याबद्दल.
8. पावेल एरेमेव्ह, श्व्याटोस्लाव रझमिस्लोव्ह. PVS-स्टुडिओ टीमने अवास्तव इंजिन कोड कसा सुधारला.
9. आंद्रे कार्पोव्ह. विकास प्रक्रियेत स्थिर कोड विश्लेषक PVS-Studio सादर करण्याची कारणे.

आपण हा लेख इंग्रजी भाषिक प्रेक्षकांसह सामायिक करू इच्छित असल्यास, कृपया भाषांतर दुवा वापरा: आंद्रे कार्पोव्ह. लेगसी प्रोजेक्टमध्ये स्टॅटिक कोड विश्लेषक कसे सादर करावे आणि संघाला परावृत्त करू नये.

स्त्रोत: www.habr.com