Devops, JUnit5 और microservice परीक्षण: मॉस्को हेइज़ेनबैग पर एक व्यक्तिपरक नज़र

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

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

लेख में तस्वीरें सम्मेलन के आधिकारिक ट्विटर से हैं ।

बारूक सदोगुरस्की। हमारे पास DevOps हैं। आइए सभी परीक्षकों को आग दें

(फोटो में - प्रचार जब बारूक ने लिक्विड सॉफ्टवेयर पुस्तक वितरित की)

जावा में शामिल होने वाले और JUGRU समूह सम्मेलनों में भाग लेने वाले, Baruch Sadogursky को किसी परिचय की आवश्यकता नहीं है। हालांकि, उन्होंने पहली बार हेइज़ेनबग में प्रदर्शन किया।

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

लेकिन यहां तक ​​कि जिन लोगों ने पहले से ही इस विषय पर कुछ सीखा है, डोर एसोसिएशन devops-research.com के अध्ययन के बारे में सीखना बहुत दिलचस्प होगा, जिसे अलग-अलग प्रदर्शन वाली टीमों में मैनुअल काम की किस्मों का प्रतिशत प्राप्त हुआ। और वितरण की गति और गुणवत्ता को जोड़ने वाले वक्र के बारे में (कुछ बिंदु पर, गति कम हो जाती है, क्योंकि हमें "बेहतर परीक्षण" के लिए समय चाहिए, लेकिन जैसे ही टीम विकसित होती है, सहसंबंध प्रत्यक्ष हो जाता है):



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

“बेशक, अगर आप बदलना नहीं चाहते हैं, तो आपके लिए काम है, हालांकि यह इतना दिलचस्प नहीं है। अब तक, 70 के दशक में COBOL में लिखी गई प्रणालियों का समर्थन करने के इच्छुक लोगों के लिए अभी भी काम है, ”बारूक ने कहा।

एरीटॉम इरशेंको। एक परियोजना को फिर से तैयार करने की आवश्यकता है? एक विचार है!

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

हालाँकि, यह रिपोर्ट एल्यूर के बारे में नहीं थी, हालाँकि उसके बारे में भी।

आर्टीम ने जनता को आश्वस्त किया कि IntelliJ IDEA के लिए प्लगइन्स लिखना एक सरल और आकर्षक गतिविधि है। इसकी आवश्यकता क्यों होगी? बल्क कोड संशोधन को स्वचालित करने के लिए। उदाहरण के लिए, JUnit4 से JUnit5 तक बड़ी संख्या में स्रोत कोड का अनुवाद करना। या एल्योर 1 से एल्योर 2. के उपयोग से या टिकिंग सिस्टम के साथ संचार के साथ परीक्षणों की टैगिंग को स्वचालित करने के लिए।

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

किरिल मरकुशेव। जावा और रिएक्टर परियोजना - परीक्षणों के बारे में क्या?

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

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

लियोनिद रुडेंको। टेराफॉर्म के साथ एक सेलेनॉइड क्लस्टर का प्रबंधन

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

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

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

लेकिन सामान्य तौर पर, कोड के रूप में इन्फ्रास्ट्रक्चर के क्षेत्र में परीक्षकों के लिए "शैक्षिक कार्यक्रम" के रूप में, यह रिपोर्ट बहुत उपयोगी है।

एंड्रे मार्केलोव। TestContainers और JUnit 5 के साथ माइक्रोसेवा चिड़ियाघर के सुरुचिपूर्ण एकीकरण परीक्षण, वैश्विक एसएमएस प्लेटफॉर्म के उदाहरण का उपयोग करते हुए

और फिर से microservices के बारे में! इस बार, यह बातचीत उन परीक्षणों को चलाने के बारे में थी जो एक ही समय में कई सेवाओं के लॉन्च और इंटरैक्शन की आवश्यकता होती है। अपने एक्सटेंशन सिस्टम के साथ JUnit5 और प्रसिद्ध (और उत्कृष्ट) TestContainers ढांचे को समाधान के आधार के रूप में प्रस्तावित किया गया था (देखें, उदाहरण के लिए, सर्गेई एगोरोव द्वारा पिछले साल की रिपोर्ट )।

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

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

@Billing @Messaging 

हम, अपेक्षाकृत बोल, लिख सकते हैं

 @Test void systemIsDoingRightThings(BillingService b, MessagingService m) {...} 

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

ये उदाहरण बहुत सुंदर लगते हैं। मेरे लिए, TestContainers और JUnit 5 के एक सक्रिय उपयोगकर्ता के रूप में, वे समझने योग्य हैं और उन्हें लागू करना अपेक्षाकृत आसान है।

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

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

एंड्रे ग्लेज़कोव बाहरी निर्भरता के साथ परीक्षण प्रणाली: समस्याएं, समाधान, माउंटबैंक

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

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

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

हालांकि, माउंटबैंक का लाभ निचले स्तर के प्रोटोकॉल (केवल HTTP के लिए वायरमॉक काम करता है) और विभिन्न प्रौद्योगिकियों के "चिड़ियाघर" में काम करने की क्षमता का समर्थन है (माउंटबैंक के लिए विभिन्न भाषाओं के लिए पुस्तकालय हैं)।

किरिल टोल्कचेव। स्प्रिंग बूट टेस्ट के साथ परीक्षण और रोना

और फिर से Java, microservices और JUnit 5. किरिल जोकर और JPoint सम्मेलनों के एक और वक्ता हैं, जो जावा समुदाय के जाने-माने हैं, जिन्होंने पहली बार Heisenbug में बात की थी।

यह रिपोर्ट पिछले साल के स्प्रिंग कर्स रिपोर्ट का संशोधित संस्करण है, जिसमें JUnit5 और स्प्रिंग बूट 2 के लिए संशोधित उदाहरण हैं। घटक / माइक्रोसर्विस परीक्षणों में स्प्रिंग बूट परीक्षणों को कॉन्फ़िगर करने से संबंधित विभिन्न व्यावहारिक समस्याओं की गहराई से जांच की जाती है। उदाहरण के लिए, मैं कॉन्फ़िगरेशन स्कैनिंग प्रक्रिया को रोकने के लिए स्रोत पेड़ में सही जगह पर खाली @SpringBootConfiguration StopConfiguration का उपयोग करने के उदाहरण से प्रभावित हुआ था, साथ ही @SpyBean बजाय @MockBean और @SpyBean का उपयोग करने की संभावना। सिरिल और एवगेनी बोरिसोव की अन्य रिपोर्टों की तरह, यह वह सामग्री है जो स्प्रिंग फ्रेमवर्क के व्यावहारिक उपयोग की प्रक्रिया में वापस आने के लिए समझ में आता है।

एंड्री कारपोव। स्थिर विश्लेषक क्या कर सकते हैं, प्रोग्रामर और परीक्षक क्या नहीं कर सकते

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

पीवीएस-स्टूडियो प्रोजेक्ट के संस्थापकों में से एक एंड्रे कारपोव, (अपने ब्लॉग से हबर पाठकों से परिचित) ने उदाहरणों पर एक रिपोर्ट बनाई कि ज्ञात उत्पादों के कोड विश्लेषण में कौन से कीड़े पीवीएस-स्टूडियो का उपयोग करते हुए पाए गए। PVS स्टूडियो अपने आप में एक पॉलीग्लॉट उत्पाद है, यह C, C ++, C # और, हाल ही में, Java का समर्थन करता है।

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

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

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

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

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

***

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

एक साल पहले अपनी रिपोर्ट में , मैंने पहले ही सम्मेलन के सामान्य माहौल को व्यक्त करने की कोशिश की और चर्चा के क्षेत्रों में, दोपहर के भोजन और पार्टी में क्या हो रहा है, इस बारे में बात की, इसलिए मैं इसे नहीं दोहराऊंगा।

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