जसे ते म्हणतात, जर तुम्हाला तुमच्या जुन्या कोडची लाज वाटत नसेल, तर तुम्ही प्रोग्रामर म्हणून वाढत नाही - आणि मी या मताशी सहमत आहे. मी 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 नाही. युनिट चाचणीने त्रुटी प्रकट केली नाही आणि माझ्या पुनरावलोकनकर्त्यानेही केली नाही. लॉन्च केले गेले आणि एका रात्री माझा कोड सर्व्हरवर गेला आणि डेटा सेंटरमधील सर्व संगणक क्रॅश झाले.

काहीही वाईट घडले नाही. कोणासाठीही काहीही तोडले नाही, कारण जागतिक लॉन्चपूर्वी कोडची चाचणी एका डेटा सेंटरमध्ये केली गेली होती. जोपर्यंत SRE अभियंत्यांनी बिलियर्ड्स खेळणे थांबवले नाही आणि थोडे रोलबॅक केले नाही. दुसऱ्या दिवशी सकाळी मला क्रॅश डंपसह ईमेल प्राप्त झाला, कोड दुरुस्त केला आणि एकक चाचण्या जोडल्या ज्यामुळे त्रुटी सापडेल. मी प्रोटोकॉलचे पालन केल्यामुळे - अन्यथा माझा कोड चालण्यास अयशस्वी होईल - इतर कोणतीही समस्या नव्हती.

धडा शिकला

बर्याचजणांना खात्री आहे की अशा मोठ्या चुकीमुळे निश्चितपणे दोषी डिसमिस करावे लागेल, परंतु हे तसे नाही: प्रथम, सर्व प्रोग्रामर चुका करतात आणि दुसरे म्हणजे, ते क्वचितच दोनदा समान चूक करतात.

खरं तर, माझा एक प्रोग्रामर मित्र आहे जो एक हुशार अभियंता होता आणि एकच चूक केल्याबद्दल त्याला काढून टाकण्यात आले होते. त्यानंतर, त्याला Google वर नियुक्त करण्यात आले (आणि लवकरच पदोन्नती मिळाली) - त्याने एका मुलाखतीत केलेल्या चुकीबद्दल प्रामाणिकपणे बोलले आणि ते घातक मानले गेले नाही.

तेच आहे सांगा IBM चे दिग्गज प्रमुख थॉमस वॉटसन बद्दल:

सुमारे एक दशलक्ष डॉलर्सचा सरकारी आदेश जाहीर करण्यात आला. IBM कॉर्पोरेशन - किंवा त्याऐवजी, थॉमस वॉटसन सीनियर. वैयक्तिकरित्या - खरोखर ते मिळवायचे होते. दुर्दैवाने, विक्री प्रतिनिधी हे करू शकला नाही आणि IBM ने बोली गमावली. दुसऱ्या दिवशी, हा कर्मचारी मि. वॉटसनच्या ऑफिसमध्ये आला आणि त्याच्या डेस्कवर एक लिफाफा ठेवला. मिस्टर वॉटसनने त्याकडे पाहण्याचीही तसदी घेतली नाही - ते एका कर्मचाऱ्याची वाट पाहत होते आणि ते राजीनाम्याचे पत्र होते हे त्यांना माहीत होते.

वॉटसनने विचारले काय चूक झाली.

विक्री प्रतिनिधीने निविदेच्या प्रगतीबाबत सविस्तर माहिती दिली. टाळता येऊ शकणाऱ्या चुकांना त्याने नाव दिले. शेवटी, तो म्हणाला, “मिस्टर वॉटसन, मला समजावून सांगितल्याबद्दल धन्यवाद. मला माहित आहे की आम्हाला या ऑर्डरची किती गरज आहे. तो किती महत्वाचा होता हे मला माहीत आहे," आणि निघायला तयार झालो.

वॉटसन दारात त्याच्याजवळ गेला, त्याच्या डोळ्यात पाहिले आणि शब्दांसह लिफाफा परत केला: “मी तुला कसे जाऊ देऊ? मी फक्त तुमच्या शिक्षणात दशलक्ष डॉलर्स गुंतवले आहेत.

माझ्याकडे एक टी-शर्ट आहे ज्यावर लिहिले आहे: "जर तुम्ही चुकांमधून खरोखर शिकलात तर मी आधीच एक मास्टर आहे." किंबहुना, त्रुटींचा विचार केला तर मी विज्ञानाचा डॉक्टर आहे.

प्रथम स्थान: ॲप शोधक API

