सॉफ्टवेयर विकास के विज्ञान और कला पर जॉन कार्मैक

अनुवादक से

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

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

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

प्रतिलेखन के लेखक से एंड्रयू कं।

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

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

नीचे इस भाषण का मेरा प्रतिलेखन है। मैं त्रुटियों के लिए पहले से माफी चाहता हूं।

जॉन कार्मैक द्वारा भाषण

खेलों को तेज करने के प्रयास में (और यह, वास्तव में, यही हमें आगे बढ़ाता है), हमने DoC 4 कोड में बहुत सारी गलतियाँ कीं। करते हैं। इन त्रुटियों, एक तरह से या किसी अन्य, अतीत में रहेगा। लेकिन खेल को तेज बनाने की बहुत इच्छा है। क्योंकि आप हर छह साल में एक नया खेल जारी नहीं कर सकते।

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

अब, मैं समझाता हूं कि यह क्षण क्या है।

वास्तव में, ऐसा नहीं है। "कंप्यूटर विज्ञान" में आप एक वैज्ञानिक हैं जब आप एल्गोरिदम के बारे में "अपने आप में चीजें" के रूप में बात करते हैं। जब आप एल्गोरिदम का अनुकूलन करते हैं, तो आप एक इंजीनियर बन जाते हैं। लेकिन एल्गोरिदम (वैज्ञानिक भाग) और अनुकूलन (इंजीनियरिंग भाग) प्रोग्रामिंग प्रक्रिया की तुलना में छोटी चीजें हैं।

हमारे पास बहुत कम प्रोग्रामर हैं जो विशेष रूप से अनुकूलन और एल्गोरिदम से निपटते हैं। हमारे प्रोग्रामर का 90% एक सामान्य दिनचर्या है। वह मांस जो कंकाल से चलता है।

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

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

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

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

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

मैंने सोचा और पाया कि यह सब वास्तव में मौलिक ज्ञान के शीर्ष पर कृत्रिम लेयरिंग है, जो कि प्रोग्रामिंग समुदाय में अवांछनीय रूप से निहित है और दी गई है।

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

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

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

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

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

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

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

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

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