अनुवाद: मैंने 30 साल की प्रोग्रामिंग में क्या सीखा

जॉन ग्राहम-कमिंग का मूल लेख ।
लेखक की अनुमति से अनुवादित और प्रकाशित।

मैं 30 से अधिक वर्षों से प्रोग्रामिंग कर रहा हूं, आधुनिक मशीनों में पहले से ही अप्रचलित (Z80 और 6502 प्रोसेसर पर) आधुनिक, BASIC, कोडांतरक, C, C ++, Tcl, Perl, Lisp, ML, occam, arc, Ruby, Go का उपयोग करते हुए कई अन्य।

निम्नलिखित मैं क्या सीखा है की एक सूची है।

0. प्रोग्रामिंग एक शिल्प है, न कि विज्ञान या इंजीनियरिंग

प्रोग्रामिंग विज्ञान या इंजीनियरिंग की तुलना में एक शिल्प के बहुत करीब है। यह उपकरण की सहायता से व्यक्त किए गए कौशल और अनुभव का एक संयोजन है। डेवलपर आवश्यक उपकरण का चयन करता है (कभी-कभी अपना खुद का बनाता है) और निर्माण प्रक्रिया में उनका उपयोग करना सीखता है।

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

यह देखते हुए कि यह एक शिल्प है, यह देखना आसान है कि अनुभव, उपकरण और अंतर्ज्ञान महत्वपूर्ण हैं।

1. ईमानदारी मुख्य नियम है

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

दोनों उदाहरण बेईमानी हैं। अपने आप से पूछें: "क्या मैं समझता हूं कि मेरा कार्यक्रम एक्स क्यों बनाता है?" अगर आप नहीं समझे, तो बाद में आपको समस्या होगी। यह जानना कि क्या हो रहा है, प्रोग्रामर की जिम्मेदारी है, क्योंकि कंप्यूटर वही करता है जो उसे ऑर्डर करता है, न कि वह जो वह चाहता है।

ईमानदारी के लिए सख्त रवैये की आवश्यकता है। आपको यह सुनिश्चित करने की आवश्यकता है कि आप जानते हैं कि आपका कार्यक्रम क्या करता है और क्यों।

2. सरलीकरण, सरलीकरण, सरलीकरण

टोनी होर ने कहा: “एक प्रणाली को डिजाइन करने के दो तरीके हैं। एक इसे इतना सरल बनाना है कि स्पष्ट रूप से इसमें कोई खामियां नहीं हैं, और दूसरा यह है कि इसे इतना जटिल बना दिया जाए कि इसमें कोई स्पष्ट खामियां न हों। पहला रास्ता ज्यादा कठिन है। ”

सरलीकृत, फिर से लिखना, हटाना।

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

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

3. डिबगर कभी-कभी नुकसान पहुंचाते हैं, प्रोफाइलर कभी नहीं

मैं लगभग डिबगर का उपयोग कभी नहीं करता। मेरे कार्यक्रम पत्रिकाओं का निर्माण करते हैं और मुझे पता है कि मेरे कार्यक्रम क्या करते हैं। आमतौर पर, मैं समझ सकता हूं कि डीबगर की सहायता का सहारा लिए बिना लॉग से मेरे कोड में क्या गलत है।

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

(नोट: उपर्युक्त सभी के बावजूद, मैं जिन प्रोग्रामरों का सम्मान करता हूं, उनमें से एक, जॉन ओस्टरहट, अंत में दिनों के लिए विंडोज डिबगर में बैठे प्रतीत होते हैं)।

दूसरी ओर, प्रोफाइलर, जब आपको प्रदर्शन से निपटने की आवश्यकता होती है। आप कभी भी यह सोचना बंद नहीं करेंगे कि प्रोफाइलर आपको क्या बता सकता है।

4. डुप्लीकेट कोड आपके पैर को बदलेगा

दोहराओ मत। अपने कोड में एक बार सब कुछ करें।

यह पाठ 2 का दावा करने से संबंधित है, लेकिन यह एक विशेष मामला है। यहां तक ​​कि डुप्लिकेट किए गए कोड का एक साधारण टुकड़ा भी बाद में परेशानी पैदा करेगा, जब आप इसे एक जगह पर "ठीक" करेंगे, लेकिन इसे दूसरे में भूल जाएं।

5. प्रोग्रामिंग लैंग्वेज की आदत न डालें

कुछ लोग विशिष्ट प्रोग्रामिंग भाषाओं से ग्रस्त हैं और उन्हें केवल उनका उपयोग करने के लिए मजबूर किया जाता है। यह एक गलती है। सभी कार्यों के लिए उपयुक्त भाषा नहीं है।

यह जानना महत्वपूर्ण है कि आप अपने टूलकिट से किस भाषा का उपयोग किसी विशेष समस्या के लिए करेंगे। और अधिक उपकरण रखना बेहतर है। विभिन्न भाषाओं का प्रयास करें, उन्हें अभ्यास में डालें।

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

मुझे भाषा युद्ध पसंद नहीं है। वे बहुत हारे हुए हैं क्योंकि वे गलत चीजों के बारे में बहस करते हैं। मेरे लिए, PHP एक बेकाबू उपकरण है, और दूसरों के हाथों में यह अद्भुत काम करता है। उसी को C ++ का कहा जा सकता है।

6. इसे बनाने की तुलना में किसी प्रोग्राम को विकसित करना आसान है।

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

यदि आप तुरंत एक पूरी प्रणाली बनाते हैं, तो: (ए) आप इसे नहीं समझते हैं, (बी) एक भूलभुलैया के साथ आते हैं जिसे बदलना बहुत मुश्किल है। दूसरी ओर, यदि आपके पास कई छोटे तत्व हैं जो एक-दूसरे के साथ बातचीत करते हैं, तो रिफैक्टिंग करना आसान होगा यदि आपको एहसास है कि आपने शुरुआत में कहीं गलती की है।

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

7. अनुप्रयोग स्तरों का अन्वेषण करें

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

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

8. मैं इतना युवा नहीं हूं कि सब कुछ जान सकूं

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

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