तिनीहरू भन्छन्, यदि तपाइँ तपाइँको पुरानो कोड को लागी शर्मिला हुनुहुन्न भने, तपाइँ प्रोग्रामर को रूप मा बढ्दै हुनुहुन्छ - र म यो राय संग सहमत छु। मैले 40 वर्ष पहिले र व्यावसायिक रूपमा 30 वर्ष पहिले रमाईलोको लागि प्रोग्रामिङ सुरु गरें, त्यसैले मसँग धेरै गल्तीहरू छन्। धेरै धेरै। कम्प्यूटर विज्ञान प्रोफेसरको रूपमा, म मेरा विद्यार्थीहरूलाई गल्तीहरूबाट सिक्न सिकाउँछु - तिनीहरूको, मेरो र अरूबाट। मलाई लाग्छ कि यो मेरो गल्तीहरूको बारेमा कुरा गर्ने समय हो ताकि मेरो नम्रता गुमाउन नपरोस्। मलाई आशा छ कि तिनीहरू कसैको लागि उपयोगी हुनेछन्।

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

Мой школьный учитель считал, что «Ромео и Джульетту» нельзя считать трагедией, потому что у героев не было трагической вины — просто они вели себя глупо, как и положено подросткам. Тогда я с ним не согласилась, но сейчас вижу в его мнении рациональное зерно — особенно в связи с программированием.

MIT मा मेरो सोफोमोर वर्ष पूरा गर्दा, म जवान र अनुभवहीन थिएँ, जीवन र प्रोग्रामिङ दुवैमा। गर्मीमा, मैले माइक्रोसफ्टमा सी कम्पाइलर टोलीमा इन्टर्न गरें। सुरुमा मैले प्रोफाइलिङ समर्थन जस्ता नियमित कामहरू गरें, र त्यसपछि मलाई कम्पाइलरको सबैभन्दा रमाइलो भाग (मैले सोचेको जस्तै) - ब्याकएन्ड अप्टिमाइजेसनमा काम गर्ने जिम्मा दिइयो। विशेष गरी, मैले शाखा कथनहरूको लागि x86 कोड सुधार गर्नुपर्‍यो।

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

यो एक दुःस्वप्न थियो। धेरै वर्ष पछि मलाई भनियो कि मेरो कोड विरासतमा प्राप्त गर्ने प्रोग्रामरले मलाई घृणा गर्यो।

पाठ सिके

डेभिड प्याटरसन र जोन हेनेसीले कम्प्यूटर आर्किटेक्चर र कम्प्युटर सिस्टम्स डिजाइनमा लेखेका रूपमा, वास्तुकला र डिजाइनको मुख्य सिद्धान्तहरू मध्ये एक भनेको चीजहरू सकेसम्म चाँडो काम गर्ने हो।

सामान्य केसहरूलाई गति दिनुले दुर्लभ केसहरूलाई अनुकूलन गर्नु भन्दा बढी प्रभावकारी रूपमा कार्यसम्पादन सुधार गर्नेछ। विडम्बनाको रूपमा, सामान्य केसहरू अक्सर दुर्लभ व्यक्तिहरू भन्दा सरल हुन्छन्। यो तार्किक सल्लाह मानिन्छ कि तपाईलाई थाहा छ कुन केस सामान्य मानिन्छ - र यो केवल सावधानीपूर्वक परीक्षण र मापनको प्रक्रिया मार्फत सम्भव छ।

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

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

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

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

दोस्रो स्थान: सामाजिक सञ्जाल मा विज्ञापन

जब म Google मा सोशल मिडिया विज्ञापनमा काम गरिरहेको थिएँ (Myspace सम्झनुहोस्?), मैले 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 इन्जिनियरहरूले केही समयको लागि बिलियर्डहरू खेल्न छोडेनन् र थोरै रोलब्याक गरे। भोलिपल्ट बिहान मैले क्र्यास डम्पको साथ एउटा इमेल प्राप्त गरें, कोड सच्याएँ र त्रुटि समात्ने इकाई परीक्षणहरू थपे। मैले प्रोटोकल पछ्याएको हुनाले - अन्यथा मेरो कोड चलाउन असफल हुनेछ - त्यहाँ कुनै अन्य समस्याहरू थिएनन्।

पाठ सिके

धेरै निश्चित छन् कि यस्तो ठूलो गल्ती निश्चित रूपमा अपराधी बर्खास्तगी खर्च हुनेछ, तर यो त्यस्तो छैन: पहिलो, सबै प्रोग्रामरहरूले गल्ती गर्छन्, र दोस्रो, तिनीहरूले विरलै दुई पटक उही गल्ती गर्छन्।

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

त्यही हो बताउनुहोस् IBM को पौराणिक प्रमुख थोमस वाट्सनको बारेमा:

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

वाट्सनले के गल्ती भयो भनेर सोधे।

बिक्री प्रतिनिधिले टेन्डरको प्रगतिको बारेमा विस्तृत जानकारी दिए। उनले जोगिन सक्ने गल्तीलाई नाम दिए । अन्तमा, उनले भने, "मिस्टर वाटसन, मलाई व्याख्या गर्न दिनुभएकोमा धन्यवाद। मलाई थाहा छ हामीलाई यो आदेश कति आवश्यक छ। मलाई थाहा छ ऊ कत्तिको महत्त्वपूर्ण थियो, "र छोड्न तयार भएँ।

वाटसन उसको ढोकामा पुगे, उसलाई आँखामा हेरे र खाम फर्काएर यसो भने: “म तिमीलाई कसरी जान दिन सक्छु? मैले भर्खर तपाईको शिक्षामा एक मिलियन डलर लगानी गरेको छु।

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

पहिलो स्थान: एप आविष्कारक API

साँच्चै डरलाग्दो त्रुटिहरूले धेरै प्रयोगकर्ताहरूलाई असर गर्छ, सार्वजनिक ज्ञान बनाउँछ, सुधार गर्न लामो समय लाग्छ, र तिनीहरूलाई बनाउन नसक्नेहरूद्वारा बनाइन्छ। मेरो सबैभन्दा ठूलो गल्ती यी सबै मापदण्डहरूमा फिट हुन्छ।

जति नराम्रो उति राम्रो

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

यो कस्तो हुनुपर्छ: डिजाइन कार्यान्वयन र इन्टरफेस मा सरल हुनुपर्छ। इन्टरफेसको सरलता कार्यान्वयनको सरलता भन्दा बढी महत्त्वपूर्ण छ।

नराम्रो, राम्रो: डिजाइन कार्यान्वयन र इन्टरफेस मा सरल हुनुपर्छ। इन्टरफेसको सरलता भन्दा कार्यान्वयनको सरलता महत्त्वपूर्ण छ।

Забудем об этом на минутку. К сожалению, я забыла об этом на долгие годы.

अनुप्रयोग आविष्कारक

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

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

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

एक पटक स्प्राइट्सले काम गरिसकेपछि, मैले निर्णय गरे कि म धेरै सानो कोडको साथ बल वस्तुहरू लागू गर्न सक्छु। केवल समस्या यो थियो कि मैले सबैभन्दा सरल मार्ग (कार्यान्वयनकर्ताको दृष्टिकोणबाट) लिएको थिएँ, बल फ्रेम गर्ने समोच्चको माथिल्लो बायाँ कुनामा x- र y-निर्देशांकहरू संकेत गर्दै।

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

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

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

सिकेका पाठहरू

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

• एपीआईले तपाईंलाई ठूलो फाइदा र ठूलो हानि दुवै ल्याउन सक्छ।. Хороший API создает постоянных клиентов. Плохой становится вашим вечным кошмаром.
• सार्वजनिक API, हीरा जस्तै, सधैंभरि रहन्छ। यसलाई आफ्नो सबै दिनुहोस्: त्यहाँ सबै कुरा सही गर्न अर्को मौका हुनेछैन।
• API रूपरेखा संक्षिप्त हुनुपर्छ — कक्षा र विधि हस्ताक्षर र विवरणहरू सहितको एक पृष्ठ, एक रेखा भन्दा बढी लिने। यसले तपाइँलाई API लाई सजिलै संग पुनर्संरचना गर्न अनुमति दिनेछ यदि यो पहिलो पटक पूर्ण रूपमा बाहिर आउँदैन।
• प्रयोग केसहरू वर्णन गर्नुहोस्API लागू गर्नु अघि वा यसको विशिष्टतामा काम गर्नु अघि। यस तरिकाले तपाइँ पूर्ण रूपमा गैर-कार्यात्मक API लागू गर्न र निर्दिष्ट गर्नबाट बच्नुहुनेछ।

यदि मैले कृत्रिम लिपिको साथ छोटो सारांश पनि लेखेको भए, सम्भवतः मैले त्रुटि पहिचान गरी सच्याएको थिएँ। यदि होइन भने, मेरो एक सहकर्मीले पक्कै गर्थे। दूरगामी परिणामहरू भएका कुनै पनि निर्णयहरू कम्तिमा एक दिनको लागि सोच्न आवश्यक छ (यो प्रोग्रामिङमा मात्र लागू हुँदैन)।

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

निष्कर्षमा

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

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

स्रोत: www.habr.com