अच्छे का दुश्मन सबसे अच्छा होता है

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

SelfTester

हम C, C ++, C # और Java के लिए PVS-Studio स्टैटिक कोड एनालाइज़र का विकास और संवर्धन करते हैं। हमारे विश्लेषक की गुणवत्ता का परीक्षण करने के लिए हम आंतरिक उपकरणों का उपयोग करते हैं, जिसे सामान्य रूप से सेल्फस्टर कहा जाता है। हमने प्रत्येक समर्थित भाषा के लिए एक अलग SelfTester संस्करण बनाया। यह परीक्षण की बारीकियों के कारण है, और यह सिर्फ अधिक सुविधाजनक है। इस प्रकार, इस समय हमारे पास क्रमशः C \ C ++, C # और Java के लिए हमारी कंपनी में तीन आंतरिक SelfTester उपकरण हैं। इसके अलावा, मैं आपको SelfTester के विंडोज संस्करण के बारे में C \ C ++ विजुअल स्टूडियो प्रोजेक्ट्स के बारे में बताऊंगा, इसे केवल सेल्फटेस्टर कहते हैं। यह परीक्षक समान आंतरिक उपकरणों की कतार में पहला था, यह सभी का सबसे उन्नत और जटिल है।

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

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

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

तो, सेल्फटेस्टर का काम परीक्षण परियोजनाओं के पूल के साथ काम करना है (वैसे, सी / सी ++ के लिए उनमें से 120 से अधिक हैं)। पूल के लिए प्रोजेक्ट्स को विज़ुअल स्टूडियो समाधान के रूप में चुना जाता है। यह विभिन्न विज़ुअल स्टूडियो संस्करणों पर विश्लेषक के काम को अतिरिक्त रूप से जांचने के लिए किया जाता है, जो विश्लेषक का समर्थन करते हैं (इस बिंदु पर विज़ुअल स्टूडियो 2010 से विज़ुअल स्टूडियो 2019 तक)।

नोट: आगे मैं एक समाधान के एक भाग के रूप में एक परियोजना पर विचार करते हुए अवधारणाओं के समाधान और परियोजना को अलग करूँगा।

SelfTester का इंटरफ़ेस निम्नानुसार है:

बाईं ओर समाधानों की एक सूची है, दाईं ओर - प्रत्येक विज़ुअल स्टूडियो संस्करण के लिए एक चेक के परिणाम।

ग्रे लेबल "समर्थित नहीं" इंगित करता है कि कोई समाधान चुने हुए विज़ुअल स्टूडियो संस्करण का समर्थन नहीं करता है या यह इस संस्करण के लिए परिवर्तित नहीं किया गया है। कुछ समाधानों में एक पूल में एक कॉन्फ़िगरेशन होता है, जो एक चेक के लिए एक विशिष्ट विज़ुअल स्टूडियो संस्करण को इंगित करता है। यदि कोई संस्करण निर्दिष्ट नहीं है, तो सभी बाद के विज़ुअल स्टूडियो संस्करणों के लिए एक समाधान अपडेट किया जाएगा। इस तरह के समाधान का एक उदाहरण स्क्रीनशॉट पर है - "smart_ptr_check.sln" (सभी विजुअल स्टूडियो संस्करणों के लिए एक चेक बनाया गया है)।

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

SelfTester के परिणाम हमेशा HTML रिपोर्ट में डुप्लिकेट होते हैं (रिपोर्ट में अंतर होता है)

GUI के अलावा, SelfTester में नाइट बिल्ड रन के लिए स्वचालित मोड भी हैं। हालाँकि, सामान्य उपयोग पैटर्न दोहराया डेवलपर कार्यदिवस के दौरान एक डेवलपर द्वारा चलता है। इसलिए, सबसे महत्वपूर्ण सेल्फटेस्टर की विशेषताओं में से एक काम करने की गति है।

गति क्यों मायने रखती है:

1. नाइट टेस्ट रन के मामले में प्रत्येक चरण का प्रदर्शन काफी महत्वपूर्ण है। जाहिर है, परीक्षण जितनी तेज़ी से पास होंगे, बेहतर होगा। फिलहाल, सेल्फटेस्टर का औसत प्रदर्शन समय 2 घंटे से अधिक है;
2. दिन के दौरान सेल्फटेस्टर चलाते समय, एक डेवलपर को परिणाम के लिए कम इंतजार करना पड़ता है, जिससे उसकी कार्यबल उत्पादकता बढ़ जाती है।

यह प्रदर्शन तेज था जो इस बार परिशोधन का कारण बना।

सेल्फटेस्टर में मल्टी-थ्रेडिंग

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

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

