Ctrl-Alt-Del: लर्निंग को लिगेसी कोड

स्टार वार्स, टाटू समूह और Ctrl-Alt-Del संयोजन का लिगेसी कोड के साथ क्या करना है? जब आप एक बड़ी परियोजना के लिए आते हैं और समझ में नहीं आता है, तो पुराने कोड के अयोग्य होने पर क्या करें? और अधिकारियों को यह बताना कितना अधिक कुशल है कि तकनीकी ऋण को समाप्त करने के लिए श्रम लागत का भुगतान करना पड़ता है?

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

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





हेलो, मेरा नाम डायलन बीट्टी है। बातचीत का विषय मेरे बहुत करीब है और, मेरी राय में, सॉफ्टवेयर के विकास में शामिल सभी लोगों के लिए अत्यंत महत्वपूर्ण है: हम विरासत कोड के बारे में बात करेंगे।

पहले, मैं अपने बारे में कुछ शब्द कहूंगा। मैंने 1992 में, हमारे उद्योग के मानकों के अनुसार, प्रागैतिहासिक काल में वेबसाइटों को विकसित करना शुरू किया। अब मैं लंदन की कंपनी SkillsMatter का CTO हूं। मैंने इस साल वहां काम करना शुरू कर दिया, जिससे कोड बेस विरासत में मिला: मेरे द्वारा नहीं लिखी गई कोड की 75 हजार लाइनें मेरी जिम्मेदारी बन गईं। मेरी रिपोर्ट का एक हिस्सा इस अनुभव पर आधारित है। इसके अलावा, मैं Microsoft MVP और लंदन .NET उपयोगकर्ता समूह का प्रमुख हूं।



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

नए स्टार वार्स में, कुछ अभिनेताओं को पसंद नहीं करते थे, दूसरों को साजिश पसंद नहीं थी। लेकिन कोई भी सिनेमा से बाहर नहीं आया, "मुझे यह पसंद नहीं है कि क्लासिक एएसपी का उपयोग सृजन में किया गया था!"

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

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

लेकिन पहले, आइए बात करते हैं कि आईटी में तेजी से चीजें कैसे बदल रही हैं।



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

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

चलिए थोड़ा समय निकालते हैं। यह एक याद है?



क्या आपको याद है कि यह किस वर्ष था? टाटू ने 2003 में यूरोविज़न सांग प्रतियोगिता में प्रदर्शन किया। और 2003 में, मैंने एएसपी कोड लिखा, जो अब भी उत्पादन में उपयोग किया जाता है।

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

और यद्यपि हम सभी सहमत हैं कि विरासत मौजूद है, सवाल यह है: वास्तव में क्या है? यहाँ एक नमूना कोड है:



देखो, सोचो: यह विरासत है या नहीं? आपको क्या लगता है?

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



आपके द्वारा अभी देखा गया कोड विरासत नहीं है। इसे चार दिन पहले एंड्री अकिंशिन ( ड्रीमवॉकर ) ने लिखा था। यह बेंचमार्कडॉटनेट से लिया गया है।

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

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



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



और, ऐसा लगता है, कोई और नहीं जानता कि यह जॉर्ज ओलिवेट्टी कौन था। तो ऐसा लगता है कि हमें एक बेहतर परिभाषा की तलाश करनी चाहिए।

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

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



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

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



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

कई सिस्टम जिन्हें हम विरासत मानते हैं, वे भी दो संस्करणों में मौजूद हैं, लेकिन ये "कोड में और किसी के सिर में" संस्करण हैं। और यहाँ, मेरी राय में, हमारी मुख्य कठिनाइयों में से एक है।

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

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

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



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

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

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

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



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

लेकिन पुराने कोड को फिर से लिखने पर जोर क्यों? सबसे पहले, लोग क्लासिक एएसपी को पसंद नहीं करते हैं और वे .NET पर सब कुछ फिर से लिखना चाहते हैं। फिर यह पता चला है कि आपको संस्करण 4.5, फिर 4.6, फिर .NET कोर पर सब कुछ फिर से लिखना होगा। JQuery अच्छा नहीं है, इसलिए आपको निश्चित रूप से Angular पर स्विच करना चाहिए, जिसके बाद React, फिर Vue, लाइन आ जाएगी।

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

कल्पना करें कि इससे पहले कि आप दो को फिर से शुरू करें:



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

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

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

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



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

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

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

विश्वास हासिल करने का कोई त्वरित तरीका नहीं है। सच है, विश्वास सकर्मक है: अगर मुझे आप पर भरोसा है, और आप किसी और पर भरोसा करते हैं, तो सबसे अधिक संभावना है कि मैं इस व्यक्ति पर भी भरोसा कर सकता हूं। यदि मैं आपकी राय सुनता हूं, और आप सोचते हैं कि आप अमेज़ॅन, एडब्ल्यूएस, एज़्योर या Google ऐप इंजन पर भरोसा कर सकते हैं, तो मैं यह मानने के लिए तैयार रहूंगा कि ये अच्छी सेवाएं हैं। लेकिन विश्वास हासिल करने का कोई त्वरित तरीका नहीं है।

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



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

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



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

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



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

क्या यह अनुपात आपको यथार्थवादी लगता है? मुझे आप को गुमराह करने के लिए क्षमा करें। यह ग्राफ वास्तव में घातीय है।

अगली स्लाइड में एक लाइन ग्राफ:



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

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

यदि सिर्फ कोड पढ़ना अक्षम है, तो इसे सही तरीके से कैसे अध्ययन किया जाए? रिक फेनमैन, भौतिकी में नोबेल पुरस्कार विजेता को याद करें। उसके लिए, विज्ञान पढ़ाने के मुद्दे का बहुत महत्व था। उनका मानना ​​था कि लोगों को विज्ञान नहीं, बल्कि विज्ञान को सही तरीके से कैसे पढ़ाया जाना चाहिए। उन्हें ब्राजील में साओ पाउलो विश्वविद्यालय में आमंत्रित किया गया था, क्योंकि ब्राजील में छात्रों को बहुत उच्च ग्रेड प्राप्त हुए, लेकिन साथ ही साथ उच्च-तकनीकी उत्पादन स्थापित करना संभव नहीं था। फेनमैन को यह पता लगाने में मदद करने के लिए कहा गया कि समस्या क्या थी।

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

मेरी राय में, इसमें हमारे उद्योग के लिए एक महत्वपूर्ण सबक है। , . , , , . , .

— . , , , .

— . , , . , , - .

. , . . , , .



, — , , . , , - , ? .

- , , - . .



- «I love LAMP», , , . — , , , . : , , , .

, , , . , . , DLL. , , . , — , . , , — .

— ? ? -, « - ». , , . , , . , , Wi-Fi. Wi-Fi , , , . : , , — ? और इसी तरह।

, , . , , , .



, . , , DLL api.payments.mycompany.com. DLL, , , , , DLL , . : .

, : , . . , : , .

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

Spotlight, ASP Amazon Web Services. , GitHub - « ». , , , , .

- , , . Windows 2016 , ASP, 2003 .



, , , «» , « » Windows 2016 , . ASP.NET MVC 2 , , 3, 4. DLL, , ASP.NET MVC 2, - - microsoft.com, , , Nuget , . Program Files. ASP.NET MVC 2, , .

, . , , - . , : , -?



: , , -?



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

, , , - — , .

, . 50 000 , . — 100 000, 200 000… , Int32. , , - id -. , - , , , int, .

, , , . — . , , , .



, , . , , 32 64, . , , . . , , , . , , . , , , .

, 80- 90-, -, , . , . , .



. , — , . , , , , . , .

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

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



, . , , . , . , . , , , , — , 12 , , , 3 .

, , , . , . , , .

, — ? «definition of done»?

, , GitHub , , , .



, . , . Google Analytics , , . . - , . «», , . — , . , JavaScript, . , .

, , — , . — , 20 . — , .

: , . , . , . GitHub, . - , . : , .

-. , , , , , , , COBOL. MUMPS? , . , 1960- , 26 . — . , , - .

- , « -» « ». .



: (control), (alter) (delete) - .

आपका ध्यान के लिए धन्यवाद।

, : DotNext 15-16 . .NET- ( -10 ), — , .NET Foundation. , — .