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

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

SelfTester

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

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

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

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

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

नोट : मैं समाधान और परियोजना की अवधारणाओं को अलग कर दूंगा, परियोजना को समाधान के हिस्से के रूप में समझना, जैसा कि विज़ुअल स्टूडियो में प्रथागत है।

SelfTester इंटरफ़ेस ऐसा दिखता है:

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

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

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

SelfTester काम के प्रस्तुत परिणाम हमेशा html-रिपोर्ट (अंतर लॉग) में दोहराए जाते हैं।

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

गति क्यों महत्वपूर्ण है:

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

यह सेल्फटेस्टर के काम को गति देने की इच्छा थी जिसने इस बार सुधार किया।

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

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

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

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

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

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

नोट : आगे हम इस बात पर विचार करेंगे कि कार्य को समानता के मूल्यों की डिफ़ॉल्ट डिग्री के साथ किया जाता है।

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

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

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

सुधार के लिए आवश्यक शर्तें

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

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

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

नोट : वास्तव में, अड़चन, एक नियम के रूप में, अभी भी डिस्क सबसिस्टम है, प्रोसेसर नहीं।

शोधन

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

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

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

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

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

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

परिणाम

मुझे लगता है, इतने लंबे परिचय के बाद, आपने पहले ही अनुमान लगा लिया था कि परिणाम शून्य था।

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

खैर, अब, वास्तव में, "हमारे लिए बहुत सारी समस्याएँ" के बारे में लेख का हिस्सा शुरू होता है, और यह सब है।

साइड इफेक्ट

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

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

और फिर ...

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

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

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

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

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

इस बीच, SelfTester की समस्याओं के बारे में एक टिकट को नई त्रुटियों के साथ फिर से भर दिया गया:

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

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

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

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

दर्द

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

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

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

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

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

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

मेरे पास सब कुछ है।

बेशक, यह एक मजाक है, और मैं आपको बताऊंगा कि सेल्फटेस्टर के साथ समस्या क्या थी :)

बिंगो!

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

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

लेकिन तब वह चली गई थी।

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

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

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

डीब्रीफिंग और निष्कर्ष

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

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

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

अब सुनिश्चित करने के लिए - यह बात है। पढ़ने के लिए धन्यवाद। सभी निराशाजनक कोड के लिए!

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: सर्गेई ख्रेनोव। अच्छे का दुश्मन सबसे अच्छा होता है ।