योजनाकार का उपयोग दो स्तरों पर किया जाता है। पहला समाधान का स्तर है, इसका उपयोग PVS-Studio_Cmd.exe उपयोगिता का उपयोग करके .sln समाधान का परीक्षण शुरू करने के लिए किया जाता है। समान अनुसूचक, लेकिन समानांतरता डिग्री की एक और सेटिंग के साथ, PVS-Studio_Cmd.exe (स्रोत फ़ाइलों के परीक्षण स्तर पर) के अंदर उपयोग किया जाता है।

समानतावाद की डिग्री एक पैरामीटर है जो इंगित करता है कि एक साथ कितने समानांतर धागे चलाने पड़ते हैं। चार और आठ डिफ़ॉल्ट मान क्रमशः समाधान और फ़ाइलों के स्तर की समानता डिग्री के लिए चुने गए थे। इस प्रकार, इस कार्यान्वयन में समानांतर थ्रेड्स की संख्या 32 होनी चाहिए (4 एक साथ परीक्षण किए गए समाधान और 8 फाइलें)। यह सेटिंग आठ-कोर प्रोसेसर पर विश्लेषक के काम के लिए हमारे लिए इष्टतम है।

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

नोट: चलिए आगे मानते हैं कि हम समानता की डिफ़ॉल्ट डिग्री से निपटते हैं।

शेड्यूलर LimitedConcurrencyLevelTaskScheduler को System.Threading.Tasks.TaskSaskuler से विरासत में मिला है और ThreadPool पर काम करते समय अधिकतम समानता स्तर प्रदान करने के लिए परिष्कृत किया गया है। वंशानुगत पदानुक्रम:

LimitedConcurrencyLevelTaskScheduler : PausableTaskScheduler { .... } PausableTaskScheduler: TaskScheduler { .... } 

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

शोधन के कारण

ऊपर वर्णित प्रक्रिया में एक खामी है: विभिन्न आकारों के समाधान के साथ काम करते समय यह इष्टतम नहीं है। और परीक्षण पूल में समाधान का आकार बहुत विविध है: 8KB से 4GB तक - एक समाधान के साथ एक फ़ोल्डर का आकार और प्रत्येक में 1 से कई हजारों स्रोत कोड फ़ाइलों तक।

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

लेकिन आइए एक अक्सर होने वाली स्थिति की कल्पना करें, जब कई छोटे समाधानों का परीक्षण किया जाता है। उदाहरण के लिए, एक समाधान बड़ा है और इसमें 50 फाइलें हैं (अधिकतम संख्या में थ्रेड्स का उपयोग किया जाएगा), जबकि अन्य तीन समाधानों में तीन, चार, पांच फाइलें हैं। इस स्थिति में, हम केवल 20 थ्रेड्स (8 + 3 + 4 + 5) का उपयोग करेंगे। हम प्रोसेसर के समय को कम करते हैं और समग्र प्रदर्शन को कम करते हैं।

नोट : वास्तव में, टोंटी आमतौर पर डिस्क सबसिस्टम है, न कि प्रोसेसर।

सुधार

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

चलो फिर से प्रत्येक में फ़ाइलों की निम्न संख्या के साथ चार समाधानों के परीक्षण के हमारे उदाहरण पर विचार करें: 50, 3, 4 और 5. तीन फ़ाइलों के समाधान की जांच करने वाला कार्य सबसे तेजी से काम करने की संभावना है। इसके बजाय आठ या अधिक फ़ाइलों के साथ एक समाधान जोड़ना सबसे अच्छा होगा (इस समाधान के लिए उपलब्ध थ्रेड्स से अधिकतम उपयोग करने के लिए)। इस तरह, हम एक ही बार में reads + 25 + + + ४ + ५ का उपयोग करेंगे। बुरा नहीं है। हालांकि, सात धागे अभी भी बिन बुलाए हैं। और यहां एक और शोधन का विचार आता है, जो परीक्षण समाधानों पर चार थ्रेड्स सीमा को हटाने के लिए है। क्योंकि हम अब एक नहीं, बल्कि कई समाधान जोड़ सकते हैं, जिसमें 32 सूत्र हैं। आइए कल्पना करें कि हमारे पास तीन और चार फ़ाइलों के दो और समाधान हैं। इन कार्यों को जोड़ने से अप्रयुक्त धागे के "अंतर" को पूरी तरह से बंद कर दिया जाएगा, और उनमें से 32 (8 + 8 + 4 + 5 + 3 + 4 ) होंगे।

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

हमें कार्य वर्ग को फिर से तैयार करने की आवश्यकता है: System.Threading.Tasks.Task से विरासत में मिला और क्षेत्र "वजन" का असाइनमेंट। हम एक समाधान के लिए वजन निर्धारित करने के लिए एक सरल एल्गोरिथ्म का उपयोग करते हैं: यदि फ़ाइलों की संख्या आठ से कम है, तो वजन इस संख्या के बराबर है (उदाहरण के लिए, 5)। यदि संख्या आठ से अधिक या बराबर है, तो वजन आठ के बराबर होगा।

हमें शेड्यूलर को भी विस्तृत करना था: 32 थ्रेड्स के अधिकतम मूल्य तक पहुंचने के लिए आवश्यक वजन के साथ समाधान चुनने के लिए इसे सिखाएं। हमें एक साथ समाधानों के परीक्षण के लिए चार से अधिक थ्रेड्स की अनुमति भी देनी थी।

अंत में, हमें समाधान के वजन का मूल्यांकन करने और सेट करने के लिए पूल में सभी समाधानों का विश्लेषण करने के लिए प्रारंभिक मूल्यांकन (MSBuild API का उपयोग करके) की आवश्यकता थी (स्रोत कोड के साथ फ़ाइलों की संख्या प्राप्त करना)।

परिणाम

मुझे लगता है कि इतने लंबे परिचय के बाद आप पहले ही अनुमान लगा चुके हैं कि इसका कुछ भी नहीं आया।

हालांकि यह अच्छा है कि सुधार सरल और तेज थे।

यहां लेख का वह हिस्सा आता है, जहां मैं आपको "क्या हमें कई परेशानियों में मिला" और इससे जुड़ी सभी चीजों के बारे में बताने जा रहा हूं।

साइड इफेक्ट

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

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

और फिर ...

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

इस बार स्टैक में बहुत उपयोगी जानकारी थी - त्रुटि xml प्रारूप में थी। यह संभावना है, कि जब Proto_IRC.vcxproj परियोजना (इसकी xml प्रतिनिधित्व) की फ़ाइल को संभालते समय कुछ ऐसा ही हुआ, तो यही कारण है कि XmlTextReader इसे संभाल नहीं सका।

काफी कम समय में दो त्रुटियां होने से हमें इस समस्या पर करीब से नज़र डालनी पड़ी। इसके अलावा, जैसा कि मैंने ऊपर कहा, SelfTester डेवलपर्स द्वारा बहुत सक्रिय रूप से उपयोग किया जाता है।

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

महत्वपूर्ण बिंदु: गलत कोड SelfTester में पुन: उपयोग किया गया था। यह मूल रूप से विश्लेषक ( PVS-Studio_Cmd.exe ) में परियोजनाओं का मूल्यांकन करने के लिए उपयोग किया गया था। इसलिए समस्या की ओर ध्यान गया है। हालांकि, विश्लेषक में ऐसी कोई दुर्घटना नहीं हुई थी।

इस बीच, SelfTester के साथ समस्याओं के बारे में टिकट नई त्रुटियों के साथ पूरक था:

XmlException फिर से। जाहिर है, कहीं न कहीं प्रतिस्पर्धा के धागे हैं जो परियोजना फाइलों को पढ़ने और लिखने के साथ काम करते हैं। SelfTester निम्नलिखित मामलों में परियोजनाओं के साथ काम करता है:

1. समाधान के भार की प्रारंभिक गणना के दौरान परियोजनाओं का मूल्यांकन: एक नया कदम जो शुरू में संदेह पैदा करता था;
2. प्रोजेक्ट्स को आवश्यक विज़ुअल स्टूडियो संस्करणों में अपडेट करना: परीक्षण से पहले सही प्रदर्शन किया जाता है (परियोजनाएं हस्तक्षेप नहीं करती हैं) और यह कार्य प्रक्रिया को प्रभावित नहीं करना चाहिए।
3. परीक्षण के दौरान परियोजना मूल्यांकन: एक अच्छी तरह से स्थापित धागा-सुरक्षित तंत्र, पीवीएस- Studio_Cmd.exe से पुन: उपयोग;
4. सेल्फटेस्टर से बाहर निकलने पर प्रोजेक्ट फाइल्स को रिस्टोर करना (संशोधित .vcxproj फाइल्स को शुरुआती फाइल्स के साथ बदलना ), क्योंकि प्रोजेक्ट फाइल्स काम के दौरान विजुअल स्टूडियो वर्जन को अपडेट कर सकती हैं। यह एक अंतिम चरण है, जिसका अन्य तंत्रों पर कोई प्रभाव नहीं है।

अनुकूलन (वजन गणना) के लिए जोड़े गए नए कोड पर संदेह गिर गया। लेकिन इसकी कोड जांच से पता चला है कि यदि कोई उपयोगकर्ता SelfTester के शुरू होने के ठीक बाद विश्लेषण चलाता है, तो परीक्षक हमेशा पूर्व-मूल्यांकन के अंत तक सही ढंग से प्रतीक्षा करता है। यह जगह सुरक्षित दिखी।

फिर, हम समस्या के स्रोत की पहचान करने में असमर्थ थे।

दर्द

अगले महीने सेल्फटेस्टर कभी-कभी दुर्घटनाग्रस्त होता रहा। टिकट डेटा से भरता रहा, लेकिन यह स्पष्ट नहीं था कि इस डेटा का क्या किया जाए। अधिकांश क्रैश समान XmlException के साथ थे । कभी-कभी कुछ और भी होता था, लेकिन PVS-Studio_Cmd.exe से समान पुन: उपयोग किए गए कोड पर।

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

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

हमारी दूसरी गलती। अन्य लोग समस्या को हल करने में जुट गए । यह एक बहुत बड़ी गलती है। न केवल समस्या को हल किया, बल्कि अतिरिक्त बर्बाद संसाधनों की भी आवश्यकता थी। हां, नए लोगों ने नए विचार लाए, लेकिन इन विचारों को लागू करने के लिए (कुछ भी नहीं) काम करने में बहुत समय लगा। कुछ बिंदु पर, हमारे पास दूसरे प्रोजेक्ट में एक परियोजना के समानांतर संशोधन के साथ विभिन्न थ्रेड्स में एक और एक ही प्रोजेक्ट के मूल्यांकन का अनुकरण करने वाले हमारे इंटर्न टेस्ट प्रोग्राम थे। यह मदद नहीं की। हमें केवल यह पता चला है कि MSBuild एपीआई अंदर से सुरक्षित था, जिसे हम पहले ही जान चुके हैं। XmlException अपवाद होने पर हमने मिनी डंप ऑटो सेविंग को भी जोड़ा। हमारे पास कोई था जो यह सब डिबग कर रहा था। गरीब आदमी! चर्चा हुई, हमने अन्य अनावश्यक चीजें कीं।

अंत में, तीसरी गलती। क्या आप जानते हैं कि जिस समय इसे हल किया गया था उस समय सेल्फटेस्टर समस्या को आने में कितना समय बीत चुका है? ठीक है, आप अपने आप को गिन सकते हैं। टिकट 09/17/2018 को बनाया गया था और 02/20/2019 को बंद हुआ था। 40 से अधिक टिप्पणियां थीं! दोस्तों, यह बहुत समय है! हमने THIS के साथ खुद को पांच महीने तक व्यस्त रहने दिया। उसी समय हम विजुअल स्टूडियो 2019 का समर्थन करने में व्यस्त थे, जावा लैंग्वेज सपोर्ट को जोड़ने, MISRA C / C ++ मानक को शुरू करने, C # एनालाइज़र को बेहतर बनाने, सम्मेलनों में सक्रिय रूप से भाग लेने, लेखों का एक गुच्छा लिखने, आदि। सेल्फटेस्टर में एक बेवकूफ त्रुटि के कारण इन सभी गतिविधियों को डेवलपर्स का कम समय मिला।

दोस्तों, हमारी गलतियों से सीखते हैं और ऐसा कभी नहीं करते हैं। हम भी नहीं करेंगे।

यह मैं कर रहा हूँ।

ठीक है, यह एक मजाक था, मैं आपको बताता हूँ कि SelfTester में क्या समस्या थी :)

बिंगो!

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

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

लेकिन उस समय हमारे पास यह नहीं था।

पागल, लेकिन सच है - लगभग छह महीने की पीड़ा के दौरान किसी ने इस पर ध्यान नहीं दिया। संदर्भों से परियोजनाओं को बहाल करना एक काफी तेज़ पृष्ठभूमि प्रक्रिया है, लेकिन दुर्भाग्य से इतना तेज़ नहीं है कि सेल्फटेस्टर के पुन: लॉन्च में हस्तक्षेप न हो। और जब हम इसे लॉन्च करते हैं तो क्या होता है? यह सही है, समाधानों के वजन की गणना। एक प्रक्रिया .vcxproj फ़ाइलों को फिर से लिखती है जबकि दूसरा उन्हें पढ़ने की कोशिश करता है। XmlException को हाय कहें।

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

उसके बाद, SelfTester पुनरारंभ होता है। और इससे पहले, जाहिरा तौर पर, उपयोगकर्ताओं ने किसी तरह खुद समस्या का अनुकरण किया, परीक्षक को फिर से चलाया।

निंदा और निष्कर्ष

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

मैंने पहले से ही अपनी मुख्य गलतियों के बारे में ऊपर लिखा है, जब समस्या की खोज की, तो आत्म-ध्वजप्रणाली के लिए पर्याप्त। हम इंसान हैं, इसलिए हम गलत हो सकते हैं। अपनी गलतियों से सीखना और निष्कर्ष निकालना महत्वपूर्ण है। इस मामले से निष्कर्ष काफी सरल हैं:

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

यही है, इस बार मैं निश्चित रूप से कर रहा हूं। अंत तक पढ़ने के लिए धन्यवाद। मैं तुम्हें बगैर कोड के कामना करता हूं!