खरोखरच भयंकर चुका मोठ्या संख्येने वापरकर्त्यांना प्रभावित करतात, सार्वजनिक ज्ञान बनतात, दुरुस्त करण्यासाठी बराच वेळ घेतात आणि ज्यांनी त्या बनवल्या नसतात त्यांच्याद्वारे त्या केल्या जातात. माझी सर्वात मोठी चूक या सर्व निकषांमध्ये बसते.

जितके वाईट तितके चांगले

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

ते कसे असावे: डिझाइन अंमलबजावणी आणि इंटरफेसमध्ये सोपे असावे. अंमलबजावणीच्या साधेपणापेक्षा इंटरफेसची साधेपणा महत्त्वाची आहे.

जितके वाईट, तितके चांगले: डिझाइन अंमलबजावणी आणि इंटरफेसमध्ये सोपे असावे. इंटरफेसच्या साधेपणापेक्षा अंमलबजावणीची साधेपणा अधिक महत्त्वाची आहे.

चला ते एका मिनिटासाठी विसरुया. दुर्दैवाने, मी बर्याच वर्षांपासून त्याबद्दल विसरलो.

अ‍ॅप शोधक

Google वर काम करत असताना, मी टीमचा एक भाग होतो अ‍ॅप शोधकनवशिक्यांसाठी एक ऑनलाइन ड्रॅग-अँड-ड्रॉप डेव्हलपमेंट वातावरण Androidडेव्हलपर्स. हे २००९ साल होते, आणि आम्ही अल्फा व्हर्जन वेळेवर रिलीज करण्याची घाई करत होतो, जेणेकरून उन्हाळ्यात शिक्षकांसाठी कार्यशाळा आयोजित करता येतील आणि मग ते शरद ऋतूमध्ये त्यांच्या वर्गात हे वातावरण वापरू शकतील. TI-99/4 वर गेम्स लिहिण्याच्या माझ्या जुन्या आठवणींमुळे, मी स्प्राइट्स तयार करण्यासाठी स्वेच्छेने पुढे आलो. ज्यांना माहिती नाही त्यांच्यासाठी, स्प्राइट म्हणजे एक द्विमितीय ग्राफिक ऑब्जेक्ट जो हलू शकतो आणि सॉफ्टवेअरच्या इतर घटकांशी संवाद साधू शकतो. स्प्राइट्सच्या उदाहरणांमध्ये स्पेसशिप, लघुग्रह, चेंडू आणि पॅडल यांचा समावेश होतो.

आम्ही Java मध्ये ऑब्जेक्ट-ओरिएंटेड ॲप इन्व्हेंटर लागू केले आहे, त्यामुळे तेथे फक्त ऑब्जेक्ट्सचा एक समूह आहे. बॉल्स आणि स्प्राइट्स सारखेच वागतात म्हणून, मी गुणधर्म (फील्ड) X, Y, स्पीड (वेग) आणि हेडिंग (दिशा) असलेला एक अमूर्त स्प्राईट वर्ग तयार केला आहे. त्यांच्याकडे टक्कर शोधणे, स्क्रीनच्या काठावरून उसळणे इत्यादी समान पद्धती होत्या.

बॉल आणि स्प्राइटमधील मुख्य फरक म्हणजे नेमके काय काढले आहे - भरलेले वर्तुळ किंवा रास्टर. मी प्रथम स्प्राइट्स अंमलात आणले असल्याने, प्रतिमा जिथे स्थित आहे त्याच्या वरच्या डाव्या कोपऱ्यातील x- आणि y- निर्देशांक निर्दिष्ट करणे तर्कसंगत होते.

एकदा स्प्राइट्स काम करत असताना, मी ठरवले की मी बॉल ऑब्जेक्ट्स अगदी कमी कोडसह लागू करू शकतो. फक्त अडचण अशी होती की मी सर्वात सोपा मार्ग घेतला (अंमलबजावणी करणाऱ्याच्या दृष्टिकोनातून), बॉल तयार करणाऱ्या समोच्चच्या वरच्या डाव्या कोपऱ्यातील x- आणि y-निर्देशांक दर्शवितो.

खरं तर, कोणत्याही गणिताच्या पाठ्यपुस्तकात शिकवल्याप्रमाणे आणि वर्तुळांचा उल्लेख करणाऱ्या इतर कोणत्याही स्रोतात शिकवल्याप्रमाणे वर्तुळाच्या केंद्राचे x- आणि y-निर्देशांक सूचित करणे आवश्यक होते.

माझ्या भूतकाळातील चुकांच्या विपरीत, याने केवळ माझ्या सहकाऱ्यांवरच नाही तर लाखो ॲप इन्व्हेंटर वापरकर्त्यांनाही प्रभावित केले. त्यापैकी बरेच मुले किंवा प्रोग्रामिंगसाठी पूर्णपणे नवीन होते. बॉल उपस्थित असलेल्या प्रत्येक ऍप्लिकेशनवर काम करताना त्यांना अनेक अनावश्यक पायऱ्या पार पाडाव्या लागल्या. माझ्या इतर चुका हसून आठवल्या तर आजही मला घाम फुटतो.

मी शेवटी हा बग नुकताच, दहा वर्षांनंतर पॅच केला. “पॅच केलेले”, “निश्चित” नाही, कारण जोशुआ ब्लोच म्हटल्याप्रमाणे, API शाश्वत आहेत. विद्यमान प्रोग्राम्सवर परिणाम करणारे बदल करू शकलो नाही, आम्ही जुन्या प्रोग्राममध्ये खोटे आणि भविष्यातील सर्व प्रोग्राम्समध्ये खरे मूल्यासह OriginAtCenter गुणधर्म जोडले. वापरकर्ते एक तार्किक प्रश्न विचारू शकतात: ज्यांनी सुरुवातीचा बिंदू केंद्राव्यतिरिक्त कुठेतरी ठेवण्याचा विचार केला आहे. कोणाला? एका प्रोग्रामरला जो दहा वर्षांपूर्वी एक सामान्य API तयार करण्यात खूप आळशी होता.

शिकलेले धडे

API वर काम करताना (जे जवळजवळ प्रत्येक प्रोग्रामरला कधी कधी करावे लागते), तुम्ही जोशुआ ब्लॉचच्या व्हिडिओमध्ये दिलेल्या सर्वोत्तम सल्ल्याचे पालन केले पाहिजे.चांगले API कसे तयार करावे आणि ते इतके महत्त्वाचे का आहे"किंवा या छोट्या यादीत:

• API तुम्हाला मोठा फायदा आणि मोठी हानी दोन्ही आणू शकते.. एक चांगला API वारंवार ग्राहक तयार करतो. वाईट तुमचे चिरंतन दुःस्वप्न बनते.
• सार्वजनिक API, हिऱ्यांसारखे, कायमचे टिकतात. हे सर्व द्या: सर्वकाही बरोबर करण्याची दुसरी संधी कधीही मिळणार नाही.
• API बाह्यरेखा संक्षिप्त असावी — वर्ग आणि पद्धतीच्या स्वाक्षऱ्या आणि वर्णनांसह एक पृष्ठ, एका ओळीपेक्षा जास्त नाही. हे तुम्हाला API ची पुनर्रचना करण्यास अनुमती देईल जर ते प्रथमच परिपूर्ण झाले नाही.
• वापर प्रकरणांचे वर्णन कराAPI ची अंमलबजावणी करण्यापूर्वी किंवा त्याच्या विनिर्देशांवर काम करण्यापूर्वी. अशा प्रकारे तुम्ही पूर्णपणे गैर-कार्यक्षम API लागू करणे आणि निर्दिष्ट करणे टाळाल.

जर मी कृत्रिम स्क्रिप्टसह एक छोटासा सारांश देखील लिहिला असता, तर बहुधा मी त्रुटी ओळखली असती आणि ती सुधारली असती. नसेल तर माझा एक सहकारी नक्कीच करेल. कोणताही निर्णय ज्याचे दूरगामी परिणाम होतात त्याबद्दल किमान एक दिवस विचार करणे आवश्यक आहे (हे केवळ प्रोग्रामिंगला लागू होत नाही).

रिचर्ड गॅब्रिएलच्या निबंधाचे शीर्षक, "वाईट इज बेटर," मार्केटमध्ये प्रथम येण्याच्या फायद्याचा संदर्भ देते—अगदी अपूर्ण उत्पादनासह—जेव्हा कोणीतरी परिपूर्ण उत्पादनाचा पाठलाग करण्यासाठी अनंतकाळ घालवतो. स्प्राईट कोडवर विचार करताना, मला समजले की ते योग्य होण्यासाठी मला अधिक कोड लिहिण्याची गरज नाही. कोणी काहीही म्हणो, माझी घोर चूक झाली.

निष्कर्ष

प्रोग्रामर दररोज चुका करतात, मग ते बग्गी कोड लिहिणे असो किंवा त्यांचे कौशल्य आणि उत्पादकता सुधारेल असे काहीतरी करून पाहण्याची इच्छा नसणे. अर्थात, माझ्यासारख्या गंभीर चुका केल्याशिवाय तुम्ही प्रोग्रामर होऊ शकता. पण तुमच्या चुका ओळखल्याशिवाय आणि त्यातून शिकल्याशिवाय चांगला प्रोग्रामर बनणे अशक्य आहे.

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

स्त्रोत: www.habr.com