परीक्षण और वास्तुकला के चौराहे: नील फोर्ड के साथ एक साक्षात्कार

क्यूए वास्तुकार की स्थिति का क्या अर्थ है? और मेम रैंगलर की पूरी तरह से समझ से बाहर की स्थिति का क्या मतलब है? वास्तुकला पर काम करते समय परीक्षकों को कब से जोड़ा जाना चाहिए? संगठन में प्रक्रियाओं को कैसे बदलना है ताकि पहली जटिलता के साथ एक बैठक में लोग पुराने पर वापस न आएं?

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

- क्या आप अपने और अपने करियर के बारे में बताकर शुरुआत कर सकते हैं?

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

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

मैं एक स्वतंत्र सलाहकार हो सकता है, लेकिन इस भूमिका में मुझे दो चीजें पसंद नहीं हैं। सबसे पहले, आपको सभी व्यवसाय स्वयं करना चाहिए: बिलिंग, पैसे के लिए लोगों का पीछा करना, नकदी प्रवाह को विनियमित करना और वह सब। मैं ऐसा करने में सक्षम हूं, लेकिन यह मेरी दिलचस्पी नहीं है। मेरा जुनून सॉफ्टवेयर और विकास है।

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

इसलिए अप्रैल में यह पहले से ही 14 साल का हो जाएगा क्योंकि मैं थॉटवर्क्स में था। मुझे यह अच्छी तरह से पता है, क्योंकि थॉटवर्क्स में काम करने का एक दिलचस्प फायदा यह है कि यदि आप 10 साल से कंपनी के साथ हैं, तो आपको 12 सप्ताह का अवकाश का समय मिलता है जब आप जो चाहें कर सकते हैं। और उसके बाद, हर 5 साल में आपको 6 सप्ताह का भुगतान किया हुआ रचनात्मक अवकाश मिलता है, इसलिए मेरे पास पहले 6 सप्ताह तक एक वर्ष का समय बचा है। मुझे वास्तव में 12-सप्ताह एक पसंद आया और मैं अगले एक की प्रतीक्षा कर रहा हूं। इसलिए आप हमेशा याद रखें कि आप एक दशक से यहां क्या कर रहे हैं: वे इस तरह की सुखद छुट्टियों के साथ मापा जाता है।

- यह छुट्टी की एक बहुत ही ठोस लंबाई है, शांत।

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

विशेष रूप से, मैंने हाल ही में जो बात की वह मेरी नवीनतम पुस्तक का विषय है, विकासवादी वास्तुकला का निर्माण। यदि आप बग को रोक सकते हैं, तो जो लोग परीक्षण कर रहे हैं, वे आसान हो जाएंगे। विकासवादी वास्तुकला में महत्वपूर्ण वास्तुशिल्प विशेषताओं के लिए सुरक्षा तकनीक शामिल है - जैसे कि तैनाती, परीक्षण क्षमता, मापनीयता, प्रदर्शन, और इसी तरह।

"मेम रैंगलर का क्या अर्थ है?"

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

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

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

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

- क्या आप बता सकते हैं कि सॉफ्टवेयर आर्किटेक्ट को क्या करना चाहिए, सॉफ्टवेयर आर्किटेक्ट के रूप में आप क्या करते हैं?

"बेशक मैं कोशिश कर सकता हूं, लेकिन कोई भी वास्तव में इसे एक परिभाषा देने में सफल नहीं होता है।" मार्टिन फाउलर - एक ऐसा व्यक्ति जो प्रोग्रामिंग के क्षेत्र में हर चीज की परिभाषा देने में बहुत शांत है - ने अपने पाठ में "सॉफ्टवेयर आर्किटेक्ट" शब्द को परिभाषित करने से सार्वजनिक रूप से मना कर दिया है "किसे एक आर्किटेक्ट की आवश्यकता है?" ।

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

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

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

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

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

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

- वास्तुकला और पदों के मुद्दे पर: मैं व्यवसाय कार्ड और लिंक्डइन पर "क्यूए आर्किटेक्ट" को अधिक से अधिक देखता हूं।

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

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

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

- हाइजेनबग में अपने भाषण की दिशा में बात करते हैं। आप एक परीक्षण सम्मेलन में बोलेंगे - आपके लिए सॉफ्टवेयर की गुणवत्ता के बारे में क्या?

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

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

