जैसा कि वे कहते हैं, यदि आप अपने पुराने कोड से शर्मिंदा नहीं हैं, तो आप एक प्रोग्रामर के रूप में विकसित नहीं हो रहे हैं - और मैं इस राय से सहमत हूं। मैंने 40 साल पहले मनोरंजन के लिए प्रोग्रामिंग शुरू की थी, और पेशेवर रूप से 30 साल पहले, इसलिए मुझसे बहुत सारी गलतियाँ हुई हैं। बहुत ज्यादा. एक कंप्यूटर विज्ञान प्रोफेसर के रूप में, मैं अपने छात्रों को उनकी, मेरी और दूसरों की गलतियों से सीखना सिखाता हूँ। मुझे लगता है कि अब अपनी गलतियों के बारे में बात करने का समय आ गया है ताकि अपनी विनम्रता न खोऊं। मुझे आशा है कि वे किसी के लिए उपयोगी होंगे।

तीसरा स्थान - माइक्रोसॉफ्ट सी कंपाइलर

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

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

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

यह एक दु: स्वप्न था। कई वर्षों बाद मुझे बताया गया कि जिस प्रोग्रामर को मेरा कोड विरासत में मिला था, वह मुझसे नफरत करता था।

सबक सीखा

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

सामान्य मामलों में तेजी लाने से दुर्लभ मामलों को अनुकूलित करने की तुलना में प्रदर्शन में अधिक प्रभावी ढंग से सुधार होगा। विडंबना यह है कि सामान्य मामले अक्सर दुर्लभ मामलों की तुलना में सरल होते हैं। यह तार्किक सलाह मानती है कि आप जानते हैं कि कौन सा मामला सामान्य माना जाता है - और यह केवल सावधानीपूर्वक परीक्षण और माप की प्रक्रिया के माध्यम से ही संभव है।

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

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

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

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

दूसरा स्थान: सोशल नेटवर्क पर विज्ञापन

जब मैं Google में सोशल मीडिया विज्ञापन पर काम कर रहा था (माइस्पेस याद है?), तो मैंने C++ में कुछ इस तरह लिखा था:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

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

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

सबक सीखा

कई लोगों को यकीन है कि इतनी बड़ी गलती के लिए दोषी को निश्चित रूप से बर्खास्त किया जाएगा, लेकिन ऐसा नहीं है: सबसे पहले, सभी प्रोग्रामर गलतियाँ करते हैं, और दूसरी बात, वे शायद ही कभी एक ही गलती दो बार करते हैं।

वास्तव में, मेरा एक प्रोग्रामर मित्र है जो एक शानदार इंजीनियर था और उसे एक गलती के कारण निकाल दिया गया था। उसके बाद, उन्हें Google में काम पर रखा गया (और जल्द ही पदोन्नत किया गया) - उन्होंने एक साक्षात्कार में ईमानदारी से अपनी गलती के बारे में बात की, और इसे घातक नहीं माना गया।

यहाँ क्या है कहना आईबीएम के प्रसिद्ध प्रमुख थॉमस वॉटसन के बारे में:

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

वॉटसन ने पूछा कि क्या ग़लत हुआ।

विक्रय प्रतिनिधि ने निविदा की प्रगति के बारे में विस्तार से बताया। उन्होंने उन गलतियों के नाम बताए जिन्हें टाला जा सकता था। अंत में, उन्होंने कहा, “मिस्टर वॉटसन, मुझे समझाने के लिए धन्यवाद। मैं जानता हूं कि हमें इस ऑर्डर की कितनी जरूरत थी. मैं जानता हूं कि वह कितना महत्वपूर्ण था,'' और जाने के लिए तैयार हो गया।

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

मेरे पास एक टी-शर्ट है जिस पर लिखा है: "यदि आप वास्तव में गलतियों से सीखते हैं, तो मैं पहले से ही उस्ताद हूँ।" वास्तव में, जब त्रुटियों की बात आती है, तो मैं विज्ञान का डॉक्टर हूं।

पहला स्थान: ऐप आविष्कारक एपीआई

वास्तव में भयानक त्रुटियाँ बड़ी संख्या में उपयोगकर्ताओं को प्रभावित करती हैं, सार्वजनिक ज्ञान बन जाती हैं, उन्हें ठीक करने में लंबा समय लगता है, और उन लोगों द्वारा की जाती हैं जो उन्हें नहीं बना सकते थे। मेरी सबसे बड़ी गलती इन सभी मानदंडों पर खरी उतरती है।

जितना बुरा उतना अच्छा

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

यह कैसा होना चाहिए: डिज़ाइन कार्यान्वयन और इंटरफ़ेस में सरल होना चाहिए। कार्यान्वयन की सरलता की तुलना में इंटरफ़ेस की सरलता अधिक महत्वपूर्ण है।

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

आइए एक मिनट के लिए इसके बारे में भूल जाएं। दुर्भाग्य से, मैं इसके बारे में कई वर्षों तक भूल गया।

ऐप आविष्कारक

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

हमने जावा में ऑब्जेक्ट-ओरिएंटेड ऐप इन्वेंटर लागू किया है, इसलिए वहां ऑब्जेक्ट्स का एक समूह है। चूँकि गेंदें और स्प्राइट बहुत समान व्यवहार करते हैं, इसलिए मैंने गुण (फ़ील्ड) X, Y, स्पीड (गति) और हेडिंग (दिशा) के साथ एक अमूर्त स्प्राइट वर्ग बनाया। उनके पास टकराव का पता लगाने, स्क्रीन के किनारे से उछलने आदि के लिए समान तरीके थे।

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

एक बार जब स्प्राइट काम कर रहे थे, तो मैंने फैसला किया कि मैं बहुत कम कोड के साथ बॉल ऑब्जेक्ट को लागू कर सकता हूं। एकमात्र समस्या यह थी कि मैंने सबसे सरल मार्ग अपनाया (कार्यान्वयनकर्ता के दृष्टिकोण से), जो गेंद को फ्रेम करने वाले समोच्च के ऊपरी बाएं कोने के x- और y-निर्देशांक को दर्शाता था।

वास्तव में, वृत्त के केंद्र के x- और y-निर्देशांक को इंगित करना आवश्यक था, जैसा कि किसी भी गणित की पाठ्यपुस्तक और किसी अन्य स्रोत में पढ़ाया जाता है जो वृत्तों का उल्लेख करता है।

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

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

सीख सीखी

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

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

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

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

निष्कर्ष

प्रोग्रामर हर दिन गलतियाँ करते हैं, चाहे वह ख़राब कोड लिखना हो या कुछ ऐसा आज़माना नहीं चाहते हों जिससे उनके कौशल और उत्पादकता में सुधार हो। निःसंदेह, आप मेरी तरह गंभीर गलतियाँ किए बिना एक प्रोग्रामर बन सकते हैं। लेकिन अपनी गलतियों को पहचाने और उनसे सीखे बिना एक अच्छा प्रोग्रामर बनना असंभव है।

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

स्रोत: www.habr.com