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

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

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

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

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

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

सबक सीखा

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

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

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

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

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

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

दूसरा स्थान: सोशल मीडिया विज्ञापन

जब मैंने सोशल मीडिया विज्ञापन पर गूगल पर काम किया था (माइस्पेस याद है?), मैंने 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)) { } } 

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

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

सबक सीखा

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

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

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

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

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

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

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

मेरे पास एक टी-शर्ट है जो कहती है: "यदि आप वास्तव में गलतियों से सीखते हैं, तो मैं पहले से ही एक मास्टर हूं।" वास्तव में, जहां तक ​​त्रुटियों का सवाल है, मैं एक डॉक्टर ऑफ साइंस हूं।

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

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

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

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

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

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

एक पल के लिए इसके बारे में भूल जाओ। दुर्भाग्य से, मैं इसके बारे में कई सालों तक भूल गया।

ऐप आविष्कारक

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

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

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


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


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


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

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

सबक सीखा

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

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

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

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

निष्कर्ष

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

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