- क्या आप गुणवत्ता से संबंधित अभ्यास से सबसे दिलचस्प मामला अध्ययन दे सकते हैं?

- यह कहना मुश्किल है, सभी परियोजनाएं अलग हैं, इसलिए सबसे अच्छा हमेशा वही होता है, जिस पर मैंने काम किया था!

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

और हमारे पास एक बिक्री प्रणाली वाला एक ग्राहक था जो समान कार्य सिद्धांत चाहता था। क्योंकि सलापर्स हमेशा आगे बढ़ते हैं, और यह आवश्यक था कि वे इंटरनेट कनेक्शन के बिना आदेश दे सकते हैं, और फिर सब कुछ सिंक्रनाइज़ हो जाएगा और जैसा होना चाहिए वैसा हो जाएगा।

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

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

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

- परीक्षण में कई लोग पूछते हैं कि वे वास्तुकला को कैसे प्रभावित कर सकते हैं। उनके लिए, हाथीदांत टॉवर में वास्तुकला कुछ है। इससे क्या हो सकता है?

- यह मुझे लगता है कि यह परीक्षकों के लिए उपयोगी होगा कि वे वास्तुकारों के पास आएं और उन्हें समझाएं कि वे अपना काम खराब तरीके से कर रहे हैं, और परीक्षकों के लिए यह जानना बेहतर है कि इसे कैसे किया जाए। जब उन्हें यह बताया जाता है तो लोग इसे पसंद करते हैं! वास्तव में, नहीं, वे इसे पसंद नहीं करते हैं, इससे अच्छा कुछ भी नहीं होगा।

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

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

, , Docker. , , . , , .

. , , , — , .

, , ?

— .

— ! ! , , , . (QA). , , , .

, , QA , . , , , . -, . -, .

, — . , QA , . , . , .

— , ?

— . , , , - QA-, -, , data science, . , .

, . , , . - : « ». - : «, , , , , ». , , , . .

, ThoughtWorks, « » . , , deployment pipeline. , , , , , . , QA, , , , , , , . , -.

— . , «-», «QA» - ?

— . ThoughtWorks , , , . , , . , , -, . , . , .

— QA ?

— , , . — . , .

- , . , , , . - , . , , . , , , . , .

, . , — , 1975 , .

— 1975-?

— « -» , . , . ( ), « ». , . , , - , . , . , .

, , , — , QA . , . , , . , , .

— .

— , , Apple , . Wi-Fi , , . . UI, . QA, .

— , . , ThoughtWorks — ?

— , , « , ». , , , .

, . ? UI, , , — , . , , , : «! !» , , 50 Jira, .

. , : , , , : , , , . , .

. , . , , , .

, — « , ». , . , , . , , . , , — , . , .

. HR, . . — , , . , - ? , , -, , , ? , - :
— ! , - ? ?
— .
— .

15- Jira, , , . , , , , . , , - Slack, , , , Slack.

, , . , 30 . ? , . , , , . -. , . , .

: , , , , . - QA: , , email Slack, , . , , , .

— . . , -, , . .

— , . , , . , , : , .

Slack! Slack — , . , , . « » , Slack. , « ». , , , , . - Slack, , , - .

, , .

-. , . — , , , . , . , - ?

— .

— ! , . , . Slack, , . , Slack, , , , , , , .

— -. - , , .

. , IT-, , , , . . , , - - ?

— . . - , , , -, . - , .

: - , . «, ». . , .

, . , , . ThoughtWorks, , , , . . , ThoughtWorks , .

, , , , , . « , ». , , - , — , . , - , . «»: , , , . . , , , .

, . -, . : «, , agile-, 1,3 , «», 30% ». , . : « , , , , ».

— , ?

— : ? ? , . , - — . ? - — , , .

, , . , , , . , -, QA , , , , . , . , , , — , , , .

— , , , - ?

— . , : , , -, , , , .

— , , , . , : « », , , .

— «architecture is abstract until operationalized», . , , ?

- बिल्कुल। , , meme wrangler.

, DevOps-. , , . DevOps , , — , , .

, — , « » . . , . , : , , . , , ?

— .
— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .

, , — , , .

— . !

